3 ms·

I never understand why PBKDF2 gets so little love. It's easy to use, it's easy to implement correctly, it's standardised. scrypt is cooler, but PBKDF2 is just f

by zeveb 11y ago

I never understand why PBKDF2 gets so little love. It's easy to use, it's easy to implement correctly, it's standardised. scrypt is cooler, but PBKDF2 is just fine.

kijin 11y ago
PBKDF2 is okay, but the underlying algorithms (usually SHA256) are a little too easy to accelerate with GPUs and ASICs. scrypt can also be accelerated with GPUs, but the difference is much smaller due to its design. PBKDF2 is still widely used in applications that need to be small and simple, such as embedded devices and disk encryption tools. For hashing website passwords, though, it is showing its age. Disclaimer: I'm not a cryptographer, so I might be talking out of my ass.
- zeveb 11y ago
  Oh sure, scrypt is better than PBKDF2, but IMHO PBKDF2 is preferable to bcrypt, due to ease of implementation.
  - kijin 11y ago
    That depends on whether someone else has already implemented it for you. In PHP, for example, bcrypt is just `password_hash()`. To use PBKDF2, on the other hand, you have to generate your own salt and pass it to `hash_pbkdf2`.
masklinn 11y ago
scrypt has the advantage that it can be memory-tuned and is designed to be both CPU-hard and memory-hard. PBKDF2 and bcrypt are only cpu-hard. Though IME it's bcrypt which is considered cooler, scrypt is regularly mentioned in KDF discussions but not widely available let alone used. The big advantage of bcrypt is its cost factor is exponential rather than linear, so the changes in cost factor are much lower and less frightening (you need to double the pbkdf2 cost factor to double the cost, on bcrypt you just increase the cost factor by 1, to match Moore's Law you just need to increment the cost factor by 1 every 2 years). And that's ignoring pbkdf2 can also be tuned using the hash function. So is PBKDF2 just fine? Yeah, that's what I generally use. But it's easier to create a simple and correct interface for bcrypt, it has less moving part and the parts which do move move slower.
dchest 11y ago
PBKDF2 is actually a crappy standard: - The work factor depends on the length of hash. For example, if you compute and store 64 bytes of PBKDF2-HMAC-SHA256, an attacker needs to only compute the first 32 bytes to verify the guess, and with PBKDF2 it means doing half the work. - In most common use (with HMAC), it inherits HMAC "vulnerability": a password longer than the hash function block is equal to the its hash (see this Twitter thread: https://twitter.com/dchest/status/421595430539894784 https://twitter.com/dchest/status/421595430539894784). For example, `plnlrtfpijpuhqylxbgqiiyipieyxvfsavzgxbbcfusqkozwpngsyejqlmjsytrmd` and `eBkXQTfuBqp'cTcar&g*` have the same PBKDF2-HMAC-SHA1 hash. (Scrypt is also vulnerable, BTW, as it uses PBKDF2-HMAC-SHA256.) - PBKDF2 is commonly used with hashes which are fast on GPU or custom hardware and require tiny memory, thus making defense/attack cost ratio very bad. See scrypt paper for cost estimates (https://www.tarsnap.com/scrypt/scrypt.pdf https://www.tarsnap.com/scrypt/scrypt.pdf). BTW, we had Password Hashing Competition (https://password-hashing.net https://password-hashing.net), the (tweaked) winner of which will hopefully be widely used in the future.
- CodesInChaos 11y ago
  It's difficult to implement efficiently: * If you use the underlying hash as a black-box, each HMAC invocation compresses 4 blocks. An optimized implementation will only require 2. Many implementations (e.g. the .NET one) don't include that optimization and thus suffer from a 2x slowdown compared to the attacker's implementation. * If you use HMAC naively, it'll hash the whole password on each iteration, opening a DoS attack. Django made this mistake (see http://arstechnica.com/security/2013/09/long-passwords-are-good-but-too-much-length-can-be-bad-for-security/ http://arstechnica.com/security/2013/09/long-passwords-are-g... ) It abuses the underlying hash: It xors together the outputs of different iteration numbers. This can interfere with the feed-forward of certain hash constructions. As far as I can tell this does not cause security issues, but it's still very dirty. --- Personally I'd go so far as to say that it's worse than PBKDF1 with a sufficiently wide underlying hash.
- zeveb 11y ago
  > - The work factor depends on the length of hash. For example, if you compute and store 64 bytes of PBKDF2-HMAC-SHA256, an attacker needs to only compute the first 32 bytes to verify the guess, and with PBKDF2 it means doing half the work. That's a fair criticism. In that respect, a better design might have been to generate a seed S using the PBKDF2 core, then just spit out HMAC(S, 1), HMAC(S, 2) for the derived key. I don't know if that would have had its own issues though; I'm not a cryptologist. > In most common use (with HMAC), it inherits HMAC "vulnerability": a password longer than the hash function block is equal to the its hash True, but as you imply it's really not a vulnerability. And it's certainly better than limiting passwords to 56 bytes, as bcrypt does (with human-memorable passwords, 56 bytes really aren't enough). > - PBKDF2 is commonly used with hashes which are fast on GPU or custom hardware and require tiny memory, thus making defense/attack cost ratio very bad. Sure, scrypt is better. But scrypt is not what 'everyone' uses: bcrypt is.

by zeveb 11y ago

I never understand why PBKDF2 gets so little love. It's easy to use, it's easy to implement correctly, it's standardised. scrypt is cooler, but PBKDF2 is just fine.

kijin 11y ago

PBKDF2 is okay, but the underlying algorithms (usually SHA256) are a little too easy to accelerate with GPUs and ASICs. scrypt can also be accelerated with GPUs, but the difference is much smaller due to its design. PBKDF2 is still widely used in applications that need to be small and simple, such as embedded devices and disk encryption tools. For hashing website passwords, though, it is showing its age. Disclaimer: I'm not a cryptographer, so I might be talking out of my ass.

zeveb 11y ago
Oh sure, scrypt is better than PBKDF2, but IMHO PBKDF2 is preferable to bcrypt, due to ease of implementation.
- kijin 11y ago
  That depends on whether someone else has already implemented it for you. In PHP, for example, bcrypt is just `password_hash()`. To use PBKDF2, on the other hand, you have to generate your own salt and pass it to `hash_pbkdf2`.

masklinn 11y ago

scrypt has the advantage that it can be memory-tuned and is designed to be both CPU-hard and memory-hard. PBKDF2 and bcrypt are only cpu-hard. Though IME it's bcrypt which is considered cooler, scrypt is regularly mentioned in KDF discussions but not widely available let alone used. The big advantage of bcrypt is its cost factor is exponential rather than linear, so the changes in cost factor are much lower and less frightening (you need to double the pbkdf2 cost factor to double the cost, on bcrypt you just increase the cost factor by 1, to match Moore's Law you just need to increment the cost factor by 1 every 2 years). And that's ignoring pbkdf2 can also be tuned using the hash function. So is PBKDF2 just fine? Yeah, that's what I generally use. But it's easier to create a simple and correct interface for bcrypt, it has less moving part and the parts which do move move slower.

