[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Cfrg] Interim MAC function



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


On Wed, 16 Mar 2005 18:17:31 -0800, Hallam-Baker, Phillip
<pbaker at verisign.com> wrote:
> 
> > From: cfrg-bounces at ietf.org [mailto:cfrg-bounces at ietf.org] 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
> Cfrg at ietf.org
> https://www1.ietf.org/mailman/listinfo/cfrg
> 


-- 
Please adjust the reply-to address.

_______________________________________________
Cfrg mailing list
Cfrg at ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg