3
$\begingroup$

HKDF-Extract is defined in RFC 5869 as

  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

In the TLS 1.3 key schedule a secret derived from Handshake Secret is used as the salt input to generate the Master Secret, with the IKM being a string of 0s. However that doesn't seem consistent with HKDF-Extract's definition of salt; that it is non-secret. Is TLS 1.3 using HKDF-Extract incorrectly?

$\endgroup$
0

2 Answers 2

2
$\begingroup$

Is TLS 1.3 using HKDF-Extract incorrectly?

No. Unfortunately, the (a non-secret random value) summary is somewhat misleading.

The HKDF RFC allows and basically encourages a secret salt if one is available:

It is worth noting that, while not the typical case, some applications may even have a secret salt value available for use; in such a case, HKDF provides an even stronger security guarantee. An example of such application is IKEv1 in its "public-key encryption mode", where the "salt" to the extractor is computed from nonces that are secret; similarly, the pre-shared mode of IKEv1 uses a secret salt derived from the pre-shared key.

This is because the salt is used as the key for HMAC, and a secret key is a good thing.

I presume they summarised it as non-secret because that's usually the case, and perhaps they expected people to read the entire document. Either way, it should really say (a secret or non-secret random value) for clarity.

$\endgroup$
9
  • 1
    $\begingroup$ Yes, you usually wouldn't use zeros for the input keying material but a shared secret. Furthermore, having another secret alongside the input keying material is often not possible. If the IKM is just zeros of a known length, knowing the salt would allow you to derive the PRK. Generally, the IKM is unknown. $\endgroup$ Aug 2 at 20:08
  • 1
    $\begingroup$ I am not sure I follow nor agree with the answer here. The "non-secret" denomination simply states that the security of the derived pseudo-random key doesn't depend on the secrecy of the salt. In the original paper by Krawczyk, we can see that in the security game for an extractor the salt is given to the adversary(eprint.iacr.org/2010/264.pdf definition 7) $\endgroup$ Aug 2 at 21:48
  • 1
    $\begingroup$ The usages and assumptions on HMAC are somewhat different for Extract and Extract. While Expand is assumed to be a PRF, hence HMAC should be pseudo-random and secret. This is not quite the case for Expand, where we are trying to extract a pseudo-random bitstring from a high entropy(non-uniform) input keying material. And in fact for TLS 1.3 and DH-based protocols one requires strictly more than PRF-like security on Extract. A number of security analysis rely on the PRF-ODH assumption. Alternatively, you could try to view Extract as a random oracle but you need domain separation. $\endgroup$ Aug 2 at 21:56
  • 1
    $\begingroup$ @MarcIlunga My main point is that just saying 'non-secret' results in confusion if you don't read the salt section, as demonstrated by the existence of this question. I agree with what you're saying, but if you know the salt and you know the IKM, you will obviously be able to derive the PRK. If the protocol then used constant or no info, you could derive the OKM. Not everything can be public/non-secret. But a known salt can be thought of as hashing with a known key, and unkeyed or randomised hashing can be used for key derivation. $\endgroup$ Aug 3 at 8:13
  • 1
    $\begingroup$ Yes, well put. I'm specifically saying this because the TLS 1.3 key schedule (lovely diagram) takes a derived key as the salt and zeros as the IKM at the end. If the salt is not secret and uniformly random (as you've pointed out) in this context, that's bad. So, 'there is no need to keep the salt secret' doesn't universally apply. I'm not sure why they're using Extract at a glance. $\endgroup$ Aug 3 at 9:04
1
$\begingroup$

As already mentioned in the other answer, the randomness extraction method of HKDF is simply a call to HMAC with the salt as the key and the Input Keying Material as the HMAC input. That is $\mathsf{Extract}(salt, ikm) = \mathsf{HMAC}(salt, ikm)$.

At a high-level, $ikm$ is drawn from a high min-entropy(not necessarily uniform) source, and we want to extract a uniform key out of $ikm$.

Krawczyk states a formal definition for key derivation functions in the HKDF paper: https://eprint.iacr.org/2010/264.pdf. At a high level, this is a security game that asks an adversary to distinguish a random value from one derived from a secret $ikm$. The adversary is also given a description of the IKM source and the salt used in the key derivation. Therefore, the security notion does not demand that the salt is secret.

What's happening then in TLS 1.3? Recall that $\mathsf{Extract}(salt, ikm) = \mathsf{HMAC}(salt, ikm)$. Therefore if $salt$ is not only secret but crucially pseudo-random, this is the normal "secure" invocation of HMAC as a pseudo-random function. And it's a legitimate usage because, at this point, the derived handshake secret is considered pseudo-random, and a PRF produces a pseudo-random output for each new input when keyed with a pseudo-random key. I assume this is an abuse of notation, given that HMAC is the underlying primitive in HKDF. Moreover, since the IKM used for the master secret is a fixed 0 value, it would seem strange to talk about randomness extraction. A fixed value doesn't have much

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.