dchest 11y ago

PBKDF2 is actually a crappy standard: - The work factor depends on the length of hash. For example, if you compute and store 64 bytes of PBKDF2-HMAC-SHA256, an attacker needs to only compute the first 32 bytes to verify the guess, and with PBKDF2 it means doing half the work. - In most common use (with HMAC), it inherits HMAC "vulnerability": a password longer than the hash function block is equal to the its hash (see this Twitter thread: https://twitter.com/dchest/status/421595430539894784 https://twitter.com/dchest/status/421595430539894784). For example, `plnlrtfpijpuhqylxbgqiiyipieyxvfsavzgxbbcfusqkozwpngsyejqlmjsytrmd` and `eBkXQTfuBqp'cTcar&g*` have the same PBKDF2-HMAC-SHA1 hash. (Scrypt is also vulnerable, BTW, as it uses PBKDF2-HMAC-SHA256.) - PBKDF2 is commonly used with hashes which are fast on GPU or custom hardware and require tiny memory, thus making defense/attack cost ratio very bad. See scrypt paper for cost estimates (https://www.tarsnap.com/scrypt/scrypt.pdf https://www.tarsnap.com/scrypt/scrypt.pdf). BTW, we had Password Hashing Competition (https://password-hashing.net https://password-hashing.net), the (tweaked) winner of which will hopefully be widely used in the future.

CodesInChaos 11y ago
It's difficult to implement efficiently: * If you use the underlying hash as a black-box, each HMAC invocation compresses 4 blocks. An optimized implementation will only require 2. Many implementations (e.g. the .NET one) don't include that optimization and thus suffer from a 2x slowdown compared to the attacker's implementation. * If you use HMAC naively, it'll hash the whole password on each iteration, opening a DoS attack. Django made this mistake (see http://arstechnica.com/security/2013/09/long-passwords-are-good-but-too-much-length-can-be-bad-for-security/ http://arstechnica.com/security/2013/09/long-passwords-are-g... ) It abuses the underlying hash: It xors together the outputs of different iteration numbers. This can interfere with the feed-forward of certain hash constructions. As far as I can tell this does not cause security issues, but it's still very dirty. --- Personally I'd go so far as to say that it's worse than PBKDF1 with a sufficiently wide underlying hash.
zeveb 11y ago
> - The work factor depends on the length of hash. For example, if you compute and store 64 bytes of PBKDF2-HMAC-SHA256, an attacker needs to only compute the first 32 bytes to verify the guess, and with PBKDF2 it means doing half the work. That's a fair criticism. In that respect, a better design might have been to generate a seed S using the PBKDF2 core, then just spit out HMAC(S, 1), HMAC(S, 2) for the derived key. I don't know if that would have had its own issues though; I'm not a cryptologist. > In most common use (with HMAC), it inherits HMAC "vulnerability": a password longer than the hash function block is equal to the its hash True, but as you imply it's really not a vulnerability. And it's certainly better than limiting passwords to 56 bytes, as bcrypt does (with human-memorable passwords, 56 bytes really aren't enough). > - PBKDF2 is commonly used with hashes which are fast on GPU or custom hardware and require tiny memory, thus making defense/attack cost ratio very bad. Sure, scrypt is better. But scrypt is not what 'everyone' uses: bcrypt is.