= Key derivation function
A \b[key derivation function] transforms initial keying material, together with specified parameters and context, into one or more <cryptographic keys>. The output lengths and security requirements belong to the application. <HKDF> separates extraction of a pseudorandom key from expansion into the needed output material; the design and its assumptions are analysed in Krawczyk's primary paper.<Cryptographic Extraction and Key Derivation: The HKDF Scheme by Hugo Krawczyk>[Abstract, extract-then-expand construction and computational-extractor security model]{ref}
Derivation does not create secret information from nothing. For an original counting example, suppose a secret input is uniformly selected from only $2^{20}$ possibilities and every other derivation input is public and fixed. A deterministic function producing 256 output <bits> can then reach at most $2^{20}$ different outputs, not all $2^{256}$ strings independently. An adversary able to enumerate the original possibilities can enumerate the derived possibilities too. More output bytes alone do not raise the input's <information entropy>.
Context supports <cryptographic domain separation>. For a stipulated application, deriving a sending key with an unambiguous label `send` and a receiving key with `receive` assigns different intended roles to the outputs. Deriving both with exactly the same inputs and parameters instead reproduces exactly the same key. This deterministic equality is a functional property, not a failure to obtain fresh randomness during a repeated call. HKDF's `info` input is explicitly intended to bind output to application context.<HMAC-based Extract-and-Expand Key Derivation Function (HKDF) by Hugo Krawczyk and Pasi Eronen>[§3.2, context and application-specific information]{ref}
Parameter encodings must also distinguish intended inputs. Naive <concatenation> makes pairs `ab`, `c` and `a`, `bc` both encode as `abc`. A defined length-prefixed or otherwise unambiguous encoding avoids that collision of descriptions. Changing the encoding changes the KDF input even if a user informally regards the labels as equivalent.
A KDF therefore supplies a specified transformation and separation mechanism. Its security still depends on the initial material, the selected construction and the surrounding <cryptographic protocol>. It does not by itself authenticate the peer that supplied a shared secret.
Back to article page
