HMAC with secret hash constants

Question

An HMAC depends on the Message, Key and the Hash function used such as SHA-256, SHA-512, etc.

Consider if the computation of the MAC used a different set of Initial hash values or initial array of round constants. Instead of the "first 32 bits of the fractional parts of the square roots of the first 8 primes 2..19", the first 8 primes 8675309 onward or similarly random non-trivial set of bits are used.

It appears that those values are not special, other than they should have little correlation. The usual specified values are well tested, unlike the discussed different sets.

A similar post addresses some impact, yet I'd like to go one step further.

Suppose these different Initial hash values (IV) and initial array of round constants are kept secret, otherwise the MAC is computed as usual.

What would be the negative authentication impact of exposing the secret cryptographic key of the HMAC in this case?
Is the key still needed?

Answer 1

Here it helps to understand the history, internals and rationale for HMAC and Merkle-Damgård hash functions in a bit more depth. In the M-D construction, the IV is used as the chaining argument to the compression function when processing the first block of the message. What you are proposing to do is to put that IV value under user control, so that users may plug in a secret key instead.

The point of the HMAC construction is to achieve the functional equivalent of that indirectly, by prepending a block with the key (XOR'ed with a pad) before processing the message. The hash function's fixed IV and the secret key block will be fed to the compression function, producing a new state that, from your point of view, you can think of as a derived secret key that then serves as the chaining value to hash the rest of the message. When HMAC starts processing the actual message, the state of the hash function is the same as if you'd fed that derived secret key to the hash function as a user-selected IV.

In fact, if you look at the original HMAC papers, you'll notice that HMAC's security is analyzed in terms of something called NMAC, which is a construction using hash functions with user-controlled IVs. HMAC is a practical improvement over NMAC with these advantages:

1. When HMAC was invented (and still today!), there were lots of legacy code bases and libraries that did not allow user control of the hash functions' IVs. Therefore, HMAC can be implemented without modifying legacy libraries.
2. Allowing the user of the hash function to control the IV would, more likely than not, lead to people abusing it by supplying a secret key as IV and expecting it to behave like a secure MAC, leaving them vulnerable to even more length extension vulnerabilities. A cryptographic API really should guard against misuse, and offer a secret-key MACs and public hash functions as different interfaces that accept different arguments.
3. NMAC requires two separate keys, one for the inner hash function and one for the outer. HMAC uses just one user-supplied key to internally derive the two NMAC keys (that's what the ipad and opad values are used for).

Answer 2

HMAC is in a certain sense based on a mac called NMAC, where the secret key really is used as the hash iv. Informally, choosing a random iv or computing the iv by applying the compression function to something random is more or less equivalent, so they should be equally secure.

In other words, using HMAC with a "public" key and random iv-s is roughly the same as using NMAC, which is a secure construction. (It may even be ok to use the same iv for both hash applications...)

Changing some internals of the compression function, such as the initial values for the compression function state, should also work in much the same way. Of course, I do not know enough about hash function analysis to say for sure.