|
|
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
Navigation:
[Reply to this message]
|