Guide
PBKDF2 and HKDF: deriving keys from passwords and secrets
People pick passwords that are short and guessable, while encryption algorithms need keys that are long and random. A key derivation function bridges the gap. PBKDF2 stretches a password by repeating a keyed hash many thousands of times, so that each guess costs an attacker real work. HKDF does a different job: it takes a secret that is already random, for example the output of a key exchange, and expands it into several independent keys. This page runs both, so you can reproduce a result from your own code.
How PBKDF2 works
PBKDF2, defined in RFC 8018, computes HMAC of the password with the salt and a block counter, then feeds the result back through HMAC for the chosen number of iterations, XORing all the intermediate values together. The output is as many bytes as you ask for. Because the work grows with the iteration count, a count of 600,000 makes a single guess roughly 600,000 times more expensive than one hash. The salt must be random and unique per password.
Checking a result
Press Sample and the page sets the password password, the salt salt, 4096 iterations and 20 bytes with HMAC-SHA-1. The derived key is 4b007901b765489abead49d926f721d065a429c1 in hex, or SwB5AbdlSJq+rUnZJvch0GWkKcE= in Base64. That is one of the test vectors in RFC 6070, and it matches the result of Node’s built-in crypto library for the same inputs. If your library gives the same value for the same inputs, its byte handling is right.
Iteration counts
Hardware gets faster, so the guidance rises. OWASP’s password storage advice from 2023 lists 1,300,000 iterations for PBKDF2 with HMAC-SHA-1, 600,000 with HMAC-SHA-256 and 210,000 with HMAC-SHA-512. The page shows a note with the figure for the hash you choose. For derivation from an already strong secret, a few thousand iterations or even one are acceptable, since there is nothing to guess.
HKDF
Switch to the HKDF tab for RFC 5869. Extract takes the optional salt and the input key material and produces a fixed-size pseudorandom key; expand turns that key and an “info” label into as many bytes as you need. Use a different info string for each purpose, such as “app v1 encryption key” and “app v1 mac key”, and you get unrelated keys from one secret. HKDF is deliberately fast, so it does not protect weak passwords.
Limits
Timing shown by the page reflects your browser and device, not a server. Very large iteration counts can freeze a slow phone for several seconds. PBKDF2 is not memory-hard, so GPUs run it efficiently; where you have the choice, Argon2id or scrypt resists them better.
Storing the result
A stored PBKDF2 password record should carry four things: the algorithm name, the iteration count, the salt and the derived key. Many systems write them in one string such as pbkdf2_sha256$600000$salt$hash, so the count can be raised later without breaking old records: when a user logs in with the right password, rehash it with the new count and replace the entry. Compare derived keys with a constant-time comparison, never with a plain equality test that stops at the first difference.
Related tools
- HMAC Generator shows the building block under both functions.
- Bcrypt Hash Generator is the slow password hash used by many frameworks.
- AES Encryptor and Decryptor uses PBKDF2 to turn a passphrase into a key.
- Password Strength Checker estimates how long a password would resist guessing.
Checked against the current version of the PBKDF2 and HKDF Calculator on .