1
$\begingroup$

On first glance, the optional customization string for cSHAKE resembles the optional salt input to HKDF-Extract. Indeed, the Noise Protocol Framework initially uses a protocol identifier string as its HKDF salt value (chaining key in Noise), which looks very similar to examples of customization strings given for cSHAKE. Both HKDF's salt and cSHAKE's customization string are intended in part for domain separation of random oracles.

The HKDF paper goes into some detail to explain that the salt value must not be attacker-controlled. For example, if it is derived from random nonces exchanged during a protocol handshake, then those nonces must be authenticated (e.g., by a signature) prior to being used in HKDF. This is in contrast to the info/context argument to HKDF-Expand, which may include elements under attacker control (public keys, user identifiers, etc).

The NIST spec for cSHAKE doesn't explicitly address this point. Should the same caveats from the HKDF paper regarding the salt also apply to cSHAKE's customization string? That is, would it be unsafe to use a customization string that might be attacker-controlled?

$\endgroup$
5
  • $\begingroup$ The reason is clear; NIST doesn't define the use case. Do you want to replace it with HKDF? $\endgroup$
    – kelalaka
    Oct 20, 2022 at 13:58
  • $\begingroup$ Well, using a XOF for key derivation is an obvious application, so I expect people will do it. $\endgroup$ Oct 20, 2022 at 15:03
  • 1
    $\begingroup$ Well, same will happen, the attacker can for to resuse a key that can be problematic especially on system that use sequential IV/nonce for encryption... $\endgroup$
    – kelalaka
    Oct 20, 2022 at 16:27
  • 2
    $\begingroup$ Hmm, yes I think you’re right. I had taken the comments in the HKDF paper as somehow related to the construction, but I see now that it’s a completely generic attack. Essentially if the salt is used for domain separation of two independent random oracles then if attacker-controlled then they can become dependent and thus insecure. $\endgroup$ Oct 21, 2022 at 10:39
  • 1
    $\begingroup$ Yes, that's it. You may write an answer to your question if you want ( with a little more details) $\endgroup$
    – kelalaka
    Oct 21, 2022 at 17:29

1 Answer 1

1
$\begingroup$

No, the customization string for cSHAKE should never be under attacker control. It should either be a fixed constant set by the protocol or application, or otherwise should be a random value that has been authenticated prior to use by a signature or other authentication mechanism.

When a hash function or XOF is used for key derivation, it is acting as a random oracle. The proofs of security of protocols often rely on different uses of the same hash function acting as independent random oracles. That is, even if the hash function is used in two different places with the same inputs it will (theoretically) produce different uniformly-random output strings. This is known as domain separation. The salt argument to HKDF and the customization string argument to cSHAKE are both intended (in part) to ensure domain separation, and therefore that uses of cSHAKE in different parts of a protocol approximate independent random oracles.

If the customization string is attacker-controlled, then the attacker may be able to force two uses of the hash function to use an identical customization string and therefore produce the same outputs for the same inputs. In theoretical terms this means that the random oracles are no longer independent and the proof of security is void. In practical terms, this may have real-world security implications. For example, if one use of the hash function is intended to derive secret key material, while another is used to derive a public value for application-level channel-binding. In this case, an attacker that is able to force these two functions to be identical could learn the value of secret key material from the public value.

Another potential real-world consequence would be if two or more uses of the hash function are used to derive secret keys that should be independent of one another. If the attacker is able to influence the customization string then this may result in identical keys being derived in the worst case, or a related-key attack in other cases.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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