Live data from Hacker News

Blake3 is 10 times faster than SHA-2

nextjournal.com

31–40 of 171 posts

Re: Blake3 is 10 times faster than SHA-2

#34
post #25
post #16

Speed comparison from the BLAKE3 authors: https://github.com/BLAKE3-team/BLAKE3/ I hadn't heard of BLAKE3 before (I thought BLAKE2b was the latest and greatest), judging by commits from the repositories of that user it's about half a year old now. Paper's abstract starts with: > BLAKE3 [is] an evolution of the BLAKE2 cryptographic hash that is both faster and also more consistently fast across different platforms and…

The reason you haven't heard of it before now is that it was released 2020-01-09, last Thursday at the time of writing, at Real World Crypto.

The only author of BLAKE3 that spoke there was JP (@veorq). The day matches but the title of his talk is "Too Much Crypto". Is that where it was announced? (Quick link to program: https://rwc.iacr.org/2020/program.html#day-2020-01-09)

Re: Blake3 is 10 times faster than SHA-2

#35

This is a bit pointless, since it does not say on which platform the comparison is made. In any case, KangarooTwelve [1][2] (on AVX-512) is also 10x faster than SHA-256. KangarooTwelve is a fast hash function of the Keccak family (from which the SHA-3 derives from), and it is clearly what BLAKE3 tries to catch up with. However, KangarooTwelve probably benefits from the more extensive scrutiny that SHA-3 has received…

There is a comparison of Blake3 to various hash functions (including SHA-2 and SHA-3 families) on AWS c5.metal; see the chart here: https://github.com/BLAKE3-team/BLAKE3

Re: Blake3 is 10 times faster than SHA-2

#36

Uhhh, I have an idea how sha-256 works but not blake3. Is blake3 better for storing passwords? If not, what is the go-to recommended hash for password storage of say, a simple front-facing app for consumers.

Neither is especially good for storing passwords.

Better use specialized password hashing functions like Argon2 or bcrypt.

Re: Blake3 is 10 times faster than SHA-2

#37

Uhhh, I have an idea how sha-256 works but not blake3. Is blake3 better for storing passwords? If not, what is the go-to recommended hash for password storage of say, a simple front-facing app for consumers.

SHA-256 is absolutely not recommended for storing passwords, and it was never designed for that purpose. If you are storing passwords with SHA-256 you should immediately migrate them to a password hashing algorithm. See “Upgrading Legacy Hashes” in the link below.

https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...

Recommended algorithms:

- Argon2

- PBKDF2

- Bcrypt

Re: Blake3 is 10 times faster than SHA-2

#38
post #14

Is "faster" always a good thing in hashing algorithms? Suppose a hashed password database falls into wrong hands. If they're hashed with a faster algorithm wouldn't it be easier to try a dictionary attack to discover the real passwords?

You can always make a fast hashing algorithm into a slow-enough password hashing algorithm by repeating it multiple times (as with PBKDF2) or better yet using a construction that also uses a minimum amount of memory, not just computational time. For most cryptographic applications (signing data in transit, signing data at rest, computing things like Merkle trees for applications like git and dm-verity), you want a ha…

[deleted]

Re: Blake3 is 10 times faster than SHA-2

#39
post #7

Not really. It's even 2x slower than SHA256-NI, the builtin. b3sum is much faster than sha256sum, and blake3 is about 2x faster than blake2. http://rurban.github.io/smhasher/doc/table.html

Just exactly what does the "insecure" flag mean in your tables? I'm curious about the kind of definition you are using for security whereby sha2 fails but farmhash passes.

"insecure" means that it fails any of the security tests.

SHA2NI and many other hashes fail most of those unless they are hardened, e.g. by support for adding random seeds, being insensitive to added \0 and such. No crypto hash supports random seeds out of the box btw.

Re: Blake3 is 10 times faster than SHA-2

#40
post #10

Do the runtime tests decouple from I/O times e.g. file and memory caching aren't affecting the results? Surprised because I'd expect a big file like that to be I/o bound in practice

There is a tech talk about Bao (I think it’s the same author) where he prefaced the talk by describing a few caveats like “benchmarks are lies” and he mentioned that you should always run a timed process a second time to tease out bias from cached/pages instructions and data. The core reason this method is faster than traditional SHAs is because Blake3 is a binary tree where the leaf blocks can be hashed in parallel…

> you should always run a timed process a second time

I should hope that anyone doing benchmarks does them multiple times to avoid crap like popcon or adobe reader update randomly keeping the system busy during one of the two algorithms' benchmarks. I don't expect that the author ran this only once and decided to make a blog post based on that, even if the post doesn't show multiple runs.

Post reply on HN