|  | Posted by David R. Tribble on 12/11/06 23:46 
Volker Hetzer wrote:ttt.tas schrieb:
 >> actually, i'll be using MSSQL for my DB.
 >> the problem is as follow, i want to develop some small exe file that
 >> will read the fields of unencrypted DB and encrypt it field by field.
 >> actually i'll get this DB from a client and he doesn't want me to view
 >> the DB content, its already an exisiting one, so i should develop him
 >> some exe file that he will run on this DB and will encrypt all its
 >> fields, and not the DB as a whole, so i can then take this DB and work
 >> on the encrypted fields instead.
 >
 
 I'm not clear on what you're saying.
 
 If you're encrypting the live data to create test data (a one-way
 trip of the data), you only need to use a method that takes
 printable n-byte field values and hashes them into printable n-byte
 values.  This is fairly easy to by hashing each n-byte field,
 truncating to n bytes, then converting to printable characters.
 This assumes that the encrypted data does not need to be
 decrypted.
 
 On the other hand, if you want the encrypt the live data, then
 process it on your end, then decrypt it back on the user's end,
 perhaps your best bet is for the user to create a second database
 containing all the live field values in his dB, indexed by unique
 random n-byte values (which can be generated in various ways).
 He then creates a copy of his live database, substituting the random
 values for the live values.  You operate on this copy dB, then return
 it to him.  He then reverses the process, replacing the random field
 values with the old live data values.  Obviously the replacement
 process should only be applied to alphanumeric fields that you
 do not intend to modify (e.g., names, addresses, SSNs, credit
 card numbers, etc.).
 
 -drt
 [Back to original message] |