[Replying via the list archives; sorry for breaking In-Reply-To: threading. Please CC me on replies.]
Robert Newson wrote: > Because PBKDF2 has been designed and tested by cryptographers I'm a cryptographer, and I designed and tested scrypt. > and is fully described in RFC 2898 I fully described scrypt in my paper. > which includes test vectors to verify an implementation. I provided test vectors in my paper. > bcrypt is tied to a now obsolete cipher (blowfish), Agreed. bcrypt is slightly more secure than PBKDF2, but not enough to justify bringing in extra code. > I don't know anything much about scrypt but anyone can claim they > designed it to be more secure, but proving it is another matter. The scrypt paper contains a proof of security for a simplified version; that's much more than any other KDF has. There are good reasons why you might want to use PBKDF2: 1. Standards-compliance. 2. Not wanting to import a large amount of new code (scrypt is considerably more complex than PBKDF2). 3. Trading security for low memory footprint (scrypt is secure because it's impossible to compute it quickly without using lots of RAM). but the reasons you've given aren't among them. ;-) If you do decide to use PBKDF2, I'd recommend PBKDF2-SHA256 rather than the standard PBKDF2-SHA1; there's no security advantage, but SHA1 is deprecated generally and you don't want to have someone discover grep in 2015 and send nasty emails saying "hey, you're using a broken hash!" -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid
