Hacker News Reader

Comment by jimrandomh | Hacker News Reader

SHA-256 is used for Bitcoin mining, which serves as an enormous bug bounty for both full and partial breaks (if you can efficiently find inputs where the output has lots of leading zeroes that's a partial break, and lets you mine bitcoin more efficiently). That's worth a lot of trust. I don't see any particular reason to think SHA-3 is better (though I'm not an expert) and unless I hear some indication that a problem has been found with SHA-2, I'll probably stick with it forever.

View on HN

Bitcoin mining uses double SHA-256. It tends to be harder to break doubled hash functions, since you don't have tools like length-extension attacks on the second round of hashing. For example, HMAC-SHA-1 is still secure (despite SHA-1 being pretty much broken), and it also uses a two-round hashing construction.

Even if it didn’t sha as a hmac is still fine because the length it takes to break. You can’t break sha1 in the time it takes for your packet to go through the hmac step.

SHA-256 is vulnerable to a length extension attack. This is well-known to cryptographers; it doesn’t matter for some applications and can be worked around in others. But it still catches some developers unaware.

https://en.wikipedia.org/wiki/Length_extension_attack

I didn't expect such attacks to exist, thanks for bringing that up. However that Wikipedia page seem to say sha-256 is ok since it's truncated?

Sha-224 and Sha-384 are the truncated versions of Sha-256 and Sha-512 respectively.

My boring hash function of choice is Sha-384. The Sha-512 computation is faster on Intel hardware, and ASICS to crack it are far more expensive than Sha-256 because of bitcoin.

If you're hashing passwords or something, use a "harder" hash like Argon2 or Scrypt.

SHA-512 is faster only on Skylake derivatives up to Comet Lake and on older Intel Core CPUs.

On Intel Atom starting with Apollo Lake (2016) and on Intel Core starting with Ice Lake (2019) and on all AMD Zen CPUs (2017), SHA-256 is implemented in hardware and it is much faster than SHA-512.

SHA-256 is not truncated. "SHA-512/256" is truncated. It means you do SHA-512 (with a different starting state) and then throw out half.

There are increasingly few situations in which length extension really matters, because we know more about designing protocols than we did 20 years ago; even code that uses SHA3 or Blake2 tends to still use HMAC. Further, there are standard variants of SHA2 that don't have length extension (they're truncated and don't disclose their full state). It's better to not have length extension properties than to have them, but it's not really a big part of the desiderata.

I’m always confused when people slam sha on hmac. Is there a realtime sha back door I’m missing? Even sha 1 takes days/months to break.

I don't understand what you're asking here. Don't use HMAC as a password hash? HMAC keys should be a long string of uncorrelated bits, not ASCII strings?

It is often worked around. But from what I understand the length extension issue was raised during the design but ignored. Hashing is not encryption but some of the recommended encryption standards are so complicated that it is a risk just by itself.

SHA-384 is a truncated SHA-512. From the claims of sec people it does not offer more security when it comes to length attacks. But from how the algo works I would assume that it does.

Nist is also plain wrong about their calculations. Cause how long it takes to calculate a specific hash depends on the hardware available, not what theory books says. It may in practice be faster to calculate a hash with more bits.

Bitcoin mining uses double SHA256 which is not subject to length extension attacks. (Not that it matters, because bitcoin block headers are fixed length.)

In my research into Ethereum, I learned that in the creation of SHA-3, they did a lot of hammering on SHA-256 to see if new weaknesses could be discovered and addressed. The conclusion was that SHA-256 is still solid as far as anyone can tell. The SHA-3 process moved forward anyway so they could have a backup-plan handy in case some problem with SHA-256 pops up out of nowhere.

> if you can efficiently find inputs where the output has lots of leading zeroes that's a partial break, and lets you mine bitcoin more efficiently

Depends on the type of break. If the break only allows finding a hash with 128+k leading zeroes in 2^{128+k/2} time, that would still be quite useless for bitcoin mining.

The break would have to cover the bitcoin regime of around 78 leading 0s.

Reply on news.ycombinator.com