[cryptography] any reason PBKDF2 shouldn't be used for storing hashed passwords?

travis+ml-rbcryptography at subspacefield.org travis+ml-rbcryptography at subspacefield.org
Wed Aug 15 19:50:32 EDT 2012

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

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.
"What are you saying?" "I'm not saying anything. I didn't say anything then,
and I'm not saying anything now." -- Babylon 5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20120815/1f340a7e/attachment.asc>

More information about the cryptography mailing list