Prev: Situation just became serious
Next: Modular Scalable Key Cryptography - Completed Feasibility Model.
From: Ryan Chan on 2 Jul 2010 04:28 Assume I hashed my message using sha1 with a secret key e.g. $result = sha1( $message . $secret) // . is concat What are the advantage if I use the implementation: http://en.wikipedia.org/wiki/HMAC#Implementation, assume the hash algo is still sha1?
From: Francois Grieu on 2 Jul 2010 05:45 On 02/07/2010 10:28, Ryan Chan wrtoe: > Assume I hashed my message using sha1 with a secret key > > e.g. > > $result = sha1( $message . $secret) // . is concat > > What are the advantage if I use the implementation: > http://en.wikipedia.org/wiki/HMAC#Implementation, assume the hash algo > is still sha1? HMAC is a FIPS-approved construct that got scrutinized and has some level of security proof. You have good assurance that if $secret is wide enough that searching it by brute force is not a concern (and up to some limit so huge that it does not matter), no theoretical shortcut helps break HMAC. OTOH, if you use the first MAC scheme - You lack such assurance. - Indeed, a simple attack allows recovery of an n-bit $secret from just one 160-bit MAC corresponding to known 512-n/2 bit message, by a simple attack with expected work of about 2^(n/2+0.6) hashes using n*(2^(n/2-1)) bits of memory, for n below about 160. This is a very practical concern when $secret is a passphrase. I encourage you to find this attack, and considered the time/memory trade-offs. - One who would know two messages that collide under SHA-1 (which many believe could be found with effort in the tune of 2^52 hashes "only") could trivially deduce arbitrarily many colliding messages under the MAC. At least find this one. Francois Grieu
From: Francois Grieu on 2 Jul 2010 05:54 About $result = sha1( $message . $secret) // . is concat I wrote: > a simple attack allows recovery of an n-bit $secret from just > one 160-bit MAC corresponding to known 512-n/2 bit message, by > a simple attack with expected work of about 2^(n/2+0.6) hashes > using n*(2^(n/2-1)) bits of memory, for n below about 160. On second though, maybe what I was thinking of is only dangerously close to working thanks to the XOR at the end of the last SHA1 round. Francois Grieu
From: Francois Grieu on 2 Jul 2010 07:10 About $result = sha1( $message . $secret) // . is concat I wrote: > a simple attack allows recovery of an n-bit $secret from just > one 160-bit MAC corresponding to known 512-n/2 bit message, by > a simple attack with expected work of about 2^(n/2+0.6) hashes > using n*(2^(n/2-1)) bits of memory, for n below about 160. On third though, what I was thinking of is only dangerously close to working, thanks to the additions at the end of the processing of the second SHA1 block. Francois Grieu
From: Joseph Ashwood on 2 Jul 2010 07:42 "Ryan Chan" <ryanchan404(a)gmail.com> wrote in message news:2c84689b-dc82-484b-a0f1-99d9d715212a(a)m17g2000prl.googlegroups.com... > Assume I hashed my message using sha1 with a secret key > $result = sha1( $message . $secret) // . is concat > > What are the advantage if I use the implementation: > http://en.wikipedia.org/wiki/HMAC#Implementation, assume the hash algo > is still sha1? HMAC has a great proof of security. HMAC only needs to know the key at the beginning your proposal needs to know it at the end. Your proposal suffers from an insecurity where the end of $message is the beginning of $secret, the two can be interchanged effectively changing what was verified The weakness of SHA1 to cryptanalytic attack makes it possible to change $secret to change the 'verified" $message, HMAC has a proof that this is not feasible And the counter-argument: Assuming $secret is known after $message, HMAC is slightly slower I'd take a tiny, tiny change in speed to get the benefits of HMAC. Joe
|
Next
|
Last
Pages: 1 2 Prev: Situation just became serious Next: Modular Scalable Key Cryptography - Completed Feasibility Model. |