Should the cSHAKE customization string ever be attacker-controlled?

Question

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?

Answer 1

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.