[CFRG] Re: BLAKE3 I-D

[Jack O'Connor <[e-mail]>]

> What properties does BLAKE3 have that TurboSHAKE doesn't? "it's already
used a lot in the wild" can be sufficient to justify a specification.

I wrote a bit about the properties of BLAKE3 earlier in this thread, but I
screwed up my list membership, and my email didn't make it through to
everyone. JP copied it in a reply here:
https://mailarchive.ietf.org/arch/msg/cfrg/zmoJ6Z4NO8R4ts9JmkXv_hQWrjY.
Regarding adoption in the wild, BLAKE3 is currently used by 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 21, 2024 at 9:51 AM Chris Barber <[e-mail]> wrote:

> Dear Chris,
>
> You are comparing specific implementations on a particular CPU, not the
> algorithms themselves. The "sha3" library you are using is not optimized
> and may not accurately reflect the performance of TurboSHAKE compared to,
> for example, XKCP. In software, the performance of BLAKE3 and
> TurboSHAKE/KT12 is theoretically very close but highly dependent on the
> implementation in practice.
>
> Since this discussion is about adoption, I believe it would be more
> relevant to compare the algorithms themselves. What properties does BLAKE3
> have that TurboSHAKE doesn't? "it's already used a lot in the wild" can be
> sufficient to justify a specification.
>
> On Thu, Aug 15, 2024 at 11:07 PM Christopher Patton <cpatton=
> [e-mail]> wrote:
>
>> Hi all,
>>
>> Before adopting BLAKE3, I think it would be useful to see how much of a
>> difference it would make in our applications. I would suggest looking
>> through RFCs published by CFRG and assess how performance would change if
>> they could have used BLAKE3. Off the top of my head:
>> - RFC 9180 - HPKE (replace HKDF?)
>> - draft-irtf-cfrg-opaque - OPAQUE
>> - RFC 9380 - hashing to elliptic curves
>>
>> I'll add my own data point: draft-irtf-cfrg-vdaf. This draft specifies an
>> incremental distributed point function (IDPF), a type of function secret
>> sharing used in some MPC protocols. Most of the computation is spent on XOF
>> evaluation. For performance reasons, we try to use AES wherever we can in
>> order to get hardware support. We end up with a mix of TurboSHAKE128 and
>> AES, which is not ideal. It would be much nicer if we could afford to use a
>> dedicated XOF, but TurboSHAKE128 is not fast enough in software. I threw
>> together some benchmarks for B3:
>>
>> https://github.com/cjpatton/libprio-rs/compare/main...cjpatton:libprio-rs:exp/blake3-for-idpf?expand=1
>>
>> The results were interesting. Compared to Turbo, B3 is 30% faster, as
>> expected. Compared to the baseline (mix of Turbo and AES), B3 is 2-3x
>> slower for the client operation, as expected; but the server was slightly
>> faster, which frankly is a bit of a mystery. We'll need to dig into the
>> code more to be certain, as there may be some obvious inefficiencies on the
>> client side. But preliminarily, I would say B3 is probably too slow in
>> software for this application.
>>
>> Chris P.
>>
>>
>>
>>
>> _______________________________________________
>> CFRG mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
> _______________________________________________
> CFRG mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>