Key Stretching Calculator

What this generator does

Divides the iteration count by your hash rate to get the time one attempt takes, inverts the target time to get the count that would hit it, and divides the attacker's raw rate by the iterations to get what they are reduced to.

How to use this tool

1. Enter your iteration count and what your server manages per second.
2. Set the time per login you are willing to spend.
3. Enter what you think an attacker's hardware manages raw.
4. Read the cost now, the count that hits your target, and the guessing rate it leaves.

Understanding the controls

Iterations

How many times the hash is repeated. This is the number that costs an attacker, and the only one of these settings you actually control.

Your hashes per second

What your own server manages for a single unrepeated hash of this algorithm. Measure it rather than guessing — it varies enormously by hardware.

Target time per login

What you are willing to spend verifying one password. Around 250 milliseconds is a common choice, since users do not notice it and attackers do.

Attacker's raw hashes per second

What dedicated cracking hardware manages without the stretching. This is the number that makes the case for a high iteration count.

Common use cases

• Choosing a PBKDF2 or bcrypt cost for a new system
• Checking whether an inherited iteration count is still adequate
• Explaining to a team why login latency is a security setting
• Working out what raising the count would buy against an attacker
• Sizing the cost against a measured hash rate rather than a guess

How this generator works

Time per attempt is iterations divided by hashes per second, so the cost is linear in the count — double the iterations and both you and the attacker pay twice. Inverting that gives the count for a target time. The attacker's effective rate is their raw rate divided by the iterations, which is what turns billions of guesses a second into thousands. Before display the tool recomputes the cost at double the iterations and confirms the time has doubled and the effective rate halved, so the linearity the page claims is checked rather than asserted.

Randomness and fairness

Nothing here is random, and nothing here is a secret. These are cost figures for a setting you choose — the password generators are where anything is actually generated.

For how randomness is produced across the whole site, see how Generate Random works.

Limitations and good to know

• This models iteration count only. Memory-hard functions like scrypt and Argon2 also charge an attacker for memory, which is the main reason to prefer them and is not captured here.
• Hash rates vary by orders of magnitude between CPUs, GPUs and dedicated hardware, so the attacker figure is only as good as your estimate of their kit.
• Stretching buys time against guessing; it does nothing for a password that appears in a breach list, where the first guess is the right one.
• Real deployments also pay for memory and parallelism, so measured login latency will exceed this arithmetic.

Privacy and your data

The arithmetic runs in your browser. No password is entered, requested or handled here, and the numbers you type are never transmitted, stored or included in analytics.