
Why I Don't Recommend Scrypt (2014) - krn
http://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scrypt.html
======
csirac2
It's a strange title, given that towards the end it seems more like he's
recommending to not bother migrating from bcrypt to scrypt (if you're already
using bcrypt).

But now I'm curious: the author states that neither scrypt or PBKDF2 are
really designed for password _storage_. Can anyone explain how a construction
designed for this purpose would differ?

Edit: I get that one of the goals for a KDF is to securely hash/expand a short
input (password) of N bits out to something potentially >> N bits; and in the
case of scrypt, do it in a way that's expensive for bruteforcers but
acceptable for authentication.

Is the reason scrypt/PBKDF2 aren't for password "storage" simply because
they're not usable as such OOB (missing salt handling which bcrypt gives you
for free?)

~~~
timmclean
KDFs are definitely suitable for password storage, so I'm pretty confused at
how the author arrived at their conclusion. They mention that scrypt with low
security params is less secure than bcrypt at an adequate security setting.
This doesn't seem particularly alarming or even surprising.

I think a better take away would be: "If you use scrypt, make sure you choose
adequate security parameters. If you're already using bcrypt, there's no need
to switch to scrypt."

Edit: the first paragraph of the scrypt paper actually brings up the fact that
the problems of password storage and key derivation are equivalent:

 _Password-based key derivation functions are used for two primary purposes:
First, to hash passwords so that an attacker who gains access to a password
file does not immediately possess the passwords contained therewithin; and
second, to generate cryptographic keys to be used for encrypting and /or
authenticating data. While these two uses appear to be cryptologically quite
different [...] they turn out to be effectively equivalent_

[https://www.tarsnap.com/scrypt/scrypt.pdf](https://www.tarsnap.com/scrypt/scrypt.pdf)

------
lisper
The only relevant part (AFAICT):

"scrypt is demonstrably weaker than bcrypt for password storage when using
memory settings under 4mb"

So don't use memory setting under 4MB. (Duh!)

------
yeukhon
The fact that today's GPU is memory-bounded does it mean we can't foresee one
not memory-bounded in ten years?

I often think with the number of hosts in all the botnets out there, some
attackers are probably distributing some of the hard work.

------
aosmith
ASICs to crack scrypt (depends on compat) are also widely available...

~~~
SwellJoe
Are there? You're not talking about ASICs for cryptocurrency mining (which is
a different problem being solved)?

~~~
throwaway304056
How is this a different problem?

Yes, PoW is trying to find near collisions, and password cracking is trying to
find direct collisions, but its collisions still the same. What is important
here is 'hashrate' which gives you bounds on time to crack your dataset (or
find a near collision).

~~~
cperciva
The scrypt used in cryptocoins has been sabotaged by limiting the amount of
RAM it uses.

~~~
SwellJoe
But, even sabotaged in that way, ASICs still aren't able to compromise keys,
right? (Just as ASICs for SHA256 don't compromise Bitcoin keys.)

I'm not suggesting this clarification isn't useful, but I was replying to
someone claiming that scrypt is effectively broken because there are ASICs for
computing scrypt hashes, which according to my understand is not correct.

~~~
cperciva
There is no hard line for "broken" when you're talking about password hashing.
The availability of ASICs brings the cost per hash down significantly though.
(If it didn't, nobody would bother designing ASICs.)

