21–30 of 193 posts
> While scrypt's cryptographic soundness, like bcrypt's, is poorly researched I think we may have different notions of what "poorly researched" means.
I think he meant it hasn't undergone the same level of public scrutiny. You've certainly spent ample time researching it, and it's obviously been tested, but possibly not as much something like AES.
So the author says to use PBKDF2 because it's researched and tested better than bcrypt, and then suggests scrypt as another alternative despite having, from what I can tell, less research done on it than bcrypt. The crypto space can be intimidating to your average dev, but almost every app needs some sort of protection (at least for user information). I think the author is fair in wanting to push for the "default" to…
Note that scrypt uses PBKDF2 before and after the memory-hard function.
Only as a cryptographic mixing/expansion function. There is no reason to think that scrypt's security would be any less if the PBKDF2 calls were replaced with xor.
Also, somewhat related question -- what if Salsa core in scrypt is replaced with BLAKE core (with fewer rounds than in hash), and SHA-2 in PBKDF2 with BLAKE, thus making it possibly smaller (hardware and lines of code). Will this work well?
PBKDF2 is worse than bcrypt. scrypt is better than bcrypt. bcrypt has the advantage of being both very good, and also broadly available on web platforms. scrypt does not yet have that advantage; when it does, I will start saying "just use scrypt". But the simple fact is: all three of these functions are fine . ANY of them is a huge step forward from what people do without them. "Just use bcrypt" is 1000x more effecti…
By roughly a factor of 5.
scrypt is better than bcrypt.
By roughly a factor of 4000.
why do I care whether something is a PKCS standard or not?
You don't care, and I don't care, but I'm sure you know lots of companies which do care (especially since PBKDF2 is a NIST standard too).
Earlier quoted context omitted.
I think he meant it hasn't undergone the same level of public scrutiny. You've certainly spent ample time researching it, and it's obviously been tested, but possibly not as much something like AES.
bcrypt is better tested than PBKDF2: far more publicly "testable" systems use it (bcrypt was the password file format for OpenBSD).
PBKDF2 is worse than bcrypt. scrypt is better than bcrypt. bcrypt has the advantage of being both very good, and also broadly available on web platforms. scrypt does not yet have that advantage; when it does, I will start saying "just use scrypt". But the simple fact is: all three of these functions are fine . ANY of them is a huge step forward from what people do without them. "Just use bcrypt" is 1000x more effecti…
Can you elaborate a little bit on this? Or point to a reference. Wikipedia mentions that PBKDF2 is easier to implement with ASICs or GPUs. Is that the primary reason?
tl;dr PBKDF2 and scrypt each have supposed upsides to bcrypt and all the benefits. PBKDF2: RSA tested and widely used. scrypt: memory hard as well.
"RSA tested and widely used" is subjective, not particularly meaningful, and in some senses erroneous, and so makes a poor case for PBKDF2.
If people want to seriously push for scrypt as a replacement for bcrypt as the "default" function, I'll design and print flags and pennants for the movement. But when people say "use PBKDF2 instead of bcrypt", I think the net effect is to scare people back to salted hashes, and my general response is going to be to poke holes in their arguments.
PBKDF2 is worse than bcrypt. scrypt is better than bcrypt. bcrypt has the advantage of being both very good, and also broadly available on web platforms. scrypt does not yet have that advantage; when it does, I will start saying "just use scrypt". But the simple fact is: all three of these functions are fine . ANY of them is a huge step forward from what people do without them. "Just use bcrypt" is 1000x more effecti…
PBKDF2 is worse than bcrypt. By roughly a factor of 5. scrypt is better than bcrypt. By roughly a factor of 4000. why do I care whether something is a PKCS standard or not? You don't care, and I don't care, but I'm sure you know lots of companies which do care (especially since PBKDF2 is a NIST standard too).
AND you lose control of your database. Even if I had a magic instant bcrypt reverser, it does me no good if I don't have the hashes. You cannot be compromised by a bcrypt mistake, it would only make your already existing compromise slightly worse.