[CFRG] Re: BLAKE3 I-D

[Eric Rescorla <[e-mail]>]

I don't actually think the question of how much an algorithm is used in the
wild is that relevant to the question of adoption. The more relevant
question is whether there are IETF groups who want to use a given
algorithm, because that is where CFRG should focus its limited resources.

-Ekr


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