up:: Foundations MOC

Key Derivation Function (KDF)

A key derivation function (KDF) is a cryptographic function that takes one source of secret material, a shared secret from a key exchange, a password, or a master key, and produces one or more strong, uniform cryptographic keys of exactly the length an application needs. The raw secret coming out of a KEM or a Diffie-Hellman exchange is often the wrong shape to use directly (uneven, too long, too short, or biased), so the KDF is the bridge that turns it into keys a symmetric cipher can actually use. It’s the standard, analyzable piece that sits between key establishment and encryption, and it’s the exact place where a classical secret and a post-quantum secret get combined in a hybrid handshake.

Source: NIST, “Recommendation for Key-Derivation Methods in Key-Establishment Schemes,” SP 800-56C Rev. 2, August 2020, csrc.nist.gov.

The short version:

• A KDF takes one input secret (a KEM or Diffie-Hellman shared secret, a password, or a master key) and produces one or more full-strength, uniform keys of exactly the length you need.
• The dominant general-purpose KDF is HKDF (RFC 5869), which runs in two steps: extract (concentrate the input’s entropy into a fixed-length pseudorandom key) then expand (stretch that key to any length and split it into several independent keys).
• Password KDFs (PBKDF2, scrypt, Argon2id) are a deliberately slow, memory-hard variety built for low-entropy inputs like passwords, so brute-forcing them stays expensive.
• KDFs are the combiner in hybrid post-quantum key exchange. X25519MLKEM768 concatenates the ML-KEM and X25519 shared secrets and feeds the result through the TLS 1.3 key schedule, which is built on HKDF, so the session is safe if either half holds.
• KDFs are quantum-safe. They’re built on hash functions, which Grover’s algorithm only dents by halving, so a 256-bit output keeps them safe with no algorithm change.

The everyday analogy: a goldsmith recasting a rough nugget

Picture a goldsmith handed a rough gold nugget. There’s real gold in it, genuine value, but the lump is the wrong shape and uneven, so you can’t spend it as-is. The goldsmith melts it down and casts it into however many identical, precisely-weighted coins you need, each one uniform and ready to use.

A KDF is that goldsmith. The shared secret from a key exchange is the nugget: it holds real, unguessable randomness, but it’s the wrong shape to drop straight into a cipher. The KDF melts it down and casts it into clean keys of the exact size the protocol calls for, and it can cast several distinct coins (one key to encrypt, one for a MAC, one for the next stage) from the single nugget. The gold, the underlying secret, never changes value; the KDF just reshapes it into something usable.

What is a key derivation function?

A key derivation function is a function that derives keying material from a source secret. NIST writes it as a function of four inputs and one output:

1. Input key material (IKM). The source secret, a Diffie-Hellman or KEM shared secret, a password, or a master key.
2. Salt (optional). Non-secret randomness that strengthens the result when the input is biased or low-entropy, and keeps derivations independent across uses.
3. Info / label (optional). A context string that binds each derived key to a specific purpose, so the same input yields different keys for different jobs.
4. Length. The number of bytes of output the application wants.
5. Output key material (OKM). The derived key or keys, indistinguishable from random to anyone who doesn’t know the IKM.

The security bar is that a KDF behaves as a pseudorandom function (PRF): an adversary who doesn’t hold the IKM can’t tell the output from a uniformly random string of the same length, even if they can see the salt and info. That PRF property is what lets a KDF safely stretch, split, and clean up raw secret material, and it’s the property the hybrid security guarantee later rests on.

Source: H. Krawczyk and P. Eronen, “HMAC-based Extract-and-Expand Key Derivation Function (HKDF),” RFC 5869, May 2010, datatracker.ietf.org.

How does a KDF work?

The most widely deployed KDF, HKDF, follows an extract-then-expand design that maps cleanly onto the two jobs a KDF has to do. Extract concentrates messy input entropy into one solid pseudorandom key; expand stretches that key out to whatever length and shape the protocol needs.

Step	What it computes	What it’s for
Extract	PRK = HMAC-Hash(salt, IKM)	Concentrates the entropy of an uneven or non-uniform input secret into a single fixed-length pseudorandom key (PRK)
Expand	Repeated HMAC over the PRK, the info string, and a counter	Stretches the PRK to any output length, and splits it into several independent, context-bound keys

Source: RFC 5869, §2 (Extract and Expand steps; PRK = HMAC-Hash(salt, IKM)), May 2010, datatracker.ietf.org.

Two details make this work in practice. When the input is already uniform, as a well-formed KEM output is, the salt can be omitted or set to zeros, because there’s no bias left to remove. And the info string is what lets a protocol derive many distinct keys from one secret without them leaking into each other, since a different info value produces an unrelated key. That’s how TLS 1.3 pulls a whole family of separate keys out of a single handshake secret.

What are the main types of KDF?

KDFs split by the kind of input they’re built for and the job they do. A high-entropy secret from a key exchange gets a fast general-purpose KDF; a low-entropy password gets a slow, memory-hard one on purpose.

