5 ms·

bcrypt uses Blowfish as it's block cipher, so an issue with blowfish is an issue with bcrypt. There have been Blowfish problems, like this charset issue: http

bcrypt uses Blowfish as it's block cipher, so an issue with blowfish is an issue with bcrypt. There have been Blowfish problems, like this charset issue: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2483 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2483 bcrypt also weakens on long passphrases, since it only uses 55 chars of input. I'm certainly not suggesting that people not use bcrypt, I'm just surprised that it's the only option.

tptacek 14y ago
This is a string of non sequiturs posing as an argument.
Firehed 14y ago
Yes, and PBKDF2 relies on other algorithms that have also shown problems. It's just looping and clever bitmasking (and takes about 10LOC to implement, assuming you have hash_hmac easily available). So if there's a problem found with sha256 or whatever hashing function you choose it use it with, then it too has a problem. That's not to knock PBKDF2 - I'm just pointing out that both have flaws, and that people should use the right tool for the job. The "KDF" in "PBKDF2" stands for Key Derivation Function; i.e., it's for deriving a(n encryption) key. bcrypt exists basically for the sole purpose of password storage. In practical terms, it's more obvious how to use bcrypt's work factor as computers speed up than PBKDF2's iteration count, although either is quite suitable for the job. It's also easier to rehash bcrypt-stored passwords when upping your work factor - the old version will still verify, just check for $WF$ not matching your current work factor. PBKDF2 requires a bit more logic since you have to rehash with a different iteration count and do a second comparison, which conceivably also opens you up to a timing attack unless you're very careful about how you do it. To me, it's a matter of what a tool was designed for. Given that I have the right tool for the job, why use something that's designed for something else even though it works quite well?

tptacek 14y ago

This is a string of non sequiturs posing as an argument.

Firehed 14y ago

Yes, and PBKDF2 relies on other algorithms that have also shown problems. It's just looping and clever bitmasking (and takes about 10LOC to implement, assuming you have hash_hmac easily available). So if there's a problem found with sha256 or whatever hashing function you choose it use it with, then it too has a problem. That's not to knock PBKDF2 - I'm just pointing out that both have flaws, and that people should use the right tool for the job. The "KDF" in "PBKDF2" stands for Key Derivation Function; i.e., it's for deriving a(n encryption) key. bcrypt exists basically for the sole purpose of password storage. In practical terms, it's more obvious how to use bcrypt's work factor as computers speed up than PBKDF2's iteration count, although either is quite suitable for the job. It's also easier to rehash bcrypt-stored passwords when upping your work factor - the old version will still verify, just check for $WF$ not matching your current work factor. PBKDF2 requires a bit more logic since you have to rehash with a different iteration count and do a second comparison, which conceivably also opens you up to a timing attack unless you're very careful about how you do it. To me, it's a matter of what a tool was designed for. Given that I have the right tool for the job, why use something that's designed for something else even though it works quite well?