PBKDF2 and why we use 310,000 iterations
Slowing down key derivation protects you from brute force. Here’s how we picked the number.
PBKDF2 repeatedly hashes your password with a salt to produce a key. The iteration count is how many times we do that. More iterations = slower for you (once per unlock or save) and much slower for an attacker trying millions of guesses.
Why 310,000
We want decryption and encryption to feel instant on a typical laptop or phone—under a few hundred milliseconds. We benchmarked and landed on 310k as a balance: noticeable but acceptable delay, and a big cost for anyone brute-forcing. NIST and OWASP guidance often cite 600k+ for PBKDF2-HMAC-SHA256; we’re in the same ballpark and can bump it if hardware gets faster.
Salt is critical
Each note has its own random salt. So an attacker can’t amortize work across notes—they have to run 310k iterations per guess per note. That makes large-scale cracking impractical for strong passwords.
FAQ: PBKDF2 and 310,000 iterations
Q1. Why did you choose PBKDF2 instead of a newer KDF?
PBKDF2 is widely supported (including in the Web Crypto API), well understood, and good enough when used with high iteration counts. That makes it a practical choice for browser-based encryption.
Q2. Is 310,000 iterations enough for PBKDF2 today?
It’s a balance between user experience and attacker cost. 310k keeps unlock times reasonable on typical devices while making brute-force attacks much more expensive. We can raise it over time as hardware improves.
Q3. Does a higher iteration count fix a weak password?
No. It helps, but it doesn’t rescue short or guessable passwords. You still need strong, unique passwords; PBKDF2 simply slows down each guess.
Q4. Why is a per-note salt so important?
Without unique salts, attackers could reuse work across notes with the same password. Salts force them to redo the full PBKDF2 work for every password–note pair.
Q5. Can someone recover my key from the salt and iteration count alone?
No. Salt and iteration count are safe to store and transmit. Without the original password, PBKDF2 is not reversible; attackers still have to guess passwords and run the KDF for each guess.
Where to go next
If you want to see how PBKDF2 fits into the rest of the stack:
- Read “Why we encrypt in the browser (and what happens to your password)”.
- Read “AES-256-GCM in the browser: a quick tour of our crypto stack”.
- Try Inkrypt at https://www.inkrypt.online and notice the slight delay on unlock—that’s PBKDF2 doing its job.