> Blake3 is fast, several times faster than ChaCha20 on my machine The speed differences between BLAKE3 and ChaCha20 depend a lot on what benchmarks you run, a

> Blake3 is fast, several times faster than ChaCha20 on my machine The speed differences between BLAKE3 and ChaCha20 depend a lot on what benchmarks you run, and I want to elaborate a bit on the details, in case anyone running benchmarks sees something different and wonders why. The whole BLAKE family is derived from ChaCha, and there are some close performance relationships between them. As CiPHPerCoder pointed out in another comment, what the BLAKE family calls "rounds" are what ChaCha calls "doublerounds", so we need to multiply by two to compare them. Since BLAKE3 does 7 rounds, its performance should be vaguely similar to ChaCha14, or a factor of ~20/14 faster than ChaCha20. SIMD optimizations matter an enormous amount here. An implementation of BLAKE3 or ChaCha20 using recent AVX-512 SIMD instructions and running on a CPU that supports them, can be an order of magnitude faster than a generic implementation. This affects both functions equally, but it means that you need to be very carful when benchmarking, to make sure that the implementations you're testing have all been similarly optimized. One wrinkle here is that, even if BLAKE3 and ChaCha20 are both implementated with AVX-512 optimizations, ChaCha20 will be able to take advantage of many of those optimizations at smaller input sizes. That's because each 64-byte ChaCha20 output block is independent of all the others, so full AVX-512 parallelism can kick in at 16*64 = 1024 bytes of output. (The number 16 comes from the fact that ChaCha20 and BLAKE3 use 32-bit words, and 16 of those words fit in a 512-bit vector.) In contrast, BLAKE3 on the input side needs to parallelize 1024-byte chunks/leaves, rather than individual blocks, so it needs 16*1024 = 16384 bytes of input to reach the same degree of parallelism. So if you benchmark an input size below 16 KiB, you might find that ChaCha20 is faster for that reason. (Note that BLAKE3's output side is more similar to ChaCha20 than it is to BLAKE3's input side. But in practice the official BLAKE3 implementations have some missing optimizations in the XOF.) Another difference that will come up is multithreading. Both BLAKE3 and ChaCha20 can be multithreaded in theory, but multithreading ChaCha20 is almost never done. This is for a few reasons: 1) BLAKE3's multithreading capabilities have to do with its Merkle tree structure and are one of the things that make it special, so of course the official implementation wants to showcase that. In contrast, any block-based stream cipher like AES-CTR or ChaCha20 can be trivially multithreaded, and it's not very interesting to demonstrate it. 2) Hashing gigantic files is something we actually need to do sometimes, and multithreading can be beneficial in that use case, when we don't have a read bottleneck. In contrast, encrypting a gigantic file is pretty rare, and it tends to involve prohibitive memory requirements and/or an output bottleneck. Most encrypted ciphertexts tend to be pretty small, like TLS records, and it's rare to have a good use case for multithreaded ChaCha20. So if you're benchmarking BLAKE3 (b3sum) against large input files, there's a good chance your benchmark is benefitting from multithreading. But if you try to encrypt the same file, and you manage not to have an output bottleneck, your ChaCha20 implementation almost certainly isn't multithreaded. So that's another thing we need to be careful about when we compare them.