On Wed, Aug 11, 2010 at 6:50 PM, tedd <tedd@xxxxxxxxxxxx> wrote: > Hi gang: > > Okay, a question to the Encryption/Decryption gurus out there. > > If you were given: > > 1. This encrypted string: > > p3IVhDBT26i+p4vd7J4fAw== > > 2. Were told it was a social security number (i.e., in the form of > 123-45-6789). > > 3. And it had been generated from this code: > > $cipher = mcrypt_module_open(MCRYPT_TRIPLEDES,'','cbc',''); > mcrypt_generic_init($cipher, $key1, $key2); > $encrypted = mcrypt_generic($cipher,$social_security_number); > > 4. Where $key1 and $key2 are md5() values calculated from two different > security phrases. > > 5. Where each security phrase contains multiple non-English words. > > What would it take for you to break the encrypted string and decipher the > social security number? Can it be done? If so, how long? > Incentive. If cracking the encryption means you'll have one soc # without a name or other types of info, I suspect no hacker would devote the time needed to crack it. However, if this is an encryption scheme meant to protect 100's, 1000's, or millions of records that include the corresponding name, then this is asking for trouble because: 1. MD5 - Use of this old algorithm to produce your keys limits your key space due to collisions AND the fact that 3DES accepts keys longer than the 128 bit output MD5 produces. Additionally, only 64 bits of the MD5 digest are utilized in the 3DES initialization vector. 2. 3DES in CBC mode using the MD5'd passphrase as an IV - Using a constant initialization vector reveals much about the underlying consistencies in plaintext. 3DES uses block sizes of 64 bits (yuck), makes use of a relatively small key (effectively 112 bits.) And, as mentioned above, you're using a shortened key, which essentially makes the key space even smaller. 3. SS#'s - Several patterns to work from, if the table containing them was compromised, including the dashes, consistent padding, the distribution (first 3 digits related to where you applied for your soc.), etc. If the attacker happened to be an entry in the database, even worse (known plaintext.) Knowing how long it would take is pretty difficult. An attacker could start in the middle of the key space, one end, the other, break the key space up into blocks and randomly brute force them, etc. Odds are no matter how big the potential key space, the key that works won't be the last one tried, so the attempts rarely come at the very end of any brute force attack. As I've mentioned, there are several patterns in this particular scheme that would allow an attacker to short-curuit attempts that are not the correct key, and even a dumb brute force attack that requires 2 ^ 112 keys gets much smaller every day, technologically speaking. Additionally, the number of rows in the table would likely play a role, as more rows would provide incentive for throwing more processing power at the work. 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. 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 NOT HAVE CONFIDENCE IN THE ENCRYPTION'S ABILITY TO PROTECT THE SS#'s. The probabilities are just to poor when compared to other, better algorithms/schemes available. 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 ;) > > And lastly, where would the "best" place to store these security phrases? > (Note: I didn't ask where would be the best place for me to put them.) :-) > Might as well post them on your website with this scheme. (OK, don't flame me, just joking with that one.) Bastiens's points about storage are on spot. I would store the credentials (in memory, you'd have to reenter them when you reboot) on a separate machine which would handle all of the encrypted data processing (the DB server would merely hand-off the encrypted data.) > > Cheers, > > tedd > > PS: No, the SS number in question is not 123-45-6789. :-) > > -- > ------- > http://sperling.com/ > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > Adam -- Nephtali: PHP web framework that functions beautifully http://nephtaliproject.com
