# Is there a null HMAC?

I came up with this question while unit testing a function that includes an HMAC. What is the expected behavior of an HMAC with a well-defined key and a set of data with no elements in it? Is there such a concept as a "null HMAC"?

For example,

byte[] key = RNG.RandomData(32);
byte[] data = { };
byte[] hmac_result = HMAC.HMAC(key, data)


Ignoring the specific language or library I used, is hmac_result well-defined (based on the value of the key or specific HMAC algorithm used), or should the function return an exception?

I'm looking for an answer backed in theory, as I could believe different HMAC implementations could choose to raise an exception on questionable input data.

If the answer depends on the hash function used, what factors would lead to the result being well-defined or not?

It is well defined.

The hash function has no impact on whether HMAC is defined for a null string text argument. As long as HMAC is defined for a particular hash function, the resulting HMAC of a null string text argument should also be well defined.

The definition of HMAC according to FIPS 190-1 is:

$$HMAC(K, text) = H((K_0 \oplus opad)|| H((K_0 \oplus ipad) || text))$$

If $$text$$ is the empty string the right hand side simply collapses to

$$H((K_0 \oplus opad)|| H(K_0 \oplus ipad))$$

which is well defined.

The hash function used has no impact on the existence of the null HMAC.

• Thanks, that makes perfect sense! I (suggested an) edit to fully answer the last part of my question. – JohnDvorak Feb 7 '16 at 22:58

The data input to HMAC (which is passed directly to the underlying hash function, after prepending the padded and masked key to it) is an arbitrary string of bytes. In particular, the zero-length string is a perfectly valid input.

Of course, if you're using a wrapper around HMAC that encodes some kind of structured data into a byte string before passing it to HMAC, then this wrapper may or may not accept (or correctly process) an empty data structure. But the HMAC specification itself says nothing about any such encoding.