3 ms·
While I think it's cool to have a competition to help come up with better, "standardized" methods of hashing, PBKDF2 is pretty good already. The problem seems t
by jstalin 14y ago
While I think it's cool to have a competition to help come up with better, "standardized" methods of hashing, PBKDF2 is pretty good already. The problem seems to be a lack of implementation, not a lack of good options.
- dchest 14y agoPBKDF2 is not pretty good: the difference between GPU/hardware-accelerated implementations of PBKDF2 with common hashes and software implementations for CPUs is huge. Plus you can compute it in parallel cheaply. See scrypt paper for details: http://www.tarsnap.com/scrypt.html http://www.tarsnap.com/scrypt.html
- jstalin 14y agoI can't find in that paper how many iterations they put PBKDF2 through and which hashing algorithm they used. Any implementation of PBKDF2 I do uses a very high number of iterations (50,000+) and I use whirlpool, which is amongst the slowest of algorithms.
- dchest 14y ago100ms in table: PBKDF2-HMAC-SHA256 with an iteration count of 86,000; 5s: PBKDF2-HMAC-SHA256 with an iteration count of 4,300,000 (see page 13). If you're using the slowest possible algorithm/biggest number of iterations, you're still vulnerable to parallel attacks: imagine a huge number of cheap chips bruteforcing passwords. Scrypt tries to maximize the cost of such chips by requiring large amounts of RAM for computation. Again, this is explained in the paper.
- jstalin 14y agoThanks.