HKDF Key Deriver
Derive keys from high-entropy material using HKDF.
Overview
The HKDF key deriver expands one chunk of high-entropy keying material into one or more cryptographically independent keys. Paste your input keying material (an ECDH shared secret, a random buffer, a master key), supply an optional salt and info, choose a hash, and receive a derived key of any length you specify.
It is the standard tool for protocol designers, TLS 1.3 implementers, and anyone who needs to turn one shared secret into key, IV, and MAC keys without weakening the underlying entropy. An HKDF online tool also helps when you are debugging a mismatch between an implementation and an RFC 5869 test vector.
How it works
HKDF (HMAC-based Key Derivation Function, RFC 5869) is a two-step extract-and-expand construction. The extract step computes PRK = HMAC(salt, IKM) to consolidate input keying material into a pseudo-random key. The expand step iteratively produces output blocks: T(1) = HMAC(PRK, info || 0x01), T(i) = HMAC(PRK, T(i-1) || info || i). The final output is the concatenation of T(1) || T(2) || ... truncated to the requested length. The hash function (typically SHA-256 or SHA-512) determines block size and a maximum output of 255 × hash-output-size bytes.
Examples
IKM: 0b0b0b0b0b0b0b0b0b0b0b
Salt: 000102030405060708090a0b0c
Info: f0f1f2f3f4f5f6f7f8f9
Hash: SHA-256
Len: 42
Output: 3cb25f25faacd57a90434f64d0362f2a2d2d0a90cf1a5a4c5db02d56ecc4c5bf34007208d5b887185865
IKM: secretsharedsecret
Salt: ""
Info: "session-key"
Hash: SHA-256
Len: 32
Output: a4f7... (32 bytes hex)
IKM: ecdh-shared-secret-bytes
Info: "tls13 client handshake traffic"
Hash: SHA-384
Len: 48
Output: ... (48 bytes hex)
FAQ
Why two steps?
The extract step handles inputs that are not uniformly random (like an ECDH shared secret, which sits on an elliptic curve and is not uniformly distributed). The expand step then stretches the now-uniform PRK into as many bytes as you need.
Do I need a salt?
A non-empty random salt strengthens HKDF when the input keying material has structure or is partially predictable. For high-entropy inputs you can omit it (RFC 5869 defines a zero-byte default).
What goes in info?
Context-specific data that binds the derived key to its purpose: protocol label, session ID, party identities. Different info values with the same PRK produce independent keys.
Can I use HKDF as a password hash?
No. HKDF is fast and assumes the input already has high entropy. For passwords use PBKDF2, scrypt, bcrypt, or Argon2.