Visual RFC.
ALL RFCs / RFC 5869
Read the RFC ↗
RFC 5869 / HKDF KEY DERIVATION

Context separation and security limits

06

info binds derived material to its use, but the consuming protocol still needs sound input entropy and a clear key-derivation design.

DIAGRAMRead RFC section 3.2 ↗
RFC 5869 · § 3.2EXAMPLE
3 / 3
Context separation and security limitsTwo expand calls take the same PRK and distinct fictional send and receive info inputs, then emit derived keys for separate contexts. With identical PRK and info, changing only L gives outputs with a common prefix; length is not automatically part of info. A final failure gate rejects an entropy-amplification expectation for a predictable password, not the ability to compute HKDF on those bytes. No password-guessing slowdown is specified.Context separates uses, not input entropyFictional application labels and chosen policiesPredictable passwordNew entropy?cannot amplify entropyHKDF still computes bytes for that inputNo password-guessing slowdown is addedA longer output does not fix a weak inputSecurity depends on inputs, hash assumptions and protocol use
03
Reject the expectation of password hardening.

A predictable password does not gain new entropy or a guessing slowdown merely by passing through HKDF. Choose an appropriate password-based KDF design rather than assuming a longer output fixes the input.

Source for this drawing: RFC 5869 · Read RFC section 3.2 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
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

RFC 8446 TLS 1.3 RFC 4648 Base encodings

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Terms in this drawing
Context separation
Binding key derivation to distinguishable intended uses.
Entropy
Uncertainty in the input source; length alone is not uncertainty.
Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

info is optional and may be empty, but often matters greatly for separating application contexts. It should be independent of the IKM value.

  • info is optional and may be empty, but often matters greatly for separating application contexts. It should be independent of the IKM value.
  • With the same PRK and info, different output lengths share a common prefix. If a design needs length bound into the context, encode L in info explicitly; HKDF does not do that automatically.
  • Using PRK directly as OKM is NOT RECOMMENDED because it omits info. A Diffie-Hellman IKM should go through extract (SHOULD NOT skip), while a suitable strong pseudorandom IKM can support expand-only use.
  • Extract can concentrate existing entropy, not amplify it. HKDF includes no password-guessing slowdown mechanism; it is not by itself a replacement for a password-based KDF.
DETAILS

Fictional labels send and receive are distinct UTF-8 info byte strings chosen by this example application; RFC 5869 does not prescribe their encoding or these labels. Distinct contexts support domain separation, not a mathematical guarantee that every output can never collide. Security depends on appropriate independent inputs, hash assumptions and the protocol using the derived keys.

Read the RFC section ↗

All chapters in RFC 5869

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