3 ms·

In my understanding, Blake3 is fast mostly because it does fewer rounds than blake2. The logic is that there is no need to be conservative in the number of roun

In my understanding, Blake3 is fast mostly because it does fewer rounds than blake2. The logic is that there is no need to be conservative in the number of rounds because the current public attacks work only on few rounds so we can just do a bit more rounds and be good. I personally avoid Blake3 and stick with blake2.

thatonelutenist 5y ago
It's a bit more complicated than that. Yes, the core of blake3 is a modified blake2b with fewer rounds, and yes the person who wrote the "Too much Crypto" paper is one of the blake authors, but there are other aspects of the construction that contribute as well. Blake3 operates in a merkle tree mode using the modified blake2 as a node hashing function, which, in and of itself complicates attacks for reasons explained in the blake3 paper. Blake2 also didn't really have that many rounds to start with, Blake3 only reduces the round count from 10 to 7. A good _most_ of the speedup in Blake3 is due to the change in construction, the merkle tree mode allowing for unbounded parallelism, and not having the SIMD-friendly version be a variant. The parallel variants of Blake2 are already _almost_ as fast as Blake3 even without the round reduction (hell, BLAKE2sp can actually be faster than Blake3 in the right conditions).
- CiPHPerCoder 5y ago
  Worth noting that the 10 and 7 are double ChaCha rounds, which means that the strength of BLAKE3's bit diffusion is closer to ChaCha14 than ChaCha7. Given that the best attack against ChaCha fails to break ChaCha8, it's reasonable to conclude that BLAKE3 is secure.
- masklinn 5y ago
  Merkle tree of what, file blocks?
  - thatonelutenist 5y ago
    Its section 2.1 of the paper: https://github.com/BLAKE3-team/BLAKE3-specs/blob/master/blake3.pdf https://github.com/BLAKE3-team/BLAKE3-specs/blob/master/blak... Though, note, blake3 still provides enhanced resistance against the attacks against blake2 even in the case where you only have one block, due to the change in how the fundamental hashing primitive is used.
oconnor663 5y ago
Reducing the rounds from 10 to 7 results in a ~10/7 = ~1.4x speedup. But single-threaded BLAKE3 is 5-6x faster than BLAKE2b, and most of that comes from SIMD optimizations. Thatonelutenist (the author of the original post) points out in a sibling comment that BLAKE2sp closes a lot of that gap, and that's very true. BLAKE2sp and BLAKE2bp can take advantage of many of the same SIMD optimizations that BLAKE3 can. But not all :) A fully optimized implementation of BLAKE2bp/sp is about 2x faster than BLAKE2b and more than 3x faster than BLAKE2s. That's an enormous speedup. Consider that SHA-3 has a reputation for being slow, but the software speed difference between SHA-512 and SHA3-256 is smaller than this. There are some complications when you get into short input performance, but any application that needs to hash files (where short input performance is dominated by the cost of opening the file) would almost certainly be better served by BLAKE2bp/sp than by BLAKE2b/s. In that sense, I think the biggest practical advantage of BLAKE3 is just that it doesn't ask users to navigate these tradeoffs. We discussed this a bit in the intro section of the BLAKE3 paper.

thatonelutenist 5y ago

It's a bit more complicated than that. Yes, the core of blake3 is a modified blake2b with fewer rounds, and yes the person who wrote the "Too much Crypto" paper is one of the blake authors, but there are other aspects of the construction that contribute as well. Blake3 operates in a merkle tree mode using the modified blake2 as a node hashing function, which, in and of itself complicates attacks for reasons explained in the blake3 paper. Blake2 also didn't really have that many rounds to start with, Blake3 only reduces the round count from 10 to 7. A good _most_ of the speedup in Blake3 is due to the change in construction, the merkle tree mode allowing for unbounded parallelism, and not having the SIMD-friendly version be a variant. The parallel variants of Blake2 are already _almost_ as fast as Blake3 even without the round reduction (hell, BLAKE2sp can actually be faster than Blake3 in the right conditions).

CiPHPerCoder 5y ago
Worth noting that the 10 and 7 are double ChaCha rounds, which means that the strength of BLAKE3's bit diffusion is closer to ChaCha14 than ChaCha7. Given that the best attack against ChaCha fails to break ChaCha8, it's reasonable to conclude that BLAKE3 is secure.
masklinn 5y ago
Merkle tree of what, file blocks?
- thatonelutenist 5y ago
  Its section 2.1 of the paper: https://github.com/BLAKE3-team/BLAKE3-specs/blob/master/blake3.pdf https://github.com/BLAKE3-team/BLAKE3-specs/blob/master/blak... Though, note, blake3 still provides enhanced resistance against the attacks against blake2 even in the case where you only have one block, due to the change in how the fundamental hashing primitive is used.

oconnor663 5y ago

Reducing the rounds from 10 to 7 results in a ~10/7 = ~1.4x speedup. But single-threaded BLAKE3 is 5-6x faster than BLAKE2b, and most of that comes from SIMD optimizations. Thatonelutenist (the author of the original post) points out in a sibling comment that BLAKE2sp closes a lot of that gap, and that's very true. BLAKE2sp and BLAKE2bp can take advantage of many of the same SIMD optimizations that BLAKE3 can. But not all :) A fully optimized implementation of BLAKE2bp/sp is about 2x faster than BLAKE2b and more than 3x faster than BLAKE2s. That's an enormous speedup. Consider that SHA-3 has a reputation for being slow, but the software speed difference between SHA-512 and SHA3-256 is smaller than this. There are some complications when you get into short input performance, but any application that needs to hash files (where short input performance is dominated by the cost of opening the file) would almost certainly be better served by BLAKE2bp/sp than by BLAKE2b/s. In that sense, I think the biggest practical advantage of BLAKE3 is just that it doesn't ask users to navigate these tradeoffs. We discussed this a bit in the intro section of the BLAKE3 paper.