Subject: RE: [Cfrg] Interim MAC function

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 16 Mar 2005 18:17:31 -0800

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Daniel Brown

> Because for long messages, the HMAC key is computed as 
> SHA-1(m), is that 
> you what you're referring to?  Maybe the original intention 
> was to modify 
> HMAC to expand out the key the somehow.  Anyway, I agree with 
> you that 
> MASH - with a compacted key - is no more secure that SHA1 as 
> a HASH, for 
> the reason above. 

The precise proposal is to use 

MASH (m) = HMAC (m, (SHA (m))

Where HMAC (m, k) is the HMAC of message m with key k.

So the problem is to find

HMAC (m1, (SHA (m1)) = HMAC (m2, (SHA (m2))

If we find SHA (m1) = SHA (m2) the attacker still has to satisfy:

HMAC (m1, k) = HMAC (m2, k)

Which implies that

H(K XOR opad, H(K XOR ipad, m1)) = H(K XOR opad, H(K XOR ipad, m2))

It may be possible to find such a condition but I certainly do not believe
that this follows as a direct result of SHA (m1) = SHA (m2)

_______________________________________________
Cfrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/cfrg

---

From: Michael Silk <[email-masked]>
Date: Thu, 17 Mar 2005 13:27:51 +1100

But now all you have is a HMAC with a key that the attacker knows.

You've just broken the purpose of HMAC - secret-keyed hashing.

Have I missed something obvious here? It seems that this clarified
proposal is worse then normal HMAC.

-- Michael

-- 
Please adjust the reply-to address.

---

From: Michael Silk <[email-masked]>
Date: Thu, 17 Mar 2005 00:38:29 -0800

> that this follows as a direct result of SHA (m1) = SHA (m2)

Have you read Kaminsky's note about HMAC's resistance to the attack
(http://eprint.iacr.org/2004/357)?

Re your previous comment to make those two operations collide all we
need to do is find a collision for H(K XOR ipad, m2) (where "," is
append). (Ps, I assume "H" here is "SHA" and not another HMAC algo or
something).

If you know the K (which we do under your proposal) we can calculate
IV = H(K XOR ipad) (padding it to meet block requirements if required)
and then calculate our collision for "M" (m1 & m2) based on that IV.

This IS as a direct result from the research and findings (i.e
collisions from ANY IV).

-- Michael

---

From: Michael Silk <[email-masked]>
Date: Thu, 17 Mar 2005 01:27:02 -0800

Oh, but I guess in your proposal the key (K) is some function
involving M (sha(m)), so you really can't calculate the inner
collision.

I guess I will retract my object on that note too, then :)

-- Michael

---

From: Daniel Brown <[email-masked]>
Date: Thu, 17 Mar 2005 09:19:29 -0500

"Hallam-Baker, Phillip" <[email-masked]> wrote on 03/16/2005 09:17:31 

> Where HMAC (m, k) is the HMAC of message m with key k.

Ah, I see: it makes a big difference which input is the key.  In the 
notation I'm used to, the first input is taken as the key (perhaps since 
HMAC begins processing the key before the message?). Anyway, it should 
have occurred to me to try the other order, sorry I didn't think it 
through.

> that this follows as a direct result of SHA (m1) = SHA (m2)

For what little it's worth, I agree that MASH is at least as 
collision-resistant as SHA1: if MASH(m1) = MASH(m2), then one can find m1' 
and m2' such that SHA1(m1') and SHA(m2').   Would anybody hazard an 
estimate of how much better, if at all, the security is?  (E.g. 3DES is 
generally estimated to have twice the security level of DES.)