At 3:48 AM -0400 8/12/10, Adam Richardson wrote:
-- snip excellent points --

Of note, SS#'s are a special piece of data, not only because of their power,
but because of their lifetime (normally as long as the individual lives.)
 This is very different from a credit card which gets updated every 5 years
or so, and is easily changed if needed.  You have to ask yourself if the
encryption/security scheme can be counted on to protect this data many years
from now.

Agreed and understood.

In summary, I wouldn't use this scheme for storing SS#'s in a large DB, as
it would keep me awake at night.  If the DB was ever compromised, I would
probabilities are just to poor when compared to other, better
algorithms/schemes available.

What do you recommend? Do you have code/reference?

However, if this is just a "Tedd" special for storing a few SS#'s on your
home computer/network, I wouldn't worry too much because 1) it's your SS#,
not mine, and more importantly 2) such a small set of SS#'s wouldn't be
analyzed because it wouldn't merit the processing power/time (unless you get
really, really rich really really quick ;)


This isn't a "Tedd's" special for storing my SS#'s on my own computer, but rather an honest attempt to better understand and implement a prudent Encryption/Decryption scheme.

Not that you said otherwise, but I am capable of understanding how these things work. My problem is that I am not current on what practice is best. It seems to me that things change so fast that when you become to rely on one solution, it goes out of date and is replaced with something else.




PHP General Mailing List (
To unsubscribe, visit:

Reply via email to