Re: [Cfrg] erratum for hmac what do we think...

Anyway, the actual text is prone to HMACcollisions:
Given |k|<b one can find easily another k' with HMAC-H_h = HMAC-H_k.
Why not accept this issue as an erratum of the RFC?

Not sure that the prosed correction is necessary. You gave some
considerations to reject it.
My 2 cents: you should write "MUST NOT" instead of "MUST not" ;-)

Regards,
/Ann.

Am 02.02.2017 um 22:56 schrieb Taylor R Campbell:
>> Date: Thu, 2 Feb 2017 02:24:44 +0000
>> From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
>>
>> There's an erratum posted for hmac [1] where I'd be
>> interested in what folks here think.
> Fix hash function H with block size b.  The alleged problem is that
> for a key k, if |k| > b and h = H(k), then HMAC-H_h = HMAC-H_k.
>
> What protocol would ever use HMAC-H with related keys of different
> lengths like this for the same purpose?  What protocol would ever use
> HMAC-H with keys of different lengths at all for the same purpose?
>
> Needless flexibility like that strikes me as more likely to indicate a
> deeper problem -- e.g., one reason that might happen is that the
> protocol foolishly uses a password verbatim as an HMAC key.
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg