What is key stretching?

What is key stretching?

Passwords are short and predictable compared with real cryptographic keys. Key stretching compensates by making the conversion from password to stored hash, or from passphrase to encryption key, deliberately expensive. The legitimate system pays that cost once per login or unlock. An attacker who steals the hashes pays it for every single guess, so a delay nobody notices at login multiplies across billions of attempts.

The cost is set by a tunable work factor: an iteration count, a cost exponent or an amount of memory. Because the parameters are normally stored with each hash, administrators can raise them as hardware gets faster and rehash each password the next time its user logs in.

Key stretching algorithms

• PBKDF2 repeats HMAC many thousands of times. It is defined in PKCS #5 and NIST SP 800-132 and is the usual choice where FIPS-validated cryptography is required. OWASP currently recommends 600,000 iterations with HMAC-SHA-256. It needs very little memory, so GPUs attack it efficiently.
• bcrypt, from 1999, is built on the Blowfish cipher. Its cost is an exponent, so cost 12 means 2^12 rounds and each step up doubles the work. It reads only the first 72 bytes of a password.
• scrypt is memory-hard: every hash needs a configurable amount of RAM, which makes large GPU and custom-hardware cracking rigs far more expensive to run.
• Argon2id comes from Argon2, the 2015 winner of the Password Hashing Competition, specified in RFC 9106. It tunes memory, passes and parallelism and is OWASP's first choice for new systems.

Key stretching also protects keys derived from passphrases. WPA2-Personal, for example, runs the Wi-Fi passphrase through PBKDF2 with 4,096 iterations, using the network name (SSID) as the salt, to produce the pre-shared key.

A worked example of the cost

Suppose an attacker wants to test one billion candidate passwords against one stolen hash on a single processor core.

Real attackers run many GPUs in parallel, so the absolute times shrink, but the ratio holds: a hash that is 100,000 times slower costs the attacker 100,000 times more work for every guess. A user waiting a tenth of a second at login barely notices.

Key stretching vs. salting vs. plain hashing

These controls solve different problems and are used together. A salt makes each hash unique, defeating precomputed tables and duplicate matching, but it does nothing to slow down an individual guess. Key stretching slows each guess but on its own would still give identical passwords identical hashes, which is why every modern password hashing function also takes a salt. General-purpose hashes such as SHA-256 and SHA-3 are excellent for integrity checks but are designed to be fast, which is the wrong property for passwords.

Stretching does not rescue a terrible password: one taken from the top of a breach list falls quickly at any realistic work factor, so pair stretching with breached-password screening and MFA. Also keep it apart from fast key derivation functions such as HKDF, which expand an already strong secret, like a Diffie-Hellman result, into session keys. HKDF can be fast because its input cannot be guessed.

Key stretching on the CompTIA Security+ exam

SY0-801 no longer lists key stretching as a separate item, but it is part of the secure password storage material that sits with salting under objective 1.3, the objective about selecting cryptographic solutions and justifying the choice. Wording such as "make brute-force attacks on stolen hashes slower", "increase the work factor" or "strengthen a weak password before it becomes a key", or an answer list containing PBKDF2 or bcrypt, points to key stretching. If the question is about rainbow tables or identical hashes, the answer is salting instead. Common distractors are switching to a longer fast hash such as SHA-512, encrypting the stored hashes, and account lockout, which cannot help against offline guessing on the attacker's own hardware.