# Can key hardening compensate lack of entropy?

In the context of an offline brute-force attack on encrypted data at rest (say, a password-protected AES encrypted file), is a password with 64 bits of entropy and 65536 rounds of key hardening just as strong as a password with 80 bits of "true" entropy (and no key hardening)? I guess what I really want to know is, can I get away with using a shorter password if I know that key hardening is applied?

• How are you defining a "round" of key hardening? i.e. Does a "round" take the same computational resources (especially time) as encrypting as single 128-bit block with AES?
– J.D.
Mar 4, 2017 at 15:47

## 1 Answer

Yes. That's the entire idea of key stretching, you can get away with a password that offers less strength against attacks. You add more operations to a brute force/dictionary attack to protect the keys. The disadvantage is that you need to do the same number of operations during key derivation.

Passwords commonly don't have 64 bits or 80 bits of entropy though. Say that the alphabet is 64 characters (6 bits) then you'd need a fully random password of 11 characters. For 80 bits you'd already need 14 characters. Those are easy to generate of course, but it may be tricky to remember them. And if you have to revert to a password manager, you might as well use a password that requires a few more keystrokes.

Note that shorter doesn't necessarily mean less strength. A password of 12 zero digits is not very strong. And although the idea behind "correct horse battery staple" is great, the strength of the passphrase is of course not the same as 28 fully random characters.

J.D. indicates that, indeed, different operations are performed for a single round. The amount of operations however will stay the same, so the increase should be in the same ball park. You could possibly assign a weight to each round of AES vs each round of the key strengthening routine to get a better estimate about the increase of strength.

• Or rather, the number of rounds of AES that is required to verify that the guess is correct. The further you dive into the details, the more complex things become, as always. Mar 4, 2017 at 15:52
• Usually I'd guess one round of AES is enough for verification though, as the attacker can choose which round is attacked, and usually the attacker learns enough to have pretty good indication and decrypt a few blocks more (which won't have much influence on the total amount of brute force AES decryptions required). Mar 4, 2017 at 16:09
• One of the complicating details Maarten mentions is that very often attackers can precompute the key hardening portion of the attack, and may even be able to amortize the cost of that precomputation across many different attacks (i.e. if the attacker is breaking many different keys that all used the same key stretching method). So should we weight the resource requirements of the precomputation phase differently than the online phase of the attack?
– J.D.
Mar 4, 2017 at 16:19
• @J.D. That's not what I'm mentioning. That kind of attack should not be possible if a salt is being used. I didn't mention salts, but for a good PBKDF (password based key derivation function) a salt is one of the required inputs. Mar 4, 2017 at 16:27
• That's a good point, Maarten - if the key stretching uses an unpredictable and large enough salt then precomputation is not viable. In that case disregard my above comment.
– J.D.
Mar 4, 2017 at 16:33