BLAKE3-specs VS XKCP

We put a lot of effort into section 5.1.2 of https://github.com/BLAKE3-team/BLAKE3-specs/blob/master/blak..., and the relatively more complicated part of BLAKE3 (incrementally building the Merkle tree) ends up being ~4 lines of code. Let me know what you think.

BLAKE3 is a new function which includes a KDF mode, and is significantly faster than HKDF-SHA256. However, it hasn't seen as much cryptanalysis as more established functions, so I'm still somewhat wary of it (admittedly it's a reduced-round variant of BLAKE2s, with extra modes, so I'm not that wary, but it's still worth a warning).

The BLAKE3 spec is also pretty readable (though I think the graphics in the BLAKE2b paper make it a bit easier to understand).

> That's for 16KiB inputs.

BLAKE3 needs 16 KiB of input to hit the numbers in that bar chart, but BLAKE2s doesn't. It'll maintain its advantage over SHA-256 all the way down to the empty string. You can see this in Figure 3 of https://github.com/BLAKE3-team/BLAKE3-specs/blob/master/blak.... (BLAKE3 is also faster than SHA-256 all the way down to the empty string, but not by as large a margin as the 16 KiB figures suggest.)

On the other hand, these measurements were done on machines without SHA-256 hardware acceleration. If you have that (and Intel chips from the past year do), then SHA-256 does a lot better of course.

Its section 2.1 of the paper: 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.

Consensus is done with Blockmania, a PBFT consensus protocol. Link P2P networking stack (in progress) = libp2p. Link (currently we're using Serf for cluster membership, but this will be replaced by libp2p) We use Blake 3 for merkle tree and hashing algorithm. Link (amongst others that are standard, e.g. multisig) Lthash is used for block propagation and homomorphic hashing, and to extend for bootstrapping. Link For transaction and balance privacy we use:

> Just another nail in the long overdue C/C++ coffin

C, f**ing C. By the sake of god. Not C++.

https://github.com/XKCP/XKCP/commit/fdc6fef075f4e81d6b1bc383...

Something like that in modern C++ would have been done using span<> and that prevents this kind of out-of-bound access party-time.

This and the commit diff itself tell the tale: https://github.com/XKCP/XKCP/issues/105

With parameters as specified by SHA3 it's a lot slower than BLAKE3

Keccak (SHA-3) is actually a good deal faster than BLAKE(1) in hardware. That’s the reason why they chose it: It has acceptable performance in software, and very good performance in hardware.

KangarooTwelve / MarsupilamiFourteen are Keccak variants with fewer rounds; they should smoke BLAKE2 and probably even BLAKE3 in dedicated hardware. Also, they have tree hashing modes of operation like the later BLAKE developers.

The BLAKE family is best in situations where you want the best possible software performance; indeed, there are cases where you do not want hardware to outperform software (e.g. key derivation functions) where some Salsa20/ChaCha20/BLAKE variant makes the most sense. The Keccak family is when one already has dedicated hardware instructions (e.g. ARM already has a hardware level Keccak engine; Intel is dragging their feet but it is only a matter of time) or is willing to trade software performance for more hardware performance.

Keccak code is here: https://github.com/XKCP/XKCP