If you've read anything about password hashing or encryption, you've run into all three names: PBKDF2, bcrypt, Argon2. They get lumped together as "ways to turn a password into something safe to store or use," but they were built for different problems, at different times, and they don't defend against the same attacks equally well. Here's what each one actually does, where they diverge, and why FileX derives its encryption keys with PBKDF2 rather than the others.
What a key-derivation function is for
A password like correct horse battery staple is not usable directly as a cryptographic key, and it's not safe to check by comparing it to a plain stored copy either. A key-derivation function (KDF) — sometimes called a password-hashing function in the login context — takes the password plus a random salt and runs it through a deliberately expensive one-way computation. Two properties matter:
- The salt makes every derivation unique, even for two people who pick the same password, so an attacker can't precompute one giant table of results and reuse it against every target.
- The cost (iterations, memory, or both) makes each guess slow. An attacker who steals a salt and a ciphertext (or a stored hash) still has to pay that cost for every single password they try. That's the entire point — the cipher or the login check is rarely the weak link; how expensive it is to brute-force the password is.
PBKDF2, bcrypt, and Argon2 all satisfy this shape. Where they differ is what they make expensive.
PBKDF2: CPU-hard, standardized, everywhere
PBKDF2 (Password-Based Key Derivation Function 2) dates to 2000 and is specified in RFC 2898. It derives a key by running an underlying HMAC (commonly HMAC-SHA256) over the password and salt thousands of times in sequence. The only cost knob is iterations — more repetitions, more CPU time, no memory requirement beyond the hash itself.
That single-dimension cost is PBKDF2's main weakness: it parallelizes cleanly on GPUs and ASICs, which can run huge numbers of hash iterations concurrently far cheaper than a general-purpose CPU can. NIST SP 800-63B sets the floor at "typically at least 10,000 iterations," while the current OWASP Password Storage Cheat Sheet recommends 600,000 iterations for PBKDF2-HMAC-SHA256 in new systems specifically because commodity GPU cracking has gotten so much faster since the function was designed. PBKDF2 is still considered sound — it just needs a high, regularly-revisited iteration count to stay expensive against modern hardware.
bcrypt: built for login checks, not general key derivation
bcrypt (1999) wraps the Blowfish cipher into a password-hashing scheme with a configurable, exponential cost factor. It was a real improvement over unsalted or fast-hashed passwords at the time, and OWASP still lists it as an acceptable choice with a work factor "as large as verification server performance will allow, with a minimum of 10."
Two things limit it outside login-check use cases: it silently truncates input past 72 bytes, and — like PBKDF2 — its cost is CPU time only, so it doesn't resist a well-funded, memory-rich cracking rig as well as a memory-hard function does. It's also not part of any Web Crypto API standard, so a browser can't produce it without shipping a separate implementation.
Argon2: memory-hard, the modern default
Argon2 won the Password Hashing Competition in 2015 and is standardized in RFC 9106. Its cost has three independent dials: iterations (time), memory (how much RAM each computation must hold), and parallelism. That memory requirement is the important change — a GPU or ASIC that can run millions of cheap hash operations in parallel can't cheat past a function that demands, say, 19 MiB of memory per guess. Memory is expensive to parallelize at scale in a way that raw compute isn't.
OWASP now recommends Argon2id (a hybrid variant resistant to both side-channel and GPU-style attacks) as the first choice for new password-hashing systems, falling back to PBKDF2 only when FIPS-140 compliance is required.
The three, side by side
| PBKDF2 | bcrypt | Argon2id | |
|---|---|---|---|
| Defined | RFC 2898 (2000) | 1999, no formal RFC | RFC 9106 (2021) |
| Cost dimension | Iterations (CPU only) | Cost factor (CPU only) | Time + memory + parallelism |
| GPU/ASIC resistance | Weaker — parallelizes well | Moderate | Strong when memory is tuned high |
| Input limits | None significant | Truncates past 72 bytes | None significant |
| Native in the browser (Web Crypto API) | Yes | No | No |
| FIPS-140 status | Approved | Not a NIST/FIPS algorithm | Not currently FIPS-approved |
Why FileX uses PBKDF2
FileX derives the AES-256 key for every .filex container with PBKDF2-HMAC-SHA256, a random 16-byte salt, and 250,000 iterations, calling crypto.subtle.deriveKey directly — the Web Crypto API built into every modern browser. That's the deciding factor: SubtleCrypto.deriveKey supports PBKDF2, HKDF, and ECDH natively. It does not support Argon2 or bcrypt. Getting either of those into the browser means shipping a third-party WebAssembly implementation and trusting it the way you'd trust any dependency — which cuts against FileX's rule of using only the browser's own audited, self-hosted crypto primitives with nothing extra to fetch or verify.
That's an honest trade-off, not a claim that PBKDF2 is the strongest KDF available. Argon2id's memory-hardness is a genuine advantage against large-scale GPU cracking, and if you're designing a server-side login system today, OWASP's guidance to prefer Argon2id over PBKDF2 is worth following. FileX's use case is different in one respect but not immune to the same math: it derives a file encryption key from a password, not a login-check hash, but an attacker who obtains a .filex file still faces the same offline brute-force economics — the salt and iteration count are exactly what slow them down. FileX's 250,000 iterations sit well above the NIST floor of 10,000, though below OWASP's newer 600,000-iteration figure for stored password verifiers; iteration counts are a moving target as hardware gets faster, which is why the cheat sheets keep raising them.
The practical upshot for you: the KDF is only half the defense. A long, random password does more for your file's security than any iteration count can compensate for on its own — generate one in your browser with the same zero-upload guarantee. For the full picture of how the derived key gets used — AES-256-GCM, the random IV, the authentication tag that rejects tampering — see how AES-256-GCM keeps your files safe.
Takeaway
- All three — PBKDF2, bcrypt, Argon2 — exist to make password guessing slow, not to make encryption itself stronger.
- PBKDF2 and bcrypt cost CPU time only; Argon2 also costs memory, which is why it resists GPU/ASIC cracking better.
- Web browsers only implement PBKDF2 natively (via the Web Crypto API), which is why FileX — and most in-browser crypto — uses it rather than Argon2 or bcrypt.
- The password you choose still matters more than the KDF choice. Encrypt a file in your browser — nothing is uploaded, and the live monitor on the page proves it.