[CFRG] Re: BLAKE3 I-D

[Chris Barber <[e-mail]>]

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]
>