PBKDF2 is certainly decent, and often the easiest choice if you intend to comply with e.g. FIPS 140-2/ISO 27001, but the biggest argument against it is that it _isn't_ difficult to parallelize, since it is just e.g. HMAC-SHA256. Each guess might require sequential iteration, but you can still compute many guesses simultaneously. bcrypt is slightly more computationally expensive (although its 55-byte input limit is often ignored,) and scrypt is massively more so, requiring a significant amount of die area. I don't know of an AKDF that can be tuned to be as expensive to parallelize as scrypt. Comparison (from the scrypt paper, http://www.tarsnap.com/scrypt/scrypt.pdf): http://i.imgur.com/iUpUk.png
If you are building a new system, I would definitely recommend investigating if there is a good implementation of scrypt for the language you are using -- library support has been improving recently. But, to be honest, if you use PBKDF2 with a high iteration count (at least 0.2s per run on a decent system), your digests are stronger than the ones most companies store. > PBKDF2-HMAC-SHA1 significantly weaker than PBKDF2-HMAC-SHA512? SHA-1 is still safe in an HMAC construction, however there's no convincing reason not to use at least PBKDF2-HMAC-SHA256 that I can think of. You don't need it to be fast. Going beyond that won't really give you much security compared to using a memory-hard function. On Thu, Aug 16, 2012 at 1:50 AM, <[email protected] > wrote: > Any reason PBKDF2 shouldn't be used for (storing) hashed passwords? > > Seems like it solves many problems: > 1) slowing down guesses (at cost of slowing valid entries too) > 2) parameterized iteration > 3) IV/salt/uniquification > 4) widely deployed, tested > 5) difficult to parallelize (iterations) > 6) prepackaged, doesn't require developers to roll their own > (and we all know about letting developers roll their own) > many language stacks > published test vectors > 7) No potential short cycles, at cost of being unable to update > iteration count without preimage > > I'm ignoring the differences between PBKDF2 and bcrypt at the moment, > I know it seems to require more memory... scrypt seems to be a better > countermeasure for the FPGA threat, though much less widely > implemented. > > Also, what's the status of SHA-3? Is it on horizon? > > Finally, is PBKDF2-HMAC-SHA1 significantly weaker than > PBKDF2-HMAC-SHA512? I couldn't find the latter in JRE > and some other stacks. > -- > http://www.subspacefield.org/~travis/ > "What are you saying?" "I'm not saying anything. I didn't say anything > then, > and I'm not saying anything now." -- Babylon 5 > > _______________________________________________ > cryptography mailing list > [email protected] > http://lists.randombit.net/mailman/listinfo/cryptography > >
_______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
