PBKDF2 key derivation

Derive a cryptographic key from a password using PBKDF2-HMAC. Choose the hash, iterations, salt and output length — it runs in your browser, so the password never leaves your device.

Derived key

About this tool

PBKDF2 (Password-Based Key Derivation Function 2, defined in RFC 2898 and RFC 8018) stretches a password into a fixed-length cryptographic key by applying an HMAC hash many times over. This tool runs PBKDF2-HMAC entirely in your browser using compiled Rust (WebAssembly) — your password and salt are never sent anywhere.

Inputs

The result is deterministic: identical inputs always produce the same derived key, so you can reproduce a key on any device or platform that implements PBKDF2.

Verify mode

Set Mode to verify and paste an existing key (hex or base64) into Expected key to check whether your password and parameters reproduce it. The expected key's byte length sets the derived length automatically, and the comparison runs locally.

Common uses

Notes on security

PBKDF2 is widely supported and FIPS-approved, but it is not memory-hard. For new password-storage designs, a memory-hard function such as Argon2id or scrypt resists GPU/ASIC attacks better. Whatever you choose, always use a unique random salt and the highest iteration count your latency budget allows.

Test vectors

This tool matches the published PBKDF2 test vectors (RFC 6070 for HMAC-SHA1 and RFC 7914 for HMAC-SHA256), so its output is interoperable with standard libraries.

FAQ

My key doesn't match another library — what's different?

PBKDF2 output depends on every parameter: password, salt (and how the salt bytes are decoded), iteration count, HMAC hash and key length. A mismatch is almost always one of these — most often the salt encoding (this tool defaults to treating the salt as UTF-8 text; set it to hex or base64 if the other side used raw bytes) or a different iteration count.

How do I verify a password against an existing key?

Switch Mode to verify and paste the existing key (hex or base64, auto-detected) into Expected key. The tool derives with your password and parameters and compares — the expected key's byte length automatically sets the derived length, so you don't have to enter it. Everything runs locally.

What limits are there on iterations and key length?

Iterations must be at least 1 (there's no upper cap — very high counts just take longer, since the work runs in your browser), and the derived key length is 1 to 1024 bytes. The default is 100,000 iterations and a 32-byte (256-bit) key; OWASP currently suggests ~600,000 for PBKDF2-HMAC-SHA256.

Should I use PBKDF2 or Argon2 for new password storage?

PBKDF2 is widely supported and FIPS-approved, but it isn't memory-hard, so it's weaker against GPU/ASIC cracking. For a brand-new design prefer a memory-hard function like Argon2id or scrypt. Whatever you pick, always use a unique random salt and the highest iteration count your latency budget allows.

Developer & Automation Access

Run it from the terminal

Same engine as this page, headless — via the gizza CLI:

gizza tool pbkdf2-derive "The password / passphrase"

New to the CLI? Get gizza →

Open it by URL

Pre-fill and auto-run this tool with query parameters — the names match the API/CLI:

https://gizza.ai/tools/pbkdf2-derive/?password=The%20password%20%2F%20passphrase&mode=derive&salt=Unique%20random%20salt%20%28recommended%29&salt_encoding=utf8&iterations=100000&hash=sha256&length=32&encoding=hex&expected=hex%20or%20base64%20key%20to%20check%20against

Machine-readable descriptor: tool.json — title + parameters JSON Schema for agents.