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
pgpaRS7QVaPsM.pgp
Description: PGP signature
_______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
