Contents

HkdfEdit

HKDF

HKDF, or HMAC-based Extract-and-Expand Key Derivation Function, is a widely used construction for turning a source of input keying material into cryptographically strong keys for various purposes. It was standardized to provide a clean, portable way to derive multiple keys from a single secret while keeping the different derived keys well separated by context. The method is built on the well-understood building blocks of HMAC and hash functions, and it is designed to work with any hash function that HMAC supports.

In practice, HKDF is valued for its simplicity and interoperability. It is used in many modern cryptographic stacks and protocols, including TLS and other secure communications systems, because it provides a reliable method to obtain fresh keys for different sessions or subsystems from a common secret. The standardization and widespread adoption make HKDF a dependable choice for developers who need a robust key-derivation mechanism that can be implemented consistently across platforms. See RFC 5869 for the formal specification and the rationale behind the construction.

Overview

  • Core idea: derive cryptographic keys from input keying material (IKM) through two clear phases, Extract and Expand.
  • The Extract phase uses HMAC with a salt to turn possibly weak or low-entropy IKM into a pseudorandom key (PRK). The salt helps ensure that even identical IKM values produce different PRKs across contexts; when a salt is not provided, a default value of a fixed length (matching the hash output) is used.
  • The Expand phase takes the PRK and, with a context-specific info string, produces one or more output keying material values (OKM). The process can generate as many derived keys as needed, up to the hash function’s limits, while preserving key separation via the info parameter.
  • The security of HKDF derives from the security properties of HMAC as a pseudorandom function (PRF) and from careful composition of Extract and Expand steps. See HMAC, Pseudorandom function, and Hash function for related concepts.

The standard formulation is described in RFC 5869 and relies on a hash function such as SHA-256 or SHA-384 as the underlying primitive. The general pattern is compatible with the common notion of key derivation functions (KDFs) and is distinct from password-based schemes like PBKDF2, as HKDF is designed to work with high-entropy secret material rather than user passwords.

Construction

  • Extract: PRK = HMAC(salt, IKM)
    • Salt is typically a random value of the same length as the hash output, serving as a strong, unique key for the HMAC in this step.
    • If salt is omitted, a deterministic placeholder is used, which remains secure only if the IKM has sufficient entropy on its own.
    • This step converts the potentially low-entropy IKM into a fixed-length pseudorandom key.
  • Expand: T(1) = HMAC(PRK, info || 0x01)
    • For i > 1: T(i) = HMAC(PRK, T(i-1) || info || i)
    • The OKM (output keying material) is formed by concatenating T(1), T(2), …, T(n) and truncating to the desired length L.
    • The info parameter provides application-specific context, enabling secure separation of keys derived for different uses from the same PRK.
  • The hash function choice (e.g., SHA-256 or SHA-384) determines the length of each T(i) block and the overall security level.

This two-stage design makes HKDF flexible: the same PRK can be used to derive multiple keys for distinct purposes while still maintaining separation via the info field. See also Key derivation function for a broader context of how HKDF fits into cryptographic key management.

Security considerations

  • Entropy in IKM: The starting material should have sufficient entropy. HKDF does not compensate for weak or predictable IKM; if the IKM is poorly random, the derived keys will be too.
  • Salt selection: A high-quality, unpredictable salt in the Extract step strengthens the security of the PRK and helps prevent key reuse across contexts. When a salt is not used, the strength relies more heavily on the entropy of the IKM and the hash function.
  • Info parameter: The info field provides context and application-specific separation. Using different info values for different derivations helps ensure that keys derived from the same PRK remain distinct.
  • Hash function choice: The security properties of HKDF closely track the underlying hash function and the security of HMAC with that hash. Using modern, collision-resistant hashes (such as SHA-256 or SHA-384) is standard practice in current protocols.
  • Implementation considerations: Care must be taken to avoid truncation issues and to ensure that the derived length L does not exceed the protocol’s or library’s supported limits. Implementations in libraries like OpenSSL or libsodium provide tested HKDF routines that follow the RFC 5869 design.

Practical usage

  • Protocols: TLS 1.3 uses HKDF in its key schedule to derive handshake and session keys, often in conjunction with hash-based parameters. See TLS 1.3 for concrete usage patterns in secure communications.
  • Libraries and tooling: Many cryptographic libraries expose an HKDF interface that accepts the hash function, salt, IKM, info, and the desired output length. Examples include OpenSSL, libsodium, and other cryptographic toolkits.
  • Contextual applications: HKDF can be employed to derive multiple symmetric keys from a single secret for use in different algorithms or network channels, while keeping the keys context-separated via the info parameter.

Variants and related constructions

  • HKDF-Extract and HKDF-Expand: The two distinct phases of the overall HKDF construction, sometimes discussed individually in implementations.
  • Relationship to other KDFs: HKDF sits alongside other KDF families, each with its design goals. Unlike password-based schemes, HKDF is not intended as a memory-hard function; it is optimized for scalable, context-aware key derivation from high-entropy material. See Key derivation function for comparisons.
  • Alternatives in practice: While HKDF is common, some systems may use other KDFs or PRFs depending on constraints, such as password-authenticated key exchange protocols or system-specific security requirements.

See also