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

[Jerry Leichter]

> The HMAC spec says that the key should be hashed if it is longer than the block size but zero-padded to the right if it is shorter.  Why?  Why not hash a short key?  That would simplify the code without (AFAICT) compromising security in any way.
If you look at RFC2104, it doesn't say quite this.  In fact, it seems to say two different things.  The informal description in Section 2 mentions padding the key with zeroes - but says nothing at all about keys that are too long.  Then Section 3 says "The key for HMAC can be of any length (keys longer than B bytes are first hashed using H).  However, less than L bytes is strongly discouraged as it would decrease the security strength of the function.  Keys longer than L bytes are acceptable but the extra length would not significantly increase the function strength. (A longer key may be advisable if the randomness of the key is considered weak.)"  L is the hash function's output length.

But then in the Appendix we have a sample implementation, which hashes keys that are too long - but has no explicit code to zero-pad short keys.  Rather, this falls out of copying the key into an appropriately-sized buffer which has been pre-zeroed.

There is a reported erratum against that RFC, which changes the text about long keys to say "Applications MUST not use keys longer than B bytes."  The explanation given is that "Using this approach creates an exploitable vulnerability where there are two known K instances, one the hashed key, and the other the key itself.... To cite a real world vulnerability; for all keys longer than B, using password storage configurations which store the hash of the key for integrity checks, and store the key itself in a tamper proof device, there will exist plain text keys stored on both storage systems. Compromising a hash database should not reveal plain text secrets, which will only be true if an implementation first hashes the key and uses the resultant L byte string as the actual key to HMAC."

The disposition of the Erratum is not clear.

                                                        -- Jerry