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.