Cybersecurity glossary
What is a Key Derivation Function (KDF)?
Learn what a key derivation function is, how HKDF extracts and expands key material, how password KDFs slow guessing, and why KDFs drive the TLS 1.3 key schedule.
Definition
A key derivation function (KDF) is a cryptographic algorithm that turns input key material, such as a shared secret or password, into one or more strong keys with the right length, separation, and context for encryption, authentication, or protocol state.
Why KDFs sit between secrets and usable keys
Raw shared secrets, passwords, and master keys are rarely safe to use directly. They may have the wrong length, partial bias, missing context, or too much authority for one cryptographic operation. A key derivation function (KDF) turns that input into purpose-built keys while preserving security boundaries.
Good KDF design answers three questions: what secret is being transformed, what context labels the output, and how many independent keys the protocol needs.
Common KDF families
HKDF
An HMAC-based extract-and-expand KDF standardized in RFC 5869 and used by protocols such as TLS 1.3.
Password KDFs
Argon2, PBKDF2, scrypt, and bcrypt slow offline guessing when the input is a human password or passphrase.
Counter-mode KDFs
NIST SP 800-108 defines PRF-based methods that derive labeled keys using counters, context, and output length.
Key-establishment KDFs
NIST SP 800-56C covers derivation methods for turning key agreement outputs into protocol-ready keying material.
How extract-and-expand derivation works
HKDF is the best-known example of a two-stage KDF. The pattern is useful because it separates cleanup of input key material from production of multiple context-specific outputs.
Start with input key material
This may be a Diffie-Hellman shared secret, a previous secret in a key schedule, or another high-entropy value.
Add salt when available
A salt helps randomize extraction and limits damage when related inputs appear across sessions.
Extract a pseudorandom key
HKDF-Extract uses HMAC to condense the input into a fixed-length pseudorandom key.
Bind output to context
Labels, transcript hashes, algorithm identifiers, and party identities tell the KDF what each output is for.
Expand into working keys
HKDF-Expand generates keys, IVs, exporter secrets, or other outputs with clear separation between purposes.
Use and erase carefully
Applications use the derived keys for their assigned jobs and clear intermediate secrets when no longer needed.
Password KDFs are different from protocol KDFs
Password KDFs defend against offline guessing after a verifier or encrypted file is stolen. They must be intentionally expensive because passwords have low entropy. Protocol KDFs such as HKDF usually assume high-entropy input and focus on extraction, expansion, and separation.
| KDF type | Typical input | Primary goal | Examples |
|---|---|---|---|
| Extract-and-expand KDF | Shared secret or master secret | Turn high-entropy material into separated keys | HKDF |
| Password KDF | Password or passphrase | Slow offline guessing with time, memory, or both | Argon2id, PBKDF2, scrypt, bcrypt |
| PRF-based KDF | Key derivation key plus labels and context | Produce one or more keys under a standardized construction | NIST SP 800-108 counter mode |
| Key-establishment KDF | Key agreement result | Derive keying material for a session or protocol | NIST SP 800-56C one-step and two-step methods |
The TLS 1.3 key schedule role
TLS 1.3 uses HKDF as the backbone of its key schedule. The handshake starts from early secrets, mixes in key exchange output, and derives handshake traffic secrets, application traffic secrets, exporter secrets, and resumption secrets. Each step includes labels and transcript hashes so keys are bound to the exact negotiation.
This design prevents one secret from silently standing in for another. A client handshake traffic key, a server application traffic key, and an exporter secret all descend from the same schedule, but their labels and transcript context keep their uses separate.
KDF implementation checklist
- Use a standardized KDF construction instead of inventing one.
- Choose HKDF or an approved PRF-based KDF for high-entropy protocol secrets.
- Choose Argon2id, scrypt, bcrypt, or PBKDF2 for passwords, with parameters tuned to current hardware.
- Include domain-separation labels and context for every derived output.
- Derive separate keys for encryption, authentication, exporters, wrapping, and traffic directions.
- Use salts or nonces as specified by the KDF and protocol, and do not treat them as secret.
- Validate output lengths and algorithm identifiers before passing derived keys to crypto APIs.
- Erase intermediate secrets where the platform makes that practical.
Mistakes that weaken key derivation
The most common mistake is using a fast protocol KDF directly on a password. HKDF can organize strong key material, but it does not make weak human input costly to guess. Another frequent problem is missing context: deriving two keys with the same input and no labels can cause accidental key reuse across algorithms or directions.
KDFs also do not fix broken key exchange, weak random number generation, or poor secret storage. They are the bridge from secret material to operational keys, not a replacement for the rest of the cryptographic design.
The practical takeaway
A key derivation function gives cryptographic systems disciplined key material: extracted, expanded, labeled, and separated for each purpose. Use HKDF for high-entropy protocol secrets, password KDFs for human-chosen secrets, and TLS-style key schedules as a model for careful context binding.
Related security terms
HMAC
A keyed hash construction commonly used as the pseudorandom function inside HKDF.
PBKDF2
An iteration-based password KDF used in many legacy and standards-driven systems.
Argon2
A memory-hard password KDF recommended for new password storage designs.
Key Exchange
The protocol step that produces shared secrets a KDF can turn into usable keys.
TLS 1.3
A modern TLS version whose key schedule relies on HKDF-derived secrets.
Frequently asked questions
What is a KDF in simple terms?
A KDF takes secret input, such as a Diffie-Hellman shared secret or a password, and deterministically produces keys that are the right size and context for a cryptographic job.
Is HKDF the same as a password KDF?
No. HKDF is designed for high-entropy input key material and structured extract-and-expand derivation. Password KDFs such as Argon2 and PBKDF2 are designed to make low-entropy password guessing more expensive.
What do extract and expand mean in HKDF?
Extract condenses input key material and optional salt into a pseudorandom key. Expand uses that pseudorandom key plus context information to produce one or more output keys.
Why does TLS 1.3 use a KDF?
TLS 1.3 uses HKDF to transform handshake secrets into separate traffic keys, IVs, exporter secrets, and resumption secrets while binding each result to the protocol transcript.
Can one derived key be reused for encryption and authentication?
Avoid reusing the same derived key across purposes. A KDF should derive separate, labeled keys so encryption, authentication, and export functions remain isolated.
Should passwords be run through HKDF?
Not by itself. Passwords usually need a password KDF such as Argon2id or PBKDF2 first because human-chosen secrets are guessable and require intentional cost.
What inputs should be domain separated in a KDF?
Include protocol labels, algorithm identifiers, party identities, transcript hashes, salts, counters, or application context as the standard permits so keys for different uses cannot collide.
References
Explore authoritative guidance and frameworks related to key derivation function (kdf).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.