[CFRG] Re: BLAKE3 I-D

[Jean-Philippe Aumasson <[e-mail]>]

Looks like Jack's email didnt make it through the ietf.org email filters:

On Wed, Aug 14, 2024 at 12:56 PM Jack O'Connor <[e-mail]> wrote:

> Hi Chris, here's my (biased of course) summary of some of the features and
> advantages of BLAKE3:
>
> If you haven't yet compared the performance of B3 and K12, I suggest the
> following quick-and-dirty benchmark. Here's a run on my laptop:
>
> # Install Rust and Cargo, see https://rustup.rs/
> $ cargo install b3sum k12sum hyperfine
> ...
> $ head -c 1000000000 /dev/random > /tmp/f
> $ hyperfine "sha512sum /tmp/f" "k12sum /tmp/f" "b3sum /tmp/f"
> ...
> Summary
>   b3sum /tmp/f ran
>     3.95 ± 0.10 times faster than k12sum /tmp/f
>    23.81 ± 0.57 times faster than sha512sum /tmp/f
>
> The main difference between B3 and K12 in this case is that, while both
> make extensive use of SIMD parallelism, only b3sum is multithreaded.
> k12sum could use multithreading in theory, but in practice I'm not aware
> of any multithreaded implementations of K12. The difference in tree
> structures is important: B3 is a binary tree with the usual recursive
> structure, which lets us use "divide-and-conquer" / "fork-join" parallelism
> of the sort provided by OpenMP in C/C++ or Rayon in Rust. K12 has a
> shallow/one-parent structure, which would need some sort of job queue with
> more synchronization and tuning, and the root note itself can be a
> bottleneck. (TurboSHAKE has a serial structure and can't take much
> advantage of SIMD or threads, which is a major performance disadvantage on
> modern machines.)
>
> B3 also performs better in software on 32-bit embedded systems, because it
> uses 32-bit words internally. (K12 and TurboSHAKE use 64-bit words.) This
> is important for protocol designs that want to support embedded systems,
> don't want to assume hardware acceleration, and don't want to negotiate
> algorithms at runtime. In particular, I think this is why WireGuard uses
> BLAKE2s instead of BLAKE2b or SHA-2, and BLAKE3 is derived most directly
> from BLAKE2s.
>
> The B3 XOF is counter-based, similar to ChaCha or AES-CTR, which makes it
> parallelizable and suitable as a stream cipher or a high-performance
> CSPRNG. K12 and TurboSHAKE use a sponge-style XOF that isn't parallelizable.
>
> B3 supports "streaming verification", where the recipient of a large file
> verifies chunks as they arrive instead of buffering the whole file and
> verifying everything at the end. See https://github.com/oconnor663/bao
> (my work) and https://www.iroh.computer/docs/layers/blobs (others' work).
> K12 can't do this efficiently, because of the difference in tree
> structures. (TurboSHAKE isn't a tree and can't do this at all.)
>
> Compared to BLAKE2, which comes in "b", "s", "bp", and "sp" variants (plus
> "X"), BLAKE3 is just BLAKE3. There are no variants, no tricky choices for
> callers to make.
>
> The standard BLAKE3 API is three functions: hash
> <https://docs.rs/blake3/latest/blake3/fn.hash.html>, keyed_hash
> <https://docs.rs/blake3/latest/blake3/fn.keyed_hash.html>, and derive_key
> <https://docs.rs/blake3/latest/blake3/fn.derive_key.html>. The keyed_hash
> function is similar to HMAC, but it's much faster for short inputs,
> requiring only one compression instead of four. The derive_key function
> is similar to HKDF, but also much faster for short inputs, less confusing,
> and designed to help existing applications introduce key derivation in a
> backwards compatible way. (See Section 6.2 of the BLAKE3 spec
> <https://github.com/BLAKE3-team/BLAKE3-specs/blob/master/blake3.pdf>.)
>
> Projects currently using BLAKE3 in production include LLVM, Bazel,
> OpenZFS, IPFS, and apparently Tekken 8
> <https://twitter.com/rodarmor/status/1751567502050771189>. We keep an
> incomplete list on GitHub
> <https://github.com/BLAKE3-team/BLAKE3/?tab=readme-ov-file#adoption--deployment>
> .
>
> - Jack
>
> On Wed, Aug 14, 2024 at 9:56 AM Christopher Patton <[e-mail]>
> wrote:
>
>> Hi JP,  it may be reasonable to have an update to the existing BLAKE2
>> RFC. How does BLAKE3 compare to TurboSHAKE/KangarooTwelve? Its RFC is
>> nearly finished (
>> https://datatracker.ietf.org/doc/draft-irtf-cfrg-kangarootwelve/) and we
>> already have applications for it. Are there use cases for which you think
>> BLAKE3 is better suited?
>>
>> Chris P.
>>
>> On Fri, Jul 26, 2024 at 6:46 AM Jean-Philippe Aumasson <
>> [e-mail]> wrote:
>>
>>> Dear CFRG members,
>>>
>>> We created an I-D for BLAKE3, a popular hash function that can be also
>>> used as PRF, MAC, KDF, XOF::
>>>
>>> https://datatracker.ietf.org/doc/draft-aumasson-blake3/
>>>
>>> We would like to eventually turn it into an RFC, to formally standardize
>>> BLAKE3 and make it eligible for integration in systems and organizations
>>> that require this (like OpenSSL).
>>>
>>> See also https://github.com/BLAKE3-team/BLAKE3/blob/master/README.md.
>>>
>>> BLAKE3 is often used via the b3sum utility, for example from
>>> https://crates.io/crates/b3sum
>>> https://formulae.brew.sh/formula/b3sum
>>>
>>> In the I-D we tried to describe BLAKE3's tree mode in the simplest way
>>> possible, yet in a way sufficient to implement. The I-D does not include
>>> source code, however, but instead refers to our C or Rust reference code at
>>> https://github.com/BLAKE3-team/BLAKE3.
>>>
>>> We would appreciate any informal feedback at this stage, and then we
>>> would like to proceed with the formal review process as soon as possible.
>>> We will follow the recommendations and instructions of the CFRG chairs, as
>>> we are not familiar with the process.
>>>
>>> Thank you for your attention to this new I-D submission.
>>>
>>> JP, on behalf of the BLAKE3 team (Jack, Samuel, Zooko)
>>>
>>>
>>> _______________________________________________
>>> CFRG mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>>