Key points
- Extract normalizes possibly non-uniform input keying material.
- Expand derives the requested output and binds it to an info context.
- Different context labels provide domain separation between key purposes.
- HKDF is not a password hash and should not replace Argon2id for low-entropy passwords.
Extract, then expand
HKDF-Extract takes input keying material and an optional salt, then produces a fixed-length pseudorandom key. HKDF-Expand takes that key, an info value, and a requested length to produce output keying material. [1]
The info field should describe the application and purpose. Deriving “workspace-content” and “membership-proof” with distinct labels helps ensure that a key used in one context cannot be substituted into another.
Salt and info do different jobs
A salt strengthens extraction and can make outputs independent across contexts; it does not need to be secret. The info value binds output keys to context and should be independent of the input keying material. Neither is a substitute for high-entropy input or correct protocol design. [1]
Where HKDF fits in an encrypted application
A system can start with one high-entropy root key and derive separate keys for content encryption, search, membership proofs, or record classes. This reduces key storage and creates explicit separation. The hierarchy must still define rotation, versioning, labels, and compromise boundaries.
HKDF is fast by design. That makes it appropriate for cryptographic keys and inappropriate as the only defense for a human password, which needs a deliberately expensive password-hardening function.
Common questions.
Is HKDF encryption?
No. HKDF derives key material. An encryption algorithm such as an AEAD then uses a derived key to protect messages.
Does HKDF salt need to be secret?
No. RFC 5869 states that salt adds significant strength but is a non-secret value. It should be independent of the input keying material. [1]
Can HKDF turn a password into an encryption key?
HKDF alone is too fast for that job. First use a password-hardening function designed for low-entropy inputs, then use a KDF as required by the protocol.
Primary sources
Definitions prefer standards bodies, government guidance, and the first-party SealTask architecture. Links open the complete source.
- 01 RFC 5869: HMAC-based Extract-and-Expand Key Derivation Function The HKDF specification and extract-then-expand design.
- 02 RFC 2104: HMAC The standard construction for keyed hashing and message authentication.
- 03 SealTask security architecture Product-specific encryption boundary, server visibility, protocols, and current limitations.