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

[Hugo Krawczyk <[e-mail]>]

​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