Re: Storing encryption strings - best practice?

[Jeremy Hansen at 065 <JHansen () ITT-TECH EDU>]

> Here's an interesting way to look at the SSN problem: how 
> quickly do you need a result?  How many lookups do you do per 
> second?  If the answer is that this is always from a manual 
> process, you don't mind waiting a few seconds, and it is not 
> happening very often, then consider this approach:
>
> Would it work for you to encrypt the SSNs with a one-way 
> hash, (with or without a 'private' seed), and 'decrypt' it by 
> looping over the space of all SSNs trying each one of them 
> until you get a hash match.  Let's say that one SSN can be 
> recovered in about a minute; is that too long to wait?
> (You can tweak a concatenated random seed to make the 
> recovery time as long as you want)

A better way is to simply store the hash of each SSN and when you need
to retrieve a specific SSN, just do a SELECT on hash(ssn) and you'll get
it in no time at all. This doesn't, of course, prevent the brute-force
lookup attack mentioned previously against the 10^9 different SSNs. 

Look at Bruce Schneier's "Applied Cryptography" for various discussions
about cryptographic protocols, database cryptography and key management,
all of which are relevant in this case.

Regards,
Jeremy Hansen, MS, CISSP
Chair, School of Information Technology
ITT Technical Institute - Greenfield, WI