PBKDF2 Generator and Key Derivation Calculator

How to use the pbkdf2 key derivation calculator

1. Enter the password. Use the format menu if you have raw bytes in hex instead of text.
2. Enter the salt as text or hex, or leave it empty to use an empty salt (not advised for real use).
3. Set the number of iterations and the derived key length in bytes, then choose the hash function.
4. Click Derive Key. The derived key appears as hex and Base64, calculated in your browser.

How PBKDF2 works

PBKDF2 (Password-Based Key Derivation Function 2) is defined in RFC 2898 and RFC 8018. It runs a pseudorandom function, normally HMAC, over the password and a salt, and repeats it for a chosen number of iterations. The repetition is the point: each guess an attacker tries costs as many hash calls as a legitimate login.

The output is built from blocks of the hash length. For block i it computes U_1 = HMAC(password, salt || INT(i)), then U_2 = HMAC(password, U_1), and so on up to U_c where c is the iteration count. The block value is the XOR of all U values. Blocks are joined and cut to the requested length, so a 32-byte key from HMAC-SHA256 is one block and a 64-byte key is two.

Choosing parameters securely

Three parameters decide how well a derived key resists guessing:

• Salt: a unique random value per password, so identical passwords give different keys and precomputed tables are useless. Use at least 16 random bytes (32 hex characters).
• Iterations: the cost factor. The OWASP Password Storage Cheat Sheet gave 600,000 for PBKDF2-HMAC-SHA256 and 210,000 for PBKDF2-HMAC-SHA512 in its 2023 revision; check the current edition before you choose. Higher is slower for attackers and for your own logins.
• Key length: do not ask for more than the hash produces (20 bytes for SHA-1, 32 for SHA-256, 48 for SHA-384, 64 for SHA-512). A longer key makes you compute extra blocks that an attacker verifying one guess can skip.

This page limits iterations to 1,000,000 (250,000 for SHA-384 and SHA-512, which are slower in a browser), so it can reproduce test vectors and moderate settings but not the very largest production costs.

RFC 6070 test vectors

RFC 6070 gives test vectors for PBKDF2 with HMAC-SHA1. Select HMAC-SHA1, enter the password and salt as text and the iteration count and length from the table, and you should get the same key. Passwords and salts here are ASCII text.

For SHA-256, RFC 7914 lists the password "passwd" with salt "salt", one iteration and a 64-byte key: 55ac046e56e3089fec1691c22544b605f94185216dde0465e68b9d57c20dacbc49ca9cccf179b645991664b39d77ef317c71b845b1e30bd509112041d3a19783.

PBKDF2 compared to other KDFs

PBKDF2 is widely supported and standardized (it is in FIPS-approved cryptography), but it is not the only option. The bcrypt generator makes hashes with the Blowfish-based bcrypt function, which includes its own salt and cost factor and needs a small block of memory that makes GPU cracking somewhat harder than plain PBKDF2.

For new systems that can choose freely, Argon2id is often preferred because it is memory-hard: you tune memory as well as time, which makes GPU and ASIC attacks far more costly. PBKDF2 remains acceptable with SHA-256 or SHA-512 and a high iteration count, and it is the right choice where compliance or platform support requires it. To get a feel for password strength, try the password entropy calculator.

Common mistakes to avoid

Several pitfalls weaken PBKDF2 implementations:

• Reusing salts: If two users share the same salt, identical passwords produce identical derived keys, enabling batch attacks.
• Too few iterations: Using 1,000 iterations was acceptable around 2000, but modern hardware can test millions of candidates per second at that cost.
• Requesting excessive key lengths: Asking for 64 bytes from HMAC-SHA256 requires two full sets of iterations. An attacker verifying a guess only needs to compute the first 32-byte block, giving them a relative speed advantage.
• Using the derived key directly as a password hash: Store the salt, iteration count and algorithm identifier alongside the key so you can verify logins later. A plain digest from the hash generator carries none of this, which is why key derivation needs it.

What this tool does not do: it does not generate a random salt for you, it does not output the PHC or modular crypt string format that password libraries store, and it does not support PBKDF2 with other pseudorandom functions such as HMAC-SHA3. It is for checking values, learning and one-off key derivation, not for hashing a user database.

Worked examples