PBKDF2 benchmark

Run the benchmark

This runs the browser's own PBKDF2 on a fixed test string and sends nothing anywhere. It takes a few seconds and may make your fan spin.

This PBKDF2 benchmark times your own device doing the key stretching cipher.ink uses, at four iteration counts, so you can see what 600,000 rounds actually costs. It runs the browser's real PBKDF2 on a fixed test string and reports the median of several runs. Nothing is sent anywhere, and it takes a few seconds.

What you're measuring

PBKDF2 turns a passphrase into an encryption key by running a keyed hash, HMAC-SHA256, over it again and again. The number of repetitions is the iteration count, and it works as a dial for effort. Each repetition is cheap, but 600,000 in a row cost a fixed, measurable amount of time that nobody can skip, because every round needs the output of the one before. The button above runs the real thing through crypto.subtle.deriveBits at four settings. The test string isn't your data, and the result depends on your device. A recent laptop typically takes somewhere between 50 and 300 ms for 600,000 rounds, and a phone can take several times longer.

This is the same operation cipher.ink performs when you seal or open a passphrase message. It uses PBKDF2-HMAC-SHA256 with 600,000 iterations and a fresh random 16-byte salt, so the time you see here is the extra wait before unsealing. The PBKDF2 article shows how it fits into the message format.

Why a guesser pays more than you do

You wait once, to open your own message with the right passphrase. Someone guessing the passphrase has to run the same 600,000 rounds for every guess, so their time grows with the number of guesses. Your cost is a fraction of a second. A guesser trying one billion guesses at your device's speed would need about 4.8 years of single-core time, at 150 ms a guess. Real attackers don't use your laptop, of course. Graphics cards do the same work thousands of times faster, which is why the crack-time estimator counts their speed using a published benchmark. The point of the iteration count is to move the exchange rate between your wait and their effort, and the table shows how it grows. 600,000 rounds costs 600 times what 1,000 does.

How the count was chosen

For PBKDF2-HMAC-SHA256, OWASP's Password Storage Cheat Sheet currently recommends 600,000 iterations, and that's what the compose page uses. The recommended number rises as hardware improves, which is why the count is stored with every hash. The best figure is the highest you can afford without annoying your user, which for a website is usually a few hundred milliseconds of server time. A message opened a few times can easily absorb a fraction of a second, so cipher.ink uses the OWASP figure outright. The count is recorded inside each message (it in the payload), so it can be raised for new messages without breaking old ones. How it works shows the format.

PBKDF2 isn't the strongest password hash around. bcrypt, scrypt and Argon2 make the attacker spend memory as well as time, which hurts graphics cards far more than it hurts a CPU, and Argon2id is today's first choice for new systems. We use PBKDF2 because every browser has it built in, which means no extra code to trust, and because it works under our strict Content-Security-Policy, which doesn't allow WebAssembly. The password hashing comparison lays out the trade-off honestly.

Common questions