The man walked into a bank many times over his life, no way he could decide to rob it one day.

You are creating a strawman.

The original argument is not "they created encryption that isn't broken before". The argument is "encryption created by competitions that are only refereed by NIST is trustworthy"

So it’s worse. They already robbed a bank in the past.

And lest we forget Dual_EC_DRBG

SHA3 is fine but it's so slow, I don't many people that use it

Slow? Fastest in HW, and comparable performance in SW. Moreover if you take into account security hardening, SHA3 is easier to protect than alternatives.

Faster than Blake2/3? Not even close!

> Faster than Blake2/3? Not even close!

Blake2 was not created (December 2012) until after the SHA-3 competition, which ended on October 2012 (Keccak being the winner). It was Blake1 that was entered. Blake3 was released in 2020.

I'm sure a Keccak2/3 could have also been better than the original Keccak1, but that was not available either.

You never specified timing. You made a blanket statement as if it was still true.

Comparable in software, to what? Password hashes? :)

Last I checked SHA3-512 is like 4x slower than SHA2-512 on x86.

And SHA-1 is faster than SHA-2, with MD5 faster than both. But speed isn't the only reason to choose an algorithm.

As a non cryptographer this whole conversation chain has me confused. I though it was desirable for a good hashing algorithm to be slow to make brute force difficult.

(Not a cryptographer either.) Consider two different application areas for a “hash”:

- Message digest: compute a fixed-size summary of a (relatively) large amount of data, for things like content-addressable storage or signing. You want this to be fast. (Nobody is going to brute-force even a 1K chunk of unknown data.) Examples: SHA2, Blake2b, Keccak aka SHA3.

- Key derivation: compute a small chunk of randomy data from a still-quite-small amount of substantially nonrandom data, for things like turning a user-specified password into an encryption key or (with a random salt) something you could store. You want this to be slow, even on a massively parallel machine. (You aren’t going to be processing logins that quickly; on the other hand, everybody’s going to be all over your leaked passwords table with their GPUs.) Examples: PBKDF2, bcrypt, Argon2id.

That's true for passwords (where you don't really use raw SHA or something, but rather something like bcrypt which is intentionally slow), not necessarily for all uses of passwords. E.g. computing a SHA sum of some binary doesn't need to be slow, it just has to be practically impossible to create a collision (which is what's required of every good cryptographic hash function).

Yeah this is a super common point of confusion. You need to worry about slowing down a brute force attacker when you're trying to protect a low-entropy secret, which basically always means user passwords. But when your secrets are big enough, like 128 bits, brute force becomes impossible just by virtue of the size of the search space. So for most cryptographic applications, it's the size of your key (and the fact that your hash or cipher doesn't _leak_ the key) that's protecting you from brute force, not the amount of time a single attempt takes.

Yeah SHA3 isn't directly for password hashing. You should use a memory strong PBKDF (password based key derivation function) like Argon2, bcrypt, or scrypt. These functions are all constructions that run the hash many times, so the underlying hash speed is irrelevant

For high entropy inputs, like for a HMAC signature, you want the hash to be fast because its practically impossible to brute force the 256bit input key, and you often apply this to large inputs.

SHA-2 is has more reliable HW acceleration from what I’ve seen.

SHA-1 SW according to smhasher is 350mib/s as is MD5, so never use MD5 as SHA-1 is always stronger (sha2 supposedly is 150mib/s). Hw accelerated SHA-1 and SHA-2 are both ~1.5 Gib/s and on x86 HW acceleration is always available.

Blake3 is the most interesting because it’s competitive with SHA2 even without HW acceleration. I wonder how it would fare with HW acceleration.

> Blake3 is the most interesting […]

Not really. SHA-2 was released in 2001:

* https://en.wikipedia.org/wiki/SHA-2

Blake3 was released 2020. I'm sure if the folks that created SHA-2 did a hash in 2020 they could do something better/faster as well.

First, each Blake version was written by a totally different authors AFAICT so while each version is faster, making a faster construction was a totally different team. I don't see why you're putting so much confidence that the original SHA-2 team could come up with a faster hash function.

FWIW, SHA-3 is slower than SHA-2 although of course SHA-3 is a totally different construction from SHA-2 by design.

SHA3 is mostly a hedge for the risk SHA2 is broken.

A competition is the perfect way to subvert a standard. A competition looks 'open', but in fact you can 'collaborate' with any team to make your weakened encryption and then persuade the judging panel to rate it highly.

But the competition process looks weird to me. Aparently it's not like a sports fixture, where the rules are set before the competition, and the referee just enforces the rules; this referee adjusts the rules while the competition is underway.

NIST has form for juking the standards, or at least for letting the NSA juke them. If they're not completely transparent, then any standard they recommend is open to question, which isn't good for a standard.