Re: SSN encryption

"drfremove@nber.org" <feenberg@gmail.com> wrote in message
news:1127996717.351192.56310@g14g2000cwa.googlegroups.com...
> The requirement is that the same SSN [and only the SSN] should encrypt to
> the same value [for later comparison]

Let's begin by attempting to find the security requirements (I'll give you a
hint, any system that has to hold only the SSN like this will not be
secure). First the SSN is not anything approaching random, in fact the
Social Security Administration has a website on they are generated
(http://www.ssa.gov/history/ssn/geocard.html) so there is very little that
is unguessable, for example 602-12-3456 (apologies to whomever has this
number, it has been issued and I only guessed) is from California,
eliminating 3 digits immediately, and the 12 identifies that it is fairly
early in the usage, in fact while I don't have the timing information in
front of me 602-12-xxxx is probably mostly retired if not permanently so. So
the level of protection has to be extremely high in order to prevent the
leakage of the last group of numbers (serial number).

The requirement of a 1-1 mapping leads to low levels of protection. Even
assuming all 9 digits are unknown that is less than 2^30 work, so a modern
computer can run through all combinations in a matter of minutes. This means
that for security you MUST have a random component. Unfortunately, this
violates the aforementioned requirement.

Your best bet would be to use a hash function (e.g. MD5 chosen because it's
fast and the security levels here cannot be high anyway). Your other option
would be to use the suggestion by Tom, and depend on decrypting each of the
SSNs for comparison on addition to the database (this can be secure).
                    Joe
Received on Sat Oct 15 04:37:50 2005