Derive cryptographic keys using PBKDF2 password hashing.
When an application encrypts your data (like a password manager vault), it needs a cryptographic key of an exact length (usually 256 bits). However, humans cannot memorize random 256-bit binary strings. We use passwords instead.
Passwords have dangerously low entropy (randomness). If we simply hashed a password once using SHA-256 to create an encryption key, an attacker with a modern GPU rig could guess billions of passwords per second until they found a match.
To fix this, PBKDF2 introduces Key Stretching. It hashes the password, then hashes the resulting hash, and hashes it again... thousands or millions of times in a loop (the Iteration Count). It also mixes in a random Salt to defeat rainbow table attacks.
By mathematically forcing the computer to run the hash 600,000 times to derive a single key, it intentionally slows down the process. For a legitimate user logging in, a 1-second delay is unnoticeable. But for a hacker trying to brute-force a billion passwords, that 1-second delay makes the attack mathematically impossible.
While PBKDF2 is an established standard, it relies purely on CPU processing time (it is "CPU-hard"). Modern GPUs are incredibly efficient at running parallel hashing operations, giving attackers an asymmetric advantage against PBKDF2.
Newer algorithms like Argon2 and scrypt are "Memory-hard", meaning they require large amounts of RAM to compute. GPUs have very little memory per core, making Argon2 drastically more resistant to GPU brute-forcing than PBKDF2.
What is the primary purpose of the 'Iteration Count' in PBKDF2?
