The Complete KDF Key Derivation Guide

A Key Derivation Function (KDF) is a family of cryptographic algorithms that transform a "seed secret" of arbitrary length (a user password, a DH shared value, or a master key) into one or more fixed-length, high-entropy keys. The general form can be written as DK = KDF(Password, Salt, Cost, Length), where DK stands for Derived Key.

The need for KDFs arises from the structural gap between real-world secrets and the requirements of cryptographic primitives:

• Length gap: AES-256 requires exactly 32 bytes of key material, while user passwords are typically only 8-16 ASCII characters.
• Entropy gap: even a "strong" password has far less entropy than a uniformly random 32-byte key (approximately 256 bits).
• Structure gap: human-generated passwords have dictionary patterns, keyboard-neighborhood biases, and predictable character sets, making them easy targets for brute-force search when used as keys directly.

A KDF's core value is bridging these gaps: it stretches a low-entropy, variable-length, human-readable password into a high-entropy, fixed-length, unpredictable binary key. In doing so, a KDF must satisfy two seemingly contradictory goals: one-wayness (the password cannot be recovered from DK) and determinism (the same inputs always produce the same output). Our tool supports four mainstream KDFs so you can compare them side by side.

Early systems often stored plaintext passwords or a single MD5 / SHA-1 hash. Both practices are dangerous today because they fail against two classic attacks:

1. Rainbow Table Attack: an attacker precomputes hashes for huge password dictionaries and builds a "hash → plaintext" lookup table. Once a hash file is leaked, the attacker simply looks up the original password. The defense is unique, random per-user salts—each user gets a distinct random salt so the precomputation has to be repeated per record, making rainbow tables infeasible in storage terms.

2. Offline Brute-force Attack: once an attacker obtains the hash file, they can throw GPU / ASIC farms at it at billions of attempts per second. Modern GPUs can exceed 10^9 SHA-256 hashes/s. To defeat this, a KDF must make each attempt computationally expensive—for example, 100,000 iterations per attempt—which reduces guess rates from billions to thousands and stretches the attack time from seconds to days or years.

Thus, a KDF's strength hinges on two factors: salt randomness and computational cost. The following sections discuss each algorithm's behavior in detail and include recommended parameters from OWASP, NIST, and PHC.

