Why I Don't Recommend Scrypt (2014) | Hacker News Reader

Why I Don't Recommend Scrypt (2014)

blog.ircmaxell.com

31 pointskrn14 comments

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?)

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

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!)

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.

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

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

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).

The very fact that it's near collisions vs direct collision. You're correct that having dedicated ASIC's does increase the hash-rate, and thus could lower the time-bounds. But the dedicated ASIC's are only really expanding the I/O interface to get more data in/out, and due to this have a much higher cost.

The PoW system adjusts the difficulty based on the current distributed hash-rate, so an individual(or pool) is operating in a percent range of the total hash-rate.

To analogize the two, properly, you'd have to set the PoW system to the highest difficulty, and keep it there for every individual password you want to check.

Also the scrypt currencies have a fixed memory bound, AFAIK. While use in password cases, "could be" modified in the middle, doubling the required time-bound.

If ASIC cryptocurrency miners could find collisions for an entire key in a reasonable lifetime, cryptocurrencies based on scrypt would be literally worthless. But, they can't. They can find partial collisions.

ASICs for SHA256 don't break SHA256, and ASICs for scrypt don't break scrypt.

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

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.

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.)

That sabotage was "necessitated" by the desire for fast proof-of-work verification.

With hashcash, proof attempt is as hard as proof verification, but there are other asymmetric schemes where the former is much harder.

The first such PoW was primecoin. My own design Cuckoo Cycle is another, that aims to be the most memory bound of all PoWs.

> That sabotage was "necessitated" by the desire for fast proof-of-work verification.

Oh, I understand why they did it. But it still removed the most important property of scrypt. We wouldn't have scrypt ASICs if that change hadn't been made.

Reply on news.ycombinator.com