HKDF Key Derivation Tool

HKDF (HMAC-based Key Derivation Function) is a cryptographic key derivation function defined in RFC 5869. It takes a master secret (IKM), an optional salt, and an optional context string (Info), and produces one or more cryptographically strong derived keys. HKDF uses a two-step extract-then-expand construction: the extract step produces a pseudorandom key (PRK) from the IKM and salt, and the expand step generates the desired number of output bytes from the PRK and Info. HKDF is widely used in modern cryptographic protocols including TLS 1.3, Signal, WireGuard, IPsec, and SSH.

HKDF is designed specifically for key derivation, whereas hashing (SHA-256, SHA-512) is designed for data integrity. Raw hashing of a master key produces outputs that lack key separation, domain separation, and cryptographic independence. HKDF's extract-then-expand construction ensures that: (1) Different Info parameters produce independent derived keys, (2) Even weak IKM benefits from the salt's randomness, (3) The output length is variable and validated, and (4) The derived keys maintain the full security of the HMAC construction. Hashing a master key directly is not a safe key derivation strategy.

HKDF and PBKDF2 serve different purposes. HKDF is designed for key derivation from a cryptographically strong master secret (e.g., a Diffie-Hellman shared secret or a securely generated key). PBKDF2 is designed for password-based key derivation, using a configurable iteration count to slow down brute-force attacks. HKDF is fast (no iteration count), making it unsuitable for password storage but ideal for protocol-level key derivation where the master secret already has high entropy. PBKDF2 is slow by design, making it suitable for deriving keys from human-memorable passwords. Use HKDF when you already have a strong secret; use PBKDF2 (or better, Argon2) for password hashing.

HKDF and Argon2 serve fundamentally different purposes. HKDF is a key derivation function designed to derive multiple cryptographic keys from a single high-entropy master secret. It is intentionally fast and efficient because the master secret already has sufficient entropy. Argon2 is a memory-hard key derivation function (password hash) designed to resist GPU and ASIC brute-force attacks by requiring significant memory and computation. Argon2 won the Password Hashing Competition and is the recommended choice for password hashing and key derivation from passwords. HKDF is the recommended choice for protocol-level key derivation where the input already has high entropy (e.g., ECDH shared secrets, pre-shared keys).

In HKDF, the salt is an optional but strongly recommended random input that adds entropy to the key derivation process. The salt is mixed into the extract step via HMAC, ensuring that even if the same IKM (Input Keying Material) is used multiple times, different derived keys are produced (as long as the salt is different). The salt does not need to be secret, but it should be unique per derivation context. Best practice is to use a random salt of at least 16 bytes. In TLS 1.3, the salt is derived from the Diffie-Hellman shared secret negotiation.

The Info parameter (also called context or application-specific information) is an optional string that provides domain separation in HKDF's expand step. By using different Info values, you can derive multiple independent keys from the same IKM and salt — each Info value produces a completely different derived key. For example, you might use Info='encryption' for an AES key, Info='authentication' for an HMAC key, and Info='signing-1' for a signing key — all from the same IKM. Info is included in the HMAC computation, so derived keys are cryptographically bound to their context.

This HKDF generator supports SHA-256, SHA-384, and SHA-512. SHA-256 is the default and recommended choice for most applications, providing a 256-bit security level with optimal performance. SHA-384 and SHA-512 provide higher security margins (384-bit and 512-bit respectively) but produce larger derived keys. The hash algorithm determines the maximum output length: SHA-256 supports up to 255×32 = 8160 bytes, SHA-384 up to 255×48 = 12240 bytes, and SHA-512 up to 255×64 = 16320 bytes. All three algorithms are NIST-approved and widely supported.

Yes. HKDF is the recommended method for deriving AES keys from a shared secret. To derive an AES-128 key, set the derived key length to 16 bytes (128 bits). For AES-192, use 24 bytes. For AES-256, use 32 bytes. Use a unique salt per session and meaningful Info values (e.g., 'AES-256-GCM-Encryption') to ensure key separation. The derived bytes are suitable for direct use as AES key material. Always include a unique salt to prevent key reuse across sessions.

Yes. This tool uses the Web Cryptography API's native HKDF implementation, which is the same FIPS-compliant cryptographic primitive used by browsers for TLS 1.3, Web Authentication (WebAuthn), and Encrypted Media Extensions (EME). The implementation follows RFC 5869 exactly — there is no custom cryptographic code, no polyfills, and no third-party libraries. All processing happens in your browser: your IKM, salt, Info, and derived keys never leave your device. FreeDeskTools never receives, stores, or transmits any cryptographic material.

No. This HKDF tool performs all cryptographic operations locally using your browser's native Web Crypto API. Your Input Keying Material (IKM), Salt, Info, and derived keys never leave your device. FreeDeskTools never receives, stores, or transmits any cryptographic material. There are no server requests, no logging, no telemetry related to your inputs, and no analytics that track your keys. Only anonymous usage events (e.g., 'Generate Key clicked') are tracked for site improvement.

Yes, with appropriate precautions. The tool uses the browser's native Web Crypto API HKDF implementation which is RFC 5869 compliant and suitable for production key derivation. However, you should: (1) Always verify the derived key using test vectors, (2) Use strong random salts (at least 16 bytes), (3) Ensure your IKM has sufficient entropy (at least 128 bits for AES-128, 256 bits for AES-256), (4) Never use derived keys in production without proper testing, (5) Consider the security implications of deriving keys in a browser environment (e.g., other extensions, compromised browser). For high-security production environments, consider using a dedicated cryptographic library or HSM.

RFC 5869 is the official IETF specification for HKDF (HMAC-based Key Derivation Function), published in May 2010. It defines the extract-then-expand construction: the extract step (HKDF-Extract) applies HMAC with the salt to the IKM to produce a pseudorandom key (PRK), and the expand step (HKDF-Expand) uses the PRK with the Info parameter in an HMAC-based counter mode to produce the desired output length. RFC 5869 is widely implemented and is used in TLS 1.3 (RFC 8446), IPsec (RFC 7296), SSH (RFC 4253), Signal Protocol, WireGuard, and WPA3. The Web Crypto API's HKDF implementation follows RFC 5869 exactly.

Your master key (IKM) should have at least as many bits of entropy as the security level you need. For AES-128, the IKM should have at least 128 bits (16 bytes) of entropy. For AES-256, at least 256 bits (32 bytes). The IKM can be any length, but longer keys (e.g., 64 bytes) provide additional security margin. If your IKM is a shared secret from Diffie-Hellman key exchange, it should be at least 256 bits for Curve25519 or 3072-bit DH. If you're using a password as IKM, use PBKDF2 or Argon2 instead of HKDF — HKDF is not designed for low-entropy inputs. Always use a random salt of at least 16 bytes.