Re: SSN encryption

> Now perhaps you can see the logic to my request. If the SSN can be
> suitably hashed, then the original records including the SSN can be
> stored offline, and analysis can go on as before, with table merges
> easily done on the hashed SSN, but the accidental release of a record
> will not include an individual identifier, mitigating concerns about
> violations of outer security barriers.

If this is the case, then you could keep a table mapping each SSN to a
unique random key and store that mapping table safely with the original
data, while replacing each SSN with its random key for the "work" data
set. Merging new data would just involve a lookup in the mapping table
to map existing SSNs to the proper keys, and create new keys for new
SSNs. The important requirement is that the new key is totally
unrelated to the SSN it represents. The safest way is to randomly
generate a key for each SSN that's not already in the mapping table and
use the mapping table to determine if there are any collisions. If you
choose large enough keys (128 bit), you shouldn't get any collisions
either. In this case the keys aren't use to encrypt or decrypt
anything, they're just keys in the database context.
Received on Sat Oct 15 04:37:55 2005