[CFRG] Re: BLAKE3 I-D

[Benson Muite <[e-mail]>]

On 22/08/2024 05.20, Eric Rescorla wrote:
> 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.
> 

RFC 7693 [1] documents Blake 2.  Blake 3 is an improved version of this,
so is worth reviewing. Blake 2 was done through the independent
submission stream [2], rather than through a research or working group.

1) https://datatracker.ietf.org/doc/html/rfc7693
2) https://www.rfc-editor.org/about/independent/

> -Ekr
> 
> 
> On Wed, Aug 21, 2024 at 9:51 AM Chris Barber <[e-mail]
> <mailto:[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]
>     <mailto:[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 <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] <mailto:[e-mail]>
>         To unsubscribe send an email to [e-mail]
>         <mailto:[e-mail]>
> 
>     _______________________________________________
>     CFRG mailing list -- [e-mail] <mailto:[e-mail]>
>     To unsubscribe send an email to [e-mail]
>     <mailto:[e-mail]>
> 
> 
> _______________________________________________
> CFRG mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]