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

[Hugo Krawczyk <[e-mail]>]

Sorry Quin ;-)

I knew I had to go look at the spelling but was rushing too much... Let's
see how you spell my last name from memory :-)

To the technical point: regardless of what could have been the best
resolution to variable length keys, neither of these considerations
invalidate HMAC as a PRF. Your statement "HMAC is not a PRF" is wrong (and
can add unjustified and unwanted confusion).

As I said, practice constraints us in different ways and produce
sub-optimal results. But in the case of HMAC, really, it is hard to argue
with 20 years of widespread and robust use. If this was a real issue, it
would have come in some significant practical situations but it hasn't. I
see no justification to change the standard after (exactly) 20 years.

Hugo


On Fri, Feb 3, 2017 at 2:47 PM, Dang, Quynh (Fed) <[e-mail]>
wrote:

> Hi Hugo,
>
>
> Thank you for calling me a nice name "Quin"!
>
>
> In the HMAC paper, the key length is the IV length (the length of the hash
> function output). But in the RFC specification of the HMAC, the key is
> "any" length.
>
>
> I am sure you saw that b bits of  (key||00000....) created the situation
> that many keys produced the same output from the function HMAC for the same
> message input when the key's length was not a fixed value. If you wanted a
> variable key length, you would have had at least 2 options: (1) adding
> encoding for key length and put some restriction on key length so that the
> key and its length encoding did not get longer than the hash function input
> block (avoiding one hash function call to improve performance) or (2)
> always hashing the key to produce the exact length L for the key.
>
>
> Quynh.
> ------------------------------
> *From:* Cfrg <[e-mail]> on behalf of Hugo Krawczyk <
> [e-mail]>
> *Sent:* Thursday, February 2, 2017 11:22:25 AM
> *Cc:* [e-mail]
> *Subject:* Re: [Cfrg] erratum for hmac what do we think...
>
> ​These cases of  related key setting​s are well known and can indeed be
> seen as a weakness of HMAC. They are part of the engineering trade-offs you
> have to do for accommodating a design to the real world (and requirements
> from often chaotic IETF discussions). There were things we would have liked
> to do differently such as avoiding the longer-than-block keys or having
> different keys for the inner and outer hash applications, but that would
> have made the design problematic in different ways. The particular issue of
> not disallowing keys longer than a block came at least from an IKE
> requirement. For example, people wanted to use unlimited passphrases, and
> between having people truncate long keys or hash them first, the latter
> seemed the more robust solution. (BTW, the right way to deal with these
> issues using HMAC is to use HKDF.)
>
> Anyway, over the years I heard some rare instances where this led to a
> weakness (I have myself shown such cases) but either these were theoretical
> settings or some forms of bad practice (e.g. making the hash of a secret
> key public). The paper cited earlier by Dan Brown also notes that this
> property makes HMAC with long keys non-indifferentiable from a random
> oracle. Again, not the nicest property but hardly something to worry much
> about in practice. Also, contrary to what Quin said, this property does not
> contradict HMAC being a PRF (PRFs can have related key weaknesses).
>
> After 20 years of widespread use, it seems to me that (again) the
> engineering considerations (not breaking existing implementations) are more
> significant than the potential problems of such related key issues.
>
> Hugo
>
>
>
>
>
>
>