On Wed, Aug 11, 2010 at 6:50 PM, tedd <t...@sperling.com> 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

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
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

Nephtali:  PHP web framework that functions beautifully

Reply via email to