Hacker News Reader

Comment by Dylan16807 | Hacker News Reader

You can compensate for not just 50x but 500x by adding 2 characters to your password. If that's the speedup factor, it's not itself a big worry.

View on HN

You can eliminate the problem entirely by using a random full-allowed-character-set password. The whole point of KDFs is that the password/passphrase is predictable (usually: by being generated from a seed dictionary).

Random is important, character set not so much. And yes when I say 2 characters I mean random ones. Even 26x26 is plenty to compensate. Or you can add one random word.

We're both saying the same thing: you can make the KDF irrelevant if you (as you just specified) use an AES key as an input. The entire point of KDF is that humans don't do that.

No, what I'm saying is: If your password was good enough for a quality KDF, then improving it to use a 50x worse KDF is very easy. If the worse one requires you "use an AES key", then the good one pretty much also required you to "use an AES key". If the good one didn't require that, then the 50x worse one also doesn't require that. Generate a single letter and slap it on the end, or human-pick two letters.

50x is not the decider between allowing a good password and allowing a bad password. It's a tiny little nudge.

Edit: To put "little nudge" another way, if you have a 1-10 scale of password quality, most steps in that scale are going to be more than 5.6 bits apart.

To add (and agree), if you've got (say) a 10-word Diceware-style passphrase with ≥128 bits of entropy, the point of a KDF becomes solely for the domain separation that KDFs provide. That's not particularly relevant for the USB drive case, but it's very useful in the general case of deriving keys. If I'm writing encryption software for my own use where I know I'll be generating a secure (≥128 bits of entropy) passphrase, I just use HKDF or Blake3's KDF mode.

Reply on news.ycombinator.com