Type	Examples	Input it assumes	What it’s for	Primary source
General-purpose (extract-and-expand)	HKDF-SHA-256, HKDF-SHA-384	a high-entropy secret	derive session keys from a KEM or Diffie-Hellman secret	RFC 5869
Key-establishment KDF	NIST SP 800-56C one-step and two-step	a shared secret from key agreement or transport	approved derivation right after a KEM or DH exchange	NIST SP 800-56C Rev. 2
PRF-based (from an existing key)	NIST SP 800-108, using HMAC, CMAC, or KMAC	an existing key-derivation key	derive child keys in a key hierarchy	NIST SP 800-108 Rev. 1
Password KDF (slow, memory-hard)	PBKDF2, scrypt, Argon2id	a low-entropy password	make brute-forcing passwords expensive	NIST SP 800-132, RFC 7914, RFC 9106
Protocol key schedule	TLS 1.3 key schedule	an (EC)DHE or ML-KEM secret	derive every handshake and traffic key of a session	RFC 8446

Sources: NIST, “Recommendation for Key Derivation Using Pseudorandom Functions,” SP 800-108 Rev. 1, August 2022 (updated February 2024), csrc.nist.gov; NIST, “Recommendation for Password-Based Key Derivation, Part 1,” SP 800-132, December 2010, csrc.nist.gov; C. Percival and S. Josefsson, “The scrypt Password-Based Key Derivation Function,” RFC 7914, August 2016, datatracker.ietf.org; A. Biryukov, D. Dinu, D. Khovratovich, S. Josefsson, “Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications,” RFC 9106, September 2021, datatracker.ietf.org.

The password KDFs deserve their own note. Because a password holds far less entropy than a random key, a fast function would let an attacker guess billions of candidates per second. PBKDF2 slows that down with a tunable iteration count, scrypt adds a large memory requirement so custom hardware can’t parallelize cheaply, and Argon2id (the RFC 9106 first-recommended choice) is memory-hard and resists both GPU brute-force and side-channel leakage. All three take a password plus a salt and stretch them into a key that’s expensive to attack.

The TLS 1.3 key schedule is the KDF most people rely on every day without seeing it. Every TLS 1.3 session runs its (EC)DHE or ML-KEM handshake secret through a chain of HKDF operations to produce the Early Secret, the Handshake Secret, and the Master Secret, and from those the traffic keys and IVs that actually encrypt the connection. HKDF is named in the spec as the underlying primitive for the whole schedule.

Source: E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.3,” RFC 8446, §1.2 and §7.1 (HKDF as the key-schedule primitive; Early, Handshake, and Master Secret derivation), August 2018, datatracker.ietf.org.

Why does a KDF matter in the post-quantum transition?

The KDF is the exact spot where a post-quantum key exchange and a classical one are fused into one session key. A KEM like ML-KEM outputs a shared secret, a classical X25519 exchange outputs another, and neither secret drives the cipher on its own. Both are fed through a KDF, and the KDF’s output is the key that protects the traffic. That routing is the whole mechanism behind hybrid key exchange.

The most widely deployed example is X25519MLKEM768, the hybrid group that browsers and servers switched on across TLS 1.3 during 2024 and 2025. Its combined shared secret is the concatenation of the ML-KEM-768 shared secret followed by the X25519 shared secret, 64 bytes in total, and that concatenated value is fed straight into the TLS 1.3 key schedule built on HKDF. The ML-KEM secret comes first because NIST SP 800-56C requires the first shared secret in the chain to come from a FIPS-approved key-establishment scheme.

Source: K. Kwiatkowski, P. Kampanakis, B. Westerbaan, D. Stebila, “Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3,” IETF Internet-Draft draft-kwiatkowski-tls-ecdhe-mlkem, datatracker.ietf.org.

Here’s the payoff, and it comes entirely from the KDF’s PRF property. When you feed two secrets through the KDF, the derived key stays strong as long as at least one input secret was strong. If a future quantum computer running Shor’s algorithm breaks X25519, the ML-KEM secret still holds, so the derived session key stays safe. If some later cryptanalysis dents ML-KEM, the classical X25519 secret carries it. The “safe if either half holds” guarantee that makes hybrid worth deploying is a direct consequence of running both secrets through the KDF instead of using one raw.

Sources: RFC 5869, §3 (PRF security of the extract-and-expand construction), May 2010, datatracker.ietf.org; draft-kwiatkowski-tls-ecdhe-mlkem, datatracker.ietf.org.

Are KDFs quantum-safe?

Yes. A KDF is built entirely from symmetric primitives, hash functions and the HMAC and PRF constructions layered on them, and those are the part of cryptography a quantum computer only weakens rather than breaks. Shor’s algorithm, the one that dissolves RSA and elliptic-curve key exchange, has no purchase on a hash. The only relevant quantum attack is Grover’s algorithm, which gives a square-root speedup on brute-force search and so halves the effective strength of a symmetric key or a hash output.