PBKDF2 (Password-Based Key Derivation Function 2, RFC 2898 / PKCS #5 v2.0) is the most widely deployed KDF today. It works by iterating an HMAC function N times and combining intermediate results to produce a key of the requested length. Its key parameters are:

• Iterations (c): NIST SP 800-132 recommends at least 1,000; the 2023 OWASP cheatsheet recommends no fewer than 100,000 with SHA-256.
• Hash Algorithm (PRF): typically HMAC-SHA-256 or HMAC-SHA-512. Avoid SHA-1 / MD5.
• Salt: at least 128 bits (16 bytes), generated with a cryptographically secure random generator each time.
• Derived Key Length (dkLen): 16, 32 or 64 bytes are the most common, depending on target cipher.

HKDF (HMAC-based Key Derivation Function, RFC 5869) addresses a different problem: once you already have a high-entropy shared secret (e.g. DH / ECDH output, or a seed from a CSPRNG), HKDF derives multiple independent sub-keys from it. It works in two steps:

• Extract: use the salt to HMAC the input keying material, producing a fixed-length pseudo-random key (PRK).
• Expand: use PRK as the HMAC key, then derive N = ceil(L/HashLen) consecutive blocks to produce the output keying material (OKM).

A common mistake is using HKDF to strengthen weak passwords directly. Because HKDF is fast by design, it is not suitable for password hardening. The correct composition chain is: Password → PBKDF2 / Argon2 → Master Key → HKDF → multiple service sub-keys. In our tool, you can simulate this pipeline by first deriving a master key with PBKDF2, then pasting it into HKDF mode with different info labels to produce multiple independent sub-keys.

Even at millions of iterations, PBKDF2 remains CPU-cost only. Modern GPUs and ASICs can compute SHA-256 in parallel at 1,000× the speed of a CPU. To break this asymmetry, cryptographers introduced the "memory-hard" paradigm: each derivation must consume large amounts of randomly-accessed RAM so attackers cannot simply parallelize.

Scrypt (Colin Percival, 2009 / RFC 7914) was the first practical memory-hard KDF. It has three parameters:

• N: memory cost factor (must be a power of two; typically 16,384 ~ 1,048,576).
• r: block size (usually 8).
• p: parallelism factor (usually 1; higher p increases CPU cost without extra RAM).

Scrypt's approximate memory usage is 128 × N × r bytes. With N=16384 and r=8 it uses ~16 MiB; with N=1,048,576 it requires ~1 GiB, which is prohibitively expensive for a large-scale attacker.

Argon2 (PHC 2015 winner) pushed memory-hard KDF design to the contemporary state of the art. It has three variants:

• Argon2d: best GPU/ASIC resistance but potentially vulnerable to side-channel timing attacks (used in crypto mining).
• Argon2i: safest against side-channel attacks; the classic recommendation for password storage.
• Argon2id: hybrid (d then i); the current OWASP #1 recommendation for password hashing.

Argon2's main parameters are t (time cost / iterations, typically 1-3), m (memory cost in KiB, recommended 64 MiB+), p (parallelism, typically 1 or 4), and output length (typically 32 bytes). The OWASP 2024 recommendation for Argon2id is t=3, m=65536, p=4; for constrained environments, t=2, m=37000, p=1. If Argon2 is unavailable, fall back to Scrypt (N=32768, r=8, p=1) or PBKDF2 (SHA-256, c ≥ 600,000). In our KDF tool you can switch among these algorithms and immediately feel the difference in derivation speed.

Choosing the right algorithm is only half the battle; salt handling and parameter tuning often decide real-world security. Here is an actionable checklist:

1. Three Golden Rules of Salt

• Unique: generate a new salt for each user / each derivation; never re-use a salt across records.
• Unpredictable: use a CSPRNG (e.g. the browser's crypto.getRandomValues or Node.js crypto.randomBytes) and generate at least 16 bytes.
• Stored separately from the key: salt doesn't need confidentiality, but it must be persisted together with the derived key; never concatenate password and salt into a single string before hashing (this defeats per-record uniqueness).

2. Parameter Selection

• Benchmark in your target environment: tune parameters so a single derivation takes 100 ms ~ 1,000 ms for interactive login / registration flows, or 1 s ~ 5 s for backup encryption / disk encryption flows.
• With Argon2, it is common to fix memory m (e.g., 64 MiB) and parallelism p (e.g., 4), then raise t until the derivation hits your target latency.
• Consider peppering (aka "secret pepper"): mix a server-side secret (not stored in the DB) with the password inside the KDF. Even if the database leaks, the attacker lacks the pepper and cannot brute force.

3. Agility and Upgradeable Storage

Use a structured string format similar to the PHC / modular crypt format, e.g. $argon2id$v=19$m=65536,t=3,p=4$salt_b64$dk_b64. Storing parameters alongside the derived key lets you upgrade them transparently: existing records can be re-hashed with stronger parameters on the user's next login, without invalidating old records.

Here are four canonical patterns for using KDFs in production systems. They'll help you choose and combine algorithms more systematically.

1. Server-Side Password Hashing

Most web applications store passwords using BCrypt / Scrypt / Argon2. Recommended preference order: Argon2id → Scrypt → BCrypt → PBKDF2 + HMAC-SHA-256. Note: PBKDF2's security depends heavily on iteration count and whether a server-side pepper is applied; prefer Argon2id in new systems.

2. Full-Disk Encryption (FDE)

BitLocker, VeraCrypt and LUKS all use KDFs to derive volume master keys from the user passphrase. The typical pipeline is: passphrase → KDF (Argon2 / Scrypt / PBKDF2) → volume master key → XTS-AES for sector encryption. Parameters here are intentionally very slow (seconds per derivation) because the user boots infrequently, while the attacker can only attempt offline brute-force.

3. HKDF in Key Agreement Protocols

After completing an ECDHE / X25519 handshake, TLS 1.3, Signal and WireGuard all use HKDF to "expand" the shared secret into multiple independent sub-keys (client traffic key, server traffic key, IVs, Finished MAC key, etc.). The key benefit is isolation: compromising a sub-key does not allow backtracking to the shared secret or other sub-keys.

4. Master Key → Multiple Service Keys

Large systems often keep an offline "master key" and use HKDF with different service labels (the info parameter) to derive independent sub-keys for payment, user authentication, messaging encryption, etc. The advantage: the master key stays offline; sub-keys are isolated from each other, so compromising one sub-key does not leak others. You can simulate this pipeline in our tool: first derive a master key with PBKDF2, then paste it into HKDF mode with different info labels to derive multiple independent service sub-keys.

The inputs to KDF derivation—passwords, shared secrets, salts—are among the most sensitive pieces of data. Sending them to a remote server essentially hands the "keys to the kingdom" to a third party. Even with a "we don't store your data" promise, there are transport logs, access logs, monitoring and other leak surfaces.

For that reason, every computation in this tool runs locally in your browser:

• PBKDF2 and HKDF: computed by the browser's standard Web Crypto API, which is audited by each browser vendor.
• Scrypt and Argon2id: implemented in pure JavaScript using open-source cryptography libraries (such as noble-hashes), no network round-trip.
• No input is persisted to localStorage or copied to the clipboard (unless you explicitly click "copy"). Everything is cleared when you refresh the browser.

For offline or production use, we recommend: open the page, disconnect the network, or deploy the HTML files locally. That way, even if your browser has remote code or extensions, they cannot exfiltrate your password material.

One final principle: when evaluating a KDF tool, verify that it does not invent new cryptographic primitives, does not rely on weak hashes, and lets you tune all critical parameters. Our source code, dependencies and documentation follow this rule. Feel free to cross-check against the KDF tool page and the related guides.