Re: Analyses of scrypt

On 07/05/2011 01:58, Jeffrey Goldberg wrote:
I am soliciting opinions about the various virtues of PBKDF2 versus
scrypt for handling the "master password" for a data base of passwords.

The central argument to scrypt seems extremely sound to me: a password-based key derivation function should increase the cost of an attack by making it necessary to use a lot of memory during each password guess, on top of all other "classical" methods (such as salt and iteration).

What I read about scrypt on and links
from there all are persuasive.


But I have two concerns.

(1) scrypt does not appear to have been well studied and scrutinized.
It's got a respected author, Colin Percival, I that isn't enough on its
own. (I am completely unqualified to analyze these things; so I need to
rely on the professional community).

So any pointers to work on this would be great.

No pointers. But scrypt is *demonstrably* secure (or next to that) thus there won't be a cryptanalysis. Rest assured on that. There could still be attacks on a poor implementation, though.

(2) Usability on mobile devices. For my application, we need to process
the password not only on desk top computers but on iOS, Android, and
Windows 7 Phone and potentially within browsers using JavaScript.

With PBKDF2 we have libraries that we can use and test easily on various
platforms (like what does 20000 PBKDF2 HMAC-SHA1 iterations do to
battery life). But we need to have some understanding of what the memory
pressures of scrypt do on those systems.

In my opinion scrypt is so simple that the extra implementation cost on any platform with a built-in hash by a competent crypto implementor is small compared to meaningfully benchmarking any PBKDF on that platform. Actually the increased security of scrypt should make it possible to err on the fast side (replacing benchmarking by a guestimate) and still be safer than PBKDF2, and faster, for less money invested.

As I read what I've written above, I suppose that I have talked myself
out of using scrypt any time soon.

I think using PBKDF2 rather than scrypt is hardly justifiable from a purely technical standpoint. On the other hand other very real considerations (like perceived security by non-cryptographers, availability of a reviewed implementation of PBKDF2, or conformance to law/standards) could dictate the use of something time-proven, readily available, or just mandatory, rather than mathematically proven.

We absolutely do not want to "roll our own" implementations for anything we give to users. But still, I am
really worried about how well PBKDF2 can withstand the kinds of cheap,
rentable, parallelization that is available even today.

This is a concern; but sadly, there are other things to worry in this world: many deployed applications do not even use a proper PBKDF (defined as including a tradeoff for CPU time / attack cost, set to a sound value, with proper use of salt). Further, many platforms are penetrable by other means (code injection..), and a trojan will beat any crypto scheme running on a CPU it fully penetrated.

Francois Grieu