That halving is the entire quantum adjustment a KDF needs, and it’s answered by size. A KDF producing a 256-bit key keeps about 128 bits of strength against an idealized Grover attacker, which stays comfortably safe, and pairing HKDF with SHA-256 or SHA-384 carries the whole construction into the quantum era. Unlike RSA, ECDSA, and classical key exchange, a KDF never appears on the post-quantum deprecation schedule as an algorithm to replace. The work is to confirm output lengths reach at least 256 bits, not to swap the function out.

Source: NIST, “Report on Post-Quantum Cryptography,” NISTIR 8105, April 2016 (Grover’s quadratic speedup requires larger symmetric key sizes; doubling suffices; symmetric and hash primitives are not broken), csrc.nist.gov.

Common misconceptions

1. “A KDF is just a hash function.” A hash produces a fixed-length digest with no built-in way to bind context or produce several independent keys of a chosen length. A KDF is built on top of a hash (HKDF runs on HMAC, which runs on a hash) and adds the extract, expand, salt, and info machinery that key derivation actually needs.
2. “The shared secret from a KEM or Diffie-Hellman is ready to use as an encryption key.” It usually is not directly usable. The raw secret can be uneven, the wrong length, or biased, so a KDF turns it into a uniform key of the exact size the cipher wants, and can split it into several keys at once.
3. “You can feed a password straight into HKDF.” HKDF assumes a high-entropy input and runs fast, which is the wrong tool for a password. Passwords go through a deliberately slow, memory-hard password KDF (PBKDF2, scrypt, or Argon2id) so guessing stays expensive.
4. “KDFs have to be replaced for post-quantum security.” They keep working unchanged. Because they rest on hashes, Grover’s algorithm only halves their margin, so a 256-bit output keeps them safe with no algorithm change.
5. “A KDF tells you who you’re talking to.” It only reshapes secret material into keys. Proving the other party’s identity takes a signature and a certificate layered on top of key establishment.
6. “Hybrid key exchange combines two secrets by XOR or by choosing one.” The standard combiner concatenates both shared secrets and runs the result through a KDF, which is what makes the derived key strong whenever either input secret was strong.

Questions people ask

What’s the difference between a KDF and a hash function? A hash function maps arbitrary input to a fixed-length digest and stops there. A KDF is built from a hash but adds the structure key derivation needs: it concentrates uneven entropy, stretches output to any length, binds each key to a context with an info string, and can produce several independent keys from one secret. HKDF, the common KDF, is literally HMAC (and thus a hash) wrapped in that extra machinery.

What’s the difference between HKDF and PBKDF2? HKDF is a fast, general-purpose KDF for high-entropy inputs like a KEM or Diffie-Hellman secret. PBKDF2 is a password KDF built for low-entropy inputs, deliberately slowed with a tunable iteration count so brute-forcing a password stays costly. Use HKDF after a key exchange, and a password KDF (PBKDF2, scrypt, or Argon2id) when the input is a human password.

Do I need a KDF after a KEM like ML-KEM? For most applications, yes. NIST’s key-establishment guidance applies a KDF to the KEM’s shared secret whenever you need keying material of a particular length or several separate keys, pointing to the approved methods in SP 800-56C and SP 800-108. The KEM sets up the secret, and the KDF turns it into the keys the session uses.

Which KDF should I use for passwords? A memory-hard, deliberately slow password KDF. Argon2id is the RFC 9106 first-recommended choice and resists both GPU brute-force and side-channel leakage; scrypt (RFC 7914) is a strong memory-hard alternative; PBKDF2 (NIST SP 800-132) is the older iteration-count design still accepted where compatibility requires it. Never use a fast general-purpose KDF like plain HKDF for passwords.

Is a KDF affected by quantum computers? Only mildly, and only through Grover’s algorithm, which halves the brute-force margin of the symmetric primitives a KDF is built on. That’s fixed by size: a 256-bit output keeps roughly 128 bits of strength against a quantum attacker. Shor’s algorithm, the algorithm that breaks public-key cryptography, has no effect on a hash-based KDF at all.

How does a KDF make hybrid post-quantum key exchange secure? It’s the combiner. A hybrid handshake feeds both the classical secret and the post-quantum secret through the KDF, and because the KDF is a pseudorandom function, its output stays indistinguishable from random as long as either input secret was strong. That’s why X25519MLKEM768 stays safe even if one of its two components is later broken.

What’s a real-world example of a KDF in action? Every TLS 1.3 connection you make. The handshake produces an (EC)DHE or ML-KEM shared secret, and the TLS 1.3 key schedule runs it through HKDF to derive the Early, Handshake, and Master Secrets, and from those the actual traffic-encryption keys. It happens on every HTTPS page load.

What are the salt and info inputs to a KDF? The salt is optional non-secret randomness that strengthens derivation when the input is biased and keeps different derivations independent; if it’s absent, HKDF uses zeros. The info (or label) is an optional context string that binds a derived key to a specific purpose, so the same input secret produces different, unrelated keys for encryption, for a MAC, or for the next protocol stage.

---

Everything here is the map, given freely. When your team needs its key establishment and key-derivation stack inventoried and sequenced onto a real post-quantum migration plan, that’s the work I do. Request an alignment briefing.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.