Encryption/Decryption Question
in [General]
|
Prev: Mail_Mime: undefined method Mail_mimePart::encodeHeader()
Next: Storing Social Security Number WAS:Encryption/Decryption Question
From: tedd on 11 Aug 2010 18:50 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? 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.) :-) Cheers, tedd PS: No, the SS number in question is not 123-45-6789. :-) -- ------- http://sperling.com/
From: Josh Kehn on 11 Aug 2010 20:07 On Aug 11, 2010, at 6:50 PM, tedd 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? > > 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.) :-) > > 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 > Tedd- Considering you can brute force the entire keyspace for Triple DES in under a few hours (without specialized equipment) I don't think it would take long. Granted, I'm not an encryption expert. I look forward to hearing more. Thanks, -Josh ____________________________________ Joshua Kehn | Josh.Kehn(a)gmail.com http://joshuakehn.com
From: Bastien Koert on 11 Aug 2010 20:09 From my experience, I'd have to say that it would be a real tough go to crack that. If there was a weak point in the scheme is that your end result pattern ( the ssn ) is defined with a pair of constants, the hyphens. In our scheme we remove the dashes and just provide a mask for display. We also keep a unique key with each ssn, the record number for extra security. Where to keep it is tougher, OWASP suggests that the keys be stored on another non web facing server, with a locked down filesystem. That would be best if you have the hardware available. One other option here is to load the keys into ram on server start up and never have them physically on the machine. Bastien On 8/11/10, tedd <tedd(a)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? > > 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.) :-) > > 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 > > -- Sent from my mobile device Bastien Cat, the other other white meat
From: Peter Lind on 12 Aug 2010 03:40 On 12 August 2010 02:07, Josh Kehn <josh.kehn(a)gmail.com> wrote: > On Aug 11, 2010, at 6:50 PM, tedd 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? >> >> 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.) Â :-) >> >> 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 >> > > > Tedd- > > Considering you can brute force the entire keyspace for Triple DES in under a few hours (without specialized equipment) I don't think it would take long. > > Granted, I'm not an encryption expert. I look forward to hearing more. > I'd love to see sources on how to bruteforce the entire keyspace for 3DES in under a few hours without knowing the three keys involved or the IV. Googling triple des gives you http://en.wikipedia.org/wiki/Triple_DES which among other things states "This is not currently practical and NIST considers keying option 1 to be appropriate through 2030." (keying option 1 being three independent keys as would be the case here). Regards Peter -- <hype> WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind BeWelcome/Couchsurfing: Fake51 Twitter: http://twitter.com/kafe15 </hype>
From: Adam Richardson on 12 Aug 2010 03:48
On Wed, Aug 11, 2010 at 6:50 PM, tedd <tedd(a)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 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 |