Comment by henns | Hacker News Reader

Comment by henns | Hacker News Reader

Parent Full thread

I think this misses the point: we should be doing everything we can to deprecate PBKDF2 because of the big differences between what a specialized attacker can do vs. the defender.

As a rough estimate: a $2k bitcoin miner can do 2^45 SHA-256 hashes/sec whereas your $2k laptop can do 2^16 hashes/sec; the attacker has ~a billion x advantage over you that can be multiplied based on their funding. At that point, doing even 10,000 PBKDF2 hashes may not make much of a difference.

argon2, scrypt and other memory hard password hashing algorithms reduce the orders of magnitude advantages of the attacker by requiring RAM. Attackers might be able to purchase RAM cheaper than the defender, but nothing close to a billion times cheaper.

Addressing concern #3 (want to have a password set on a laptop that decodes in a reasonable amount of time on a low-end smartphone), you could restrict the RAM to some small amount (like 256MB) if you anticipate needing to use a low-end device. This will still be a vast reduction in the attacker's advantage over PBKDF2.

I think the important point is that Bitcoin mining hardware is much more specialized than that. The really crazy fast ASICs are hardwired to do SHA-256 hashes of Bitcoin block headers only and just increment the Bitcoin nonce before repeating. They can't be repurposed to crack password hashes.

They may not be repurposable per se, but they are a great benchmark for what may be realistically achievable for cracking password hashes utilizing similar base algorithms.

One thing to keep in mind: a lot of the die real estate in modern processors is spent on doing tasks other than calculating hashes (a lot of it is caches https://www.servethehome.com/amd-epyc-7000-series-architectu... ).

Someone using an FPGA or ASIC can dedicate almost all of the die to creating lots of SHA-256 units.

AFAIK, the base algorithms here are custom-fabricated ASICs. If your adversary can custom-fab ASICs to break hashes in your PW manager password in PBKDF2-SHA256, no reason they couldn't make one in whatever harder algorithm you could come up with.

ASIC doesn't work well when a lot of RAM is required.

A $2k computer can do billions of hashes a second. 2^30

You're off by about 20 orders of magnitude (the joy of binary exponents).

Thanks for pointing out that I was off in my original estimate (a hasty web search showed the wrong cryptocurrency; almost nobody mines bitcoin on CPUs anymore :).

From what I can see, a more realistic estimate for a single core on a desktop is in the 2^26 range. Keep in mind that the PBKDF2 defender is single-threaded by design, whereas the attacker is not.

This still represents ~a half million x advantage for the attacker/$2k they spend. For $1m, they can guess passwords ~200 million times faster than you.

If we assume memory is the limiting factor for argon2, then even if a specialized attacker can use it at scale for 1/20th the cost, a 20x advantage is much better for the defender than a 500,000x advantage.

I'm confused, 2^14 = 16384 is slightly more than 4 orders of magnitude, where did you get 20 from?

An "order of magnitude" has no precise numerical meaning, it depends on what base you're working in. If the log of the number in base b increases by 1, you've increased 1 order of magnitude with respect to that base. (I don't know why the parent said "20", my instinct is to say 14 orders of magnitude here.)

I've usually heard it being used to describe powers of 10. I'd be willing to accept 14 orders of magnitude since we're talking about powers of 2, but I still can't figure out where they got 20 from. Hence my question.

One billion is 14 orders. We're talking billionS, that's a fair bit more (pun intended).

Maybe they forgot that Windows calculator doesn't respect order of operations...

This is interesting because the OP claims that this is exactly the reason they use PBKDF, because there aren't "highly optimized implementations [of other crypto algorithms] for all platforms":

> What is crucial here is that we don't want to have the defender stuck with a slow implementation of something that the attacker will have a highly optimized implementation for.

After a programmer changed PBKDF2 to use SHA512 instead of SHA-1, I asked whether it made sense to use SHA256 instead for this very reason. With SHA extensions on Intel (pretty rare, incidentally), and the cryptography extension on ARM, I wondered if SHA256 (with more iterations) might put defenders at less of a disadvantage relative to attackers than SHA512.

Reply on news.ycombinator.com