Colin Percival and I have worked on an internet-draft on scrypt for some time. I realize now that the -00 draft was published over two years ago, turning this effort today somewhat into archeology rather than rocket science. Still, having a published RFC that is easy to refer to from other Internet protocols will hopefully help to establish the point that PBKDF2 alone no longer provides state-of-the-art protection for password hashing.
I have written about password hashing before where I give a quick introduction to the basic concepts in the context of the well-known PBKDF2 algorithm. The novelty in scrypt is that it is designed to combat brute force and hardware accelerated attacks on hashed password databases. Briefly, scrypt expands the password and salt (using PBKDF2 as a component) and then uses that to create a large array (typically tens or hundreds of megabytes) using the Salsa20 core hash function and then de-references that large array in a random and sequential pattern. There are three parameters to the scrypt function: a CPU/Memory cost parameter N (varies, typical values are 16384 or 1048576), a blocksize parameter r (typically 8), and a parallelization parameter p (typically a low number like 1 or 16). The process is described in the draft, and there are further discussions in Colin’s original scrypt paper.
The document has been stable for some time, and we are now asking for it to be published. Thus now is good time to provide us with feedback on the document. The live document on gitlab is available if you want to send us a patch.
http://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scrypt.html
It seems scrypt is actually weaker than bcrypt when 4 MB of memory or less are required. However, from my testing, it seems that 8 MB of memory or more, are problematic for interactive sessions.
From the post:
Thoughts?
Like with most crypto algorithms that allows parameter choices, if you pick bad parameters you run into problems. I’ve added a bit of warning to the draft now, since someone may fall into this pit otherwise, thank you for making me aware of this!
The typical use-case for scrypt is for use on machines with several GB’s of memory, or at least many 100MBs, though.
Who uses a machine with <16MB of memory for interactive use and authenticate to it with a password these days? 🙂
/Simon
This is an incredibly important development. PBKDF2 should start heading down the deprecation lane in favor of scrypt IMO.
Also, I’m not sure if you’re aware, but there’s been a new project called NeoScrypt (PDF: http://phoenixcoin.org/archive/neoscrypt_v1.pdf) which attempts to address some of the weak points in scrypt as a key stretching algorithm. The PDF reads like this:
NeoScrypt was designed primarily as a revamped key stretching algorithm to make mining of cryptocurrency less susceptible to ASICs and FPGAs. It seems that the main concern of the author is that the default work load parameters as employed by cryptocurrencies is not optimal to defend against hardware mining.
The author fails to explain why Salsa20 with 8 rounds is susceptible to an unnamed attack, but it largely seems that the author just favors a harder attack surface by default, which is reasonable, but doesn’t scrypt allow for this using its own configuration parameters? He also throws in a new KDF and a new hash algorithm from the SHA-3 competition for some reason, which raises red flags for me.
Thoughts? In any case, I’d like to see software like LUKS, GnuPG, et al replace PBKDF2 (or worse, GPG’s s2k) with scrypt and a configurable work factor. Thanks for making the RFC.
I’m working somewhat conservatively on this — scrypt has proven itself useful in a number of deployments already, so it deserves publication. If NeoScrypt catches on, it may be specified later, however I do agree with you that I don’t see any significant advantage over scrypt. I suspect that if something replaces scrypt as the state-of-the-art-and-recommended-solution, it will be the outcome of the PHC.
/Simon
Currently I am in a group headed by Steve Gibson of grc.com and we are using Scrypt as the PKDF for our SQRL project.
We found though that the bare Scrypt function was insufficient for our needs in being appropriately memory hard for a mobile platform ~16MB while maintaining a deterministic execution timed load ~1s. Because after we chose the appropriate N & R parameters there was only the P parameter left to add work, and that can be accelerated by parallel processing. Which undermines the requirements.
Thus we presently wrap the Scrypt function in an loop that XOR’s each output together while passing forward the hash of each prior loop as a salt for the next (the first salt being random), very much like plugging scrypt in as the random-function for PBKDF2, thus preventing parallel execution.
The iteration count and random salt on first use is thus known and added to the output for use in key validation later.
My question is then, would there be a way to add this deterministic work load into Scrypt without having to wrap it in something else?