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

["Dang, Quynh (Fed)" <[e-mail]>]

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