RFC 5869 for HKDF says "an application needs to make sure that salt values are not chosen or manipulated by an attacker".1 Soatok also discusses some nuances in choosing salts for HKDF.2 This question also discusses a situation where it led to a vulnerability.3
While these sources all indicate that salts should not be left to attacker control, I would like to know exactly what is put at risk by doing so. Does it put the initial key material at risk of revelation? Does it allow an attacker to keep trying the system performing HKDF to derive the correct key?
To put in a concrete example, let's say we have a key derivation protocol shared by Alice and Bob. Both of them have a high-quality pre-shared secret between them. They'd like to use HKDF to derive a shared keys to use for a variety of protocols that they want to use. Alice and Bob agree that to derive keys for the same application, they will use HKDF with these parameters:
- initial key material (IKM): the high-quality shared secret
- info: a human-readable string describing the application (e.g., "vacation-plans")
- salt: randomly generated by the initiator of the communication, sent to the recipient in the clear without authentication
- length: a length corresponding to the encryption algorithm they wish to use, e.g., 128-bits for AES-128
In this scenario, an attacker Eve is allowed to send a great number of messages to Bob with the same info string. Eve doesn't have the original IKM, but she does have access to the salt. She knows the original salt used with "vacation-plans", but she can also substitute any other salt value for messages with "vacation-plans". Eve can also pair any salt value with any new info strings she sees between Alice and Bob. Eve can also send messages with any info string and any salt, since Bob does not know beforehand what are valid info strings.
