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.

Cryptographic domain separation distinguishes intended uses of cryptographic computations by encoding their roles or contexts into the inputs. A key derivation function can thereby derive different role-specific cryptographic keys from shared initial material. For HKDF, the info field is specifically intended to bind the output to application context, including relevant protocol and algorithm information.^[ref]

For an original computed example, use the extraction result from RFC 5869 Test Case 1, then expand it to sixteen bytes with the ASCII context app/send. The result is

e2f1c135562168a517b5c5451fd68f76.

Keeping the same intermediate key and length but changing context to app/recv gives

c5302399f25698fce7c4e33ad0c8b479.

These are new computations using the specified HKDF expansion; the contexts are illustrative application labels, not additional published test vectors. Repeating exactly the first set of inputs reproduces exactly its first output. The distinction is encoded in the context rather than obtained by hoping repeated deterministic calls will differ.

The encoding must preserve the intended distinction. Raw concatenation sends both field pairs ab, c and a, bc to abc. A length-prefixed encoding with one-byte lengths instead gives 02 61 62 01 63 and 01 61 02 62 63. These five-byte strings differ, even though their unstructured character concatenations agree. The one-byte example assumes each field is shorter than 256 bytes; a protocol must define its full length limits and encoding.

Different encodings do not mathematically guarantee different finite-length digests: distinct inputs can still collide. Domain separation supplies a structured distinction on which the construction's security argument can rely. It also does not authenticate a context string supplied by an attacker. The surrounding cryptographic protocol must establish the identities and agreed roles whose labels it encodes.

Salt and context have different jobs in HKDF. The cryptographic salt is an extraction input, while info is an expansion input. Reusing one parameter as if it automatically established every other required binding changes the specified construction.