# Why does HKDF use HMAC(salt, key) instead of HMAC(key, salt)?

I've been looking over the HKDF specs (RFC 5869), and something I noticed is that in the key and salt are reversed:

2.2.  Step 1: Extract

HKDF-Extract(salt, IKM) -> PRK

Options:
Hash     a hash function; HashLen denotes the length of the
hash function output in octets

Inputs:
salt     optional salt value (a non-secret random value);
if not provided, it is set to a string of HashLen zeros.
IKM      input keying material

Output:
PRK      a pseudorandom key (of HashLen octets)

The output PRK is calculated as follows:

PRK = HMAC-Hash(salt, IKM)


Neither the spec nor the paper seem to address the order.

To me it seems like HMAC(salt, IKM) would be weaker against a brute force search of IKMs, as the digest of the salt can in this case be precalculated by an attacker (assuming the salt is a non-secret value or zero).

What is the benefit of using it this way?

• Since HKDF assumes high entropy key material it doesn't matter if it's cheap to compute for the attacker. If you have low entropy input, you need to use a password based KDF for the slowdown. – CodesInChaos Nov 10 '15 at 8:04

To me it seems like HMAC(salt, IKM) would be weaker against a brute force search of IKMs, as the digest of the salt can in this case be precalculated by an attacker (assuming the salt is a non-secret value or zero).

Yes, it is slightly faster to brute force, but if the IKM does not have enough entropy to give brute force resistance, then a small factor will likely not be significant. In that case you would want to use a slow iterated function.

With a short IKM and a single block of output from the Expand step, you need eight calls to the compression function, two of which can be avoided if the salt is reused between calls. So the actual speedup is only 25%.

What is the benefit of using it this way?

It has to do with the security proofs (see in particular Section 6 and Appendix C).

If you feed the IKM directly into a hash function, there are some possible distributions for the IKM that would be dependent on the hash function structure (Lemma 2). By using a random (secret or not) salt as the HMAC key. the function is randomized and the distribution is independent.

Additionally, that order means that if the HKDF salt is a secret key the Extract function becomes a PRF. That is discussed in e.g. Appendix D of the paper.

Also, note that HKDF-Expand uses the normal order, because there the PRK is already a cryptographic key.

• So basically, it is easier to prove that you can create a new PRF by using a HMAC with a unique key than with a unique message? – Daan Bakker Nov 10 '15 at 17:53
• @DaanBakker, HMAC with a random key is assumed to be PRF, but the opposite order is not. In fact, when $a$ is larger than the block size $HMAC(a, b) = HMAC(H(a), b)$ so HMAC is not PRF with the order reversed. – otus Nov 10 '15 at 18:32