Extract first, then expand
01HKDF turns input keying material into a pseudorandom key, then derives the requested output material from that key.
Expand uses PRK as the HMAC key, info as context and L as the output length. This is a separate stage from extract.
Source for this drawing: RFC 5869 · Read RFC section 2.2 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
- IKM
- Input keying material: the initial source of key material.
- PRK
- Pseudorandom key: the intermediate key used by expand.
- OKM
- Output keying material: the derived bytes.
- HMAC
- A keyed message-authentication function built from a hash.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Extract computes PRK = HMAC-Hash(salt, IKM). Salt is the HMAC key; input keying material IKM is the HMAC message, not the key.
- Extract computes PRK = HMAC-Hash(salt, IKM). Salt is the HMAC key; input keying material IKM is the HMAC message, not the key.
- PRK is HashLen octets. Expand takes a pseudorandom key of at least HashLen octets, context info and a requested output length L, then produces L octets of OKM.
- Hash is a selected cryptographic hash underlying HMAC. The examples use SHA-256, where HashLen is 32 octets; the RFC does not mandate that every application use SHA-256.
- When IKM is already a suitable strong pseudorandom key, extract may be skipped. For a Diffie-Hellman value, extract SHOULD NOT be skipped (§3.3).
HKDF is a local computation, not a network exchange, encryption algorithm or source of fresh entropy. Each arrow carries an input or output of the indicated computation. A consuming protocol chooses parameters and how to split/use output keys. Using PRK directly as OKM is NOT RECOMMENDED, including when L is at most HashLen, because it omits info from the derivation.
Read the RFC section ↗