Live data from Hacker News

Blake3 is 10 times faster than SHA-2

nextjournal.com

41–50 of 171 posts

Re: Blake3 is 10 times faster than SHA-2

#41

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?

We often use 'hash' as a sort-hand way of saying 'Key Derivation Function' when talking about secrets like passwords. https://en.wikipedia.org/wiki/Key_derivation_function

These functions usually use hashes as a primitive, but there is more to them than that. Using a plain hash to store passwords is usually a red flag that the storage is insecure. I see it when doing source code audits: some legacy software using md5 without a salt.

To be precise I think security community should make an effort to separate the two terms more often. I've been trying to be more precise when writing and reviewing assessment reports.

Re: Blake3 is 10 times faster than SHA-2

#42
post #24
post #21

What are the criteria for choosing an integrity checking hash? Speed is always desired, and longer output makes collisions due to random bit swaps less likely. Even CRC32 is still used in embedded systems for short pieces of data. Is there anything else important for detecting transmission errors if the data was sent encrypted, or is something like MD5 still sufficient for such uses? Is Blake3 even worth considering…

Never use MD5 except for compatibility.

This. There are hash functions that are faster than MD5, so it's not the fastest, and everyone knows (since 1996, actually[1]) that MD5 is insecure.

If you want transmission error checking, use CRC32 or Siphash or whatever. If you want an actual, cryptographic hash function, then BLAKE3 is one of the options, though it's a very young one so unless you really know what you're doing, you should probably not use this for another few years. Heck, if anything in this comment is new to you, you'll want to steer clear of such low-level decisions and just use a library that makes the decision for you.

[1] https://en.wikipedia.org/wiki/MD5 "In 1996, Dobbertin announced a collision of the compression function of MD5 (Dobbertin, 1996). While this was not an attack on the full MD5 hash function, it was close enough for cryptographers to recommend switching to a replacement, such as SHA-1 or RIPEMD-160."

Re: Blake3 is 10 times faster than SHA-2

#43
post #23
post #13

Earlier quoted context omitted.

> For password hashing you’re correct they should be slow, bcrypt for example. Slowness is not the quality of a hashing algorithm that guarantees anything :)

You're being pointlessly pedantic. The commenter above obviously meant "slow to brute-force". You're pedantically interpreting it to mean "slow for a given implementation, even if there are some scenarios under which it would be faster to brute force". What the parent comment meant is clear enough I think, and it's accurate in that context. The whole point of modern hashing algorithms that require memory and have sca…

Wow, so offensive. Didn't mean it that way, but if it turned out that, what a heck then. What I wanted to say was that slowness is not necessary attribute, unless we really seek it. If we could get very good and quick algorithm without being it slow, we would use it. Thanks for misinterpreting my smiley too. Have a good evening there.

Re: Blake3 is 10 times faster than SHA-2

#44

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?

We often use 'hash' as a sort-hand way of saying 'Key Derivation Function' when talking about secrets like passwords. https://en.wikipedia.org/wiki/Key_derivation_function These functions usually use hashes as a primitive, but there is more to them than that. Using a plain hash to store passwords is usually a red flag that the storage is insecure. I see it when doing source code audits: some legacy software using md5…

Unfortunately, not all password hashing algorithms are key derivation functions. That's just a common design and closely related.

Re: Blake3 is 10 times faster than SHA-2

#45
post #34
post #25

Earlier quoted context omitted.

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 )

It was announced in a lightning talk following that session

Re: Blake3 is 10 times faster than SHA-2

#46
This benchmark is not a comparison between BLAKE3 and SHA-2, it’s a comparison between b3sum and sha2sum. Things like file access pattern, hiding io latency, distributing work to cores, etc can make huge differences that have nothing to do with the hash functions themselves.

Re: Blake3 is 10 times faster than SHA-2

#47

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

Yes, and it didn't go unnoticed that KangarooTwelve (which - mind - does not belong to the SHA-3 family right now) is not included on that prominent comparison diagram, while it is considered in the BLAKE3 paper.

Re: Blake3 is 10 times faster than SHA-2

#48
post #40

Earlier quoted context omitted.

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.

Author here, I did run it a few times but you don’t have to take my word for it, you can rerun the notebook yourself if you sign up for Nextjournal and remix my notebook. Full disclosure: I’m also a Cofounder of Nextjournal.

But I wouldn’t suggest to use Nextjournal for serious benchmarking (yet). We’re running on Google Cloud and it’s not suited for benchmarking unless you pay for a (big) sole tenant instance. In the future we plan to offer dedicated instances for benchmarking.

Re: Blake3 is 10 times faster than SHA-2

#50

Earlier quoted context omitted.

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

Yes, and it didn't go unnoticed that KangarooTwelve (which - mind - does not belong to the SHA-3 family right now) is not included on that prominent comparison diagram, while it is considered in the BLAKE3 paper.

That's a good point; I was just giving you a handy chart with an explicitly called out platform :)
Post reply on HN