Zero padding in HMAC

Question

Section 2 of RFC 2104 defines the key used in HMAC should be padded with zero bytes up to the block length of the underlying hash algorithm. Isn't this a potential security vulnerability since any key ending in a zero byte would produce the same result as a key without that last byte?

The following PHP code illustrates the example:

$key = "key";
$message = "message";
var_dump(hash_hmac("SHA256", $message, $key));
var_dump(hash_hmac("SHA256", $message, $key.chr(0x00)));

and produces the following output:

string(64) "6e9ef29b75fffc5b7abae527d58fdadb2fe42e7219011976917343065f58ed4a"
string(64) "6e9ef29b75fffc5b7abae527d58fdadb2fe42e7219011976917343065f58ed4a"

I'm aware that section 3 of the same RFC recommends keys of a minimum length, which would eliminate this problem, as would some sort of hashed key generation step. However, it seems to me this could be a potential problem, or am I being overly paranoid?

Answer 1

No, this is not a security vulnerability.

HMAC requires a key of the underlying hash algorithm's block size. In general, you should provide a key which is of the underlying hash algorithm's block size.

If you forget to provide a key of this size, then there are two options. The first option is that HMAC fails hard and fast, informing you that your key is of the wrong size. The second option is that HMAC simply assumes that you meant to provide a key of the right size, but that you just left off all the trailing zero bytes by accident that were supposed to be there.

The second option above accords with the policy of being liberal in the inputs one will accept but being strict in the outputs one will generate.

So HMAC is not losing information with the second option, because a key of a smaller size is not a valid key. There is simply a policy of taking invalid keys and somehow making them valid for your convenience in a deterministic, documented way.

Answer 2

With an algorithm like HMAC, the strength of a key relates to the number of possible key, within the set that you choose to work with. For instance, you may want to work with 128-bit keys, in which case all your keys will have length exactly 16 bytes.

That two distinct keys may yield the same HMAC behaviour is a potential issue only if both keys are possible in your system. For the matter you are talking about here, this may happen only if your system accepts keys of various lengths, which is not a common situation. If you consider SSL/TLS, HMAC is used with a key generated from the master secret, with a certain fixed length for a given hash function (e.g. if SHA-256 is used, the HMAC key will always have a length of 32 bytes). Thus, no problem.

If your keys are C strings (i.e. strings which end with a byte of value 0), then no problem either: by definition, a C string contains no byte of value 0, so you cannot have two distinct C strings which, through the zero-padding, will yield the same key.

If you are really upset about it, one option is to systematically hash the key, and use the hash output as the real key for HMAC (note that the HMAC specification actually mandates such a hashing when the key is larger than the "block size" of the underlying hash function).