[Cryptography] Why is a short HMAC key zero-padded instead of hashed?

[Jerry Leichter]

>> If that’s your quality metric, why hash a long key then instead of just (say) truncating it?
> 
> If you truncate you may lose entropy....  Suppose the key
> consists of the concatenation of two passphrases, each encoded in 32
> bytes, and each having 50 bits of entropy, for a total of 64 bytes
> with 100 bits of entropy.
The proof of security in the original Bellare et al paper *explictly assumes a random key*.  You're wandering off into the wilderness of "it's secure because I don't see any obvious way to attack it" when you start worrying about how the HMAC primitive should deal with non-random keys.

Consider AES.  It takes a key of a given, fixed length.  Full stop.  How you get it is up to you.

The security promise for HMAC includes a dependency on the number of bits of *random* keying material you provide.  Appending zeroes to the key to get it up to the input block size doesn't change this value.  Truncating or hashing gives you a different security guarantee for these longer keys.  And dealing with non-random keys is a completely different issue.

Why should HMAC even deal with varying-length keys?  We already have ways to construct a key of a given length from a longer or shorter input.  Why build that into every primitive that takes a key?

My suggestion is that HMAC should be like AES:  Defined for a random key whose length equal to the input block size of the hash function on which it's based.  Creating such a key is a problem for the user of the primitive.  (It may be worth remarking that appending zeroes to a short random key is "good enough" - though you won't find any mention of that in the AES standard either.)

                                                        -- Jerry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20170203/1f6534d0/attachment.html>