Cryptographic salt

A cryptographic salt is an additional input used by a cryptographic construction to vary or condition its processing of secret material. Its required properties depend on the construction. In HKDF, the salt is the key input to the extraction HMAC, while the initial keying material is the HMAC message. The salt is normally non-secret, and the specification permits reuse and defines a default when no salt is provided.^[ref]

For HKDF extraction,Fixing both inputs gives a deterministic intermediate key. Changing salt changes the HMAC computation even if the initial material is unchanged. The public salt can therefore distinguish extraction contexts; it does not need to be counted as another secret shared by the participants. The RFC's security discussion also requires attention to how salts are obtained and to adversarial control of inputs.^[ref]

An original counting argument separates public variability from secret uncertainty. Suppose secret $X$ is uniform over $2^{20}$ values and independent public salt $S$ is uniform over $2^{16}$ values. There are $2^{36}$ possible input pairs before either value is known. Once $S=s$ is public, however, only $2^{20}$ candidate secrets remain. For any deterministic derived key $K=f(X,S)$,where $H$ is information entropy and the conditioning uses conditional entropy. Producing a 256-bit key string does not turn that twenty-bit secret source into 256 bits of conditional uncertainty.

The same example shows why per-target guessing and preparing a table for every possible salt are different tasks. A table enumerating every stipulated secret/salt pair would have $2^{36}$ entries, while enumeration for one known salt still has $2^{20}$ candidate secrets. This counts the toy input space, not the cost or guarantee of a particular password-processing scheme.

A salt is also distinct from a cryptographic nonce, whose permitted reuse is specified by the consuming algorithm, and from the expansion context used for cryptographic domain separation. Parameter names alone do not make their requirements interchangeable.