Reasons to Prefer Blake3 over Sha256

I&#x27;d probably use a Blake too. But:<p><i>SHA256 was based on SHA1 (which is weak). BLAKE was based on ChaCha20, which was based on Salsa20 (which are both strong).</i><p><i>NIST&#x2F;NSA have repeatedly signaled lack of confidence in SHA256: first by hastily organising the SHA3 contest in the aftermath of Wang&#x27;s break of SHA1</i><p>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).<p>Blake&#x27;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&#x27;t need the elbow throw.

Good, terse article that basically reinforces everything I&#x27;ve seen in my research about cryptographic hashing.<p>Context: I&#x27;m building a VCS meant for any size of file, including massive ones. It needs a cryptographic hash for the Merkle Tree.<p>I&#x27;ve chosen BLAKE3, and I&#x27;m going to use the original implementation because of its speed.<p>However, I&#x27;m going to make it easy to change hash algorithms <i>per commit</i>, just so I don&#x27;t run into the case that Git had trying to get rid of SHA1.

For short inputs, Blake3 behaves very similar to Blake2, on which it is based. From Blake&#x27;s wikipedia page [1]:<p>BLAKE3 is a single algorithm with many desirable features (parallelism, XOF, KDF, PRF and MAC), in contrast to BLAKE and BLAKE2, which are algorithm families with multiple variants. BLAKE3 has a binary tree structure, so it supports a practically unlimited degree of parallelism (both SIMD and multithreading) given long enough input.<p>[1] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;BLAKE_(hash_function)" rel="nofollow noreferrer">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;BLAKE_(hash_function)</a>

While I really like Blake3, for all reasons mentioned in this article, I have to say it does have one tiny disadvantage over older hashes like SHA-256: its internal state is slightly bigger (due to the tree structure which allows it to be highly parallelizable). This can matter when running on tiny microcontrollers with only a few kilobytes of memory.

Blake3 is a clear winner for large inputs.<p>However, for smaller inputs (~1024 bytes and down), the performance gap between it and everything else (blake2, sha256) gets much narrower, because you don&#x27;t get to benefit from the structural parallelization.<p>If you&#x27;re mostly dealing with small inputs, raw hash throughput is <i>probably</i> not high on your list of concerns - In the context of a protocol or application, other costs like IO latency probably completely dwarf the actual CPU time spent hashing.<p>If raw performance is no longer high on your list of priorities, you care more about the other things - ubiquitous and battle-tested library support (blake3 is still pretty bleeding-edge, in the grand scheme of things), FIPS compliance (sha256), greater on-paper security margin (blake2). Which is all to say, while blake3 <i>is</i> great, there are still plenty of reasons not to prefer it for a particular use-case.

I agree that if you can, BLAKE3 (or even BLAKE2) are nicer choices than SHA2. However I would like to add the following comments:<p>* SHA-2 fixes the problems with SHA-1. SHA-1 was a step up over SHA-0 that did not completely resolve flaws in SHA-0&#x27;s design (SHA-0 was broken very quickly).<p>* JP Aumasson (one of the B3 authors) has said publicly a few times SHA-2 will never be broken: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=13733069">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=13733069</a> is an indirect source, can&#x27;t seem to locate a direct one from Xitter (thanks Elon).<p>Thus it does not necessarily follow that SHA-2 is a bad choice because SHA-1 is broken.

What I dislike about BLAKE3 is that they added explicit logic to ensure that identical chunks stored at different offsets result in different Merkle tree nodes (a.k.a. the ‘chunk counter’).<p>Though this feature is well intended, it makes this hash function hard to use for a storage system where you try to do aggressive data deduplication.<p>Furthermore, on platforms that provide native instructions for SHA hashing, BLAKE3 isn’t necessarily faster, and certainly more power hungry.

At this rate, it&#x27;s going to take over 700 years before we get Blake&#x27;s 7

It&#x27;s an interesting set of reasons, but I prefer Keccak&#x2F;SHA-3 over SHA-256, SHA-512, and BLAKE. I trust the standards body and public competition and auditing that took place - more so than a single author trumpeting the virtues of BLAKE.

Until it starts coming installed by default on Linux and other mojor OS&#x27;s, it won&#x27;t be mainstream.

At the end of the day, what really matters for most people is<p>1) Certifications (FIPS...)<p>2) Speed.<p>SHA-256 is fast enough for maybe 99,9% of use cases as you will saturate your I&#x2F;O way before SHA-256 becomes your bottleneck[0][1]. Also, from my experience with the different available implementations, SHA-256 is up to 1.8 times faster than Blake3 on arm64.<p>[0] <a href="https:&#x2F;&#x2F;github.com&#x2F;skerkour&#x2F;go-benchmarks&#x2F;blob&#x2F;main&#x2F;results&#x2F;scaleway_amp2_c8.txt">https:&#x2F;&#x2F;github.com&#x2F;skerkour&#x2F;go-benchmarks&#x2F;blob&#x2F;main&#x2F;results&#x2F;...</a><p>[1] <a href="https:&#x2F;&#x2F;kerkour.com&#x2F;fast-hashing-algorithms" rel="nofollow noreferrer">https:&#x2F;&#x2F;kerkour.com&#x2F;fast-hashing-algorithms</a>

Fast hash functions are really important, and SHA256 is really slow. Switching the hash function where you can is enough to result in user-visible speedups for common hashing use cases; verifying build artifacts, seeing if on-disk files changed, etc. I was writing something to produce OCI container images a few months ago, and the 3x SHA256 required by the spec for layers actually takes on the order of seconds. (.5s to sha256 a 50MB file, on my 2019-era Threadripper!) I was shocked to discover this. (gzip is also very slow, like shockingly slow, but fortunately the OCI spec lets you use Zstd, which is significantly faster.)

&gt; BLAKE3 is much more efficient (in time and energy) than SHA256, like 14 times as efficient in typical use cases on typical platforms.<p>[snip]<p>&gt; AVX in Intel&#x2F;AMD, Neon and Scalable Vector Extensions in Arm, and RISC-V Vector computing in RISC-V. BLAKE3 can take advantage of all of it.<p>Uh huh... AVX&#x2F;x86 and NEON&#x2F;ARM you say?<p><a href="https:&#x2F;&#x2F;www.felixcloutier.com&#x2F;x86&#x2F;sha256rnds2" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.felixcloutier.com&#x2F;x86&#x2F;sha256rnds2</a><p><a href="https:&#x2F;&#x2F;developer.arm.com&#x2F;documentation&#x2F;ddi0596&#x2F;2021-12&#x2F;SIMD-FP-Instructions&#x2F;SHA256H2--SHA256-hash-update--part-2--" rel="nofollow noreferrer">https:&#x2F;&#x2F;developer.arm.com&#x2F;documentation&#x2F;ddi0596&#x2F;2021-12&#x2F;SIMD...</a><p>If we&#x27;re talking about vectorized instruction sets like AVX (Intel&#x2F;AMD) or NEON (aka: ARM), the advantage is clearly with SHA256. I don&#x27;t think Blake3 has any hardware implementation at all yet.<p>Your typical cell phone running ARMv8 &#x2F; NEON will be more efficient with the SHA256 instructions than whatever software routine you need to run Blake3. Dedicated hardware inside the cores is very difficult to beat on execution speed or efficiency.<p>I admit that I haven&#x27;t run any benchmarks on my own. But I&#x27;d be very surprised if any software routine were comparable to the dedicated SHA256 instructions found on modern cores.

I don’t understand why people use sha256 when sha512 is often significantly faster:<p><a href="https:&#x2F;&#x2F;crypto.stackexchange.com&#x2F;questions&#x2F;26336&#x2F;sha-512-faster-than-sha-256" rel="nofollow noreferrer">https:&#x2F;&#x2F;crypto.stackexchange.com&#x2F;questions&#x2F;26336&#x2F;sha-512-fas...</a>

One metric that is seldom mentioned for crypto algos is code complexity.<p>I really wish researchers would at least pay lip service to it.<p>TEA (an unfortunately somewhat weak symmetric cipher) was a very nice push in that direction.<p>TweetNaCl was another very nice push in that direction by djb<p>Why care about that metric you ask?<p>Well here are a couple of reasons: - algo fits in head - algo is short -&gt; cryptanalysis likely easier - algo is short -&gt; less likely to have buggy implementation - algo is short -&gt; side-channel attacks likely easier to analyse - algo fits in a 100 line c++ header -&gt; can be incorporated into anything - algo can be printed on a t-shirt, thereby skirting export control restrictions - algo can easily be implemented on tiny micro-controllers<p>etc ...

How does the extended output work, and what&#x27;s the point of extended output?<p>From what I can see, BLAKE3 has 256 bits of security, and extended output doesn&#x27;t provide any extra security. In this case, what&#x27;s the point of extended output over doing something like padding with 0-bits or extending by re-hashing the previous output and appending it to the previous output (eg, for 1024 bits, doing h(m) . h(h(m)) . h(h(h(m))) . h(h(h(h(m))))). Either way, you get 256 bits of security.<p>Is it just because the design of the hash makes it simple to do, so it&#x27;s just offered as a consistent option for arbitrary output sizes where needed, or is there some greater purpose that I&#x27;m missing?

When it’s said SHA2 will remain secure in foreseeable future, are there estimates on the number of decades?<p>The quantum computers apparently don’t help much with hash attacks, and SHA2 has received a lot of cryptanalysis.

It&#x27;s very hard to see Blake3 getting included in FIPS. Meanwhile, SHA256 is. That&#x27;s probably the biggest deciding factor on whether you want to use it or not.

I replaced sha with blake in my deduplication needs, and it sped up the comparisons by a factor of 4 at least.<p>For my use case, it is great

Keccak is my preference. Keccak is substantially easier to implement in hardware: fewer operations and no carry propagation delay issue because there&#x27;s no addition.

I&#x27;m holding out for BLAKE7, personally

SHA-256 has the advantage that it is used for BitCoin. It is the biggest bug bounty of all time. There see literally billions riding on the security of SHA-256.

murmur3

There has been a mountain of cryptanalysis done on SHA256 with no major breaks compared to a much smaller amount analysis on blake3.

It bears mentioning `shasum` is better supported in that it ships with operating systems (macOS, I guess Linux depends on the distro, don’t know about Windows) and is available directly from programming languages (Ruby, Swift, Python, …) without the need for libraries.<p>Even if BLAKE3 is massively faster, it’s not like I ever noticed SHA256’s supposed slowness. But I do notice its ubiquity.<p>Based on the article, I would consider switching to BLAKE3 immediately where I use checksums. But until it gets wider support (might be easier with a public domain license instead of the current ones) I can’t really do it because I need to do things with minimal dependencies.<p>Best of luck to the BLAKE3 team on making their tool more widely available.