Derive cryptographic keys from passwords using PBKDF2 with configurable iterations, salt, and hash algorithm.
PBKDF2 (Password-Based Key Derivation Function 2, specified in PKCS #5 / RFC 8018) converts a password into a fixed-length cryptographic key. It combines the password with a salt, then applies HMAC with your chosen hash algorithm (SHA-1, SHA-256, SHA-512) repeatedly, a configurable number of times; the iteration count is the work factor that makes guessing expensive. The tool runs that computation in your browser and returns the key as hexadecimal. What surprises most users: the result is deterministic and one-way. Identical inputs always produce identical output, but the key cannot be decrypted back into the password, and changing any single parameter produces a different result.
A concrete input and expected output from the current implementation.
Input
password: password | salt: salt | iterations: 4096 | hash: SHA-1 | output length: 20 bytes
Expected output
4b007901b765489abead49d926f721d065a429c1
This is test case 3 in RFC 6070, the standard conformance suite for PBKDF2: password "password", salt "salt", 4096 iterations, HMAC-SHA-1, 20-byte output. Because the derivation is deterministic, the tool reproduces the published vector byte for byte; changing any parameter changes the entire string.
PBKDF2 generates the key in blocks. For block index i, it computes HMAC over the salt with a 4-byte counter appended, using the password as the HMAC key, then feeds the result back through HMAC again for c iterations total. The block is the XOR of all c intermediate values; blocks are concatenated to the requested length and truncated. Cost scales linearly with the iteration count.
The output is a pure function of five values: password, salt, iteration count, hash algorithm, and output length. No randomness is involved, so identical inputs always yield identical keys, and any change scrambles the entire result. The salt must be stored alongside the derived key if the key is to be reproduced, and a unique salt per password keeps equal passwords from deriving equal keys across users or records.
No. PBKDF2 is a one-way derivation, not encryption; no inverse operation exists. Even with the salt and iteration count, the password cannot be recovered from the key. Verification works by re-running the derivation with a candidate password and comparing the hex output exactly - one guess at a time, which is why iteration count matters.
Each iteration is a complete HMAC computation, and PBKDF2 chains them in sequence, so doubling iterations roughly doubles the run time. That deliberate cost is the security property: an attacker pays it for every password guess. Tools that derive keys with a few iterations are fast but weak; current guidance puts the count in the hundreds of thousands.
The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.
Generate strong, random passwords with customizable length, character sets, and complexity requirements.
Analyze password strength with entropy scoring, crack-time estimates, and improvement suggestions.
Create cryptographically random strings for API keys, tokens, salts, and unique identifiers.
Create QR codes for URLs, text, Wi-Fi credentials, vCards, and more with customizable size and colors.
Scan and decode QR codes from uploaded images or your device camera to extract embedded data.
Compute MD5, SHA-1, SHA-256, and SHA-512 checksums to verify file integrity and detect tampering.