Hacker News Reader

Comment by tptacek | Hacker News Reader

I'd probably use a Blake too. But:

SHA256 was based on SHA1 (which is weak). BLAKE was based on ChaCha20, which was based on Salsa20 (which are both strong).

NIST/NSA have repeatedly signaled lack of confidence in SHA256: first by hastily organising the SHA3 contest in the aftermath of Wang's break of SHA1

No: SHA2 lacks the structure the SHA1 attack relies on it (SHA1 has a linear message schedule, which made it possible to work out a differential cryptanalysis attack on it).

Blake's own authors keep saying SHA2 is secure (modulo length extension), but people keep writing stuff like this. Blake3 is a good and interesting choice on the real merits! It doesn't need the elbow throw.

View on HN

While there is more confidence now on the security of SHA-2, or rather the lack of transference of the SHA-1 approach to SHA-2, this was not the case in 2005-2006 when NIST decided to hold the SHA-3 competition. See for example the report on Session 4 of the 2005 NIST workshop on hash functions [1].

[1] https://csrc.nist.gov/events/2005/first-cryptographic-hash-w...

Also, the NSA is currently recommending to change SHA3/Keccak inside Dilithium and Kyber into SHA2-based primitives... https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/SPTp...

For those who didn't click the link, it should be noted that they're suggesting this because it would be easier to deploy (in places that have a SHA-2 implementation but not SHA-3), not for reasons related to security or anything like that. Looking at the responses, there's also some disagreement on whether it would offer equal security for the particular use case of ML-DSA and ML-KEM (as the final version of Dilithium and Kyber standardized by NIST will be called).

> they're suggesting this because it would be easier to deploy (in places that have a SHA-2 implementation but not SHA-3), not for reasons related to security

That’s a bit absurd, right? Sure, the NSA didn’t overtly say, “we propose you use SHA-2 because we can break it.” That doesn’t mean it’s secure against them.

We can’t look at their stated justification for supporting one algorithm over another because the NSA lies. Their very _purpose_ as an organization is to defeat encryption, and one tactic is to encourage the industry to use something they can defeat while reassuring people it’s secure. We need to look at their recommendations with a lot of suspicion and assume an ulterior motive.

The NSA purpose is also to provide cybersecurity to protect US combat operations, which means they have to secure encryption.[1] I wouldn't go as far as to say the NSA should be trusted, or that they haven't tried to compromise encryption before, just that their motivations are contradictory.

Besides you aren't accounting for reverse psychology. What if SHA2 was insecure, and Blake was secure, and the NSA just tricked people into not using Blake by saying that it's secure? If we can't trust what the NSA says, it would be wisest to disregard what they say, rather than react to it.

[1] https://www.nsa.gov/About/Mission-Combat-Support/ We provide wireless and wired secure communications to our warfighters and others in uniform no matter where they are, whether traveling through Afghanistan in a Humvee, diving beneath the sea, or flying into outer space. Our cybersecurity mission also produces and packages the codes that secure our nation's weapons systems.

Additionally, we set common protocols and standards so that our military can securely share information with our allies, NATO and coalition forces around the world. Interoperability is a key to successful joint operations and exercises.

The article uses inferred NSA preferences as justification to avoid SHA2. Can't have it both ways.

Most people who publicly opine on the Blake vs. SHA2 debate seem to be relatively uninformed on the realities of each one. SHA2 and the Blakes are both usually considered to be secure.

The performance arguments most people make are also outdated or specious: the original comparisons of Blake vs SHA2 performance on CPUs were largely done before Intel and AMD had special SHA2 instructions.

The author is one of the creators of blake3, Zooko.

Sorry, I should have been more precise. JP Aumasson is specifically who I'm thinking of; he's made the semi-infamous claim that SHA2 won't be broken in his lifetime. The subtext I gather is that there's just nothing on the horizon that's going to get it. SHA1 we saw coming a ways away!

Quoting directly from https://nostarch.com/crypto-dictionary under the entry SHA-2:

> Unlike SHA-1, SHA-2 algorithms aren’t broken and are unlikely to ever be.

There's also the fact NIST themselves deprecated SHA-1 in 2011 (https://csrc.nist.gov/news/2017/research-results-on-sha-1-co... not mentioned, but otherwise nice timeline here: https://crypto.stackexchange.com/a/60655), yet SHA-2 is still OK. Wiki has a table of cryptanalysis of SHA-2: https://en.wikipedia.org/wiki/SHA-2#Cryptanalysis_and_valida...

The summary is that either you attack a very reduced round variant and you get "practical" complexity for the attack, or you attack almost a full round variant and you get an entirely practical attack.

So I think your interpretation of the subtext is entirely correct.

Who I'm sure actually is informed, but in this particular case is tweeting things that do honestly sound like one of the uninformed commentators pclmulqdq mentioned. I'm not sure why, since as tptacek said, blake3 is good and maybe even preferable on it's own merits without venturing into FUD territory. And if you still wanted to get into antiquated design arguments, picking on SHA256's use of a construction that allows length extension attacks seems like more fair game.

Would be interesting to hear Zooko's response to this. (Peergos lead here)

What do you mean by "weak" and "strong", here?

There are fundamentally two kinds of attacks, preimage which splits into two:

In a first-preimage attack, you know a hash value but not the message that created it, and you want to discover any message with the known hash value; in the second-preimage attack, you have a message and you want to find a second message that has the same hash. Attacks that can find one type of preimage can often find the other as well. A weak algorithm allows this to be done in less than 2^(hash length) attempts.

And then there is collision: two messages which produce the same hash. A weak algorithm allows this to be done in less than 2^(half of hash length) attempts.

Source: https://www.rfc-editor.org/rfc/rfc4270

Weak means that a mathematical flaw has been discovered that makes it inherently insecure, or that it is so simple that modern computer technology makes it possible to use “brute force” to crack. Strong means that it's not either.

Reply on news.ycombinator.com