[CFRG] Re: BLAKE3 I-D

[Eric Rescorla <[e-mail]>]

On Fri, Aug 23, 2024 at 11:56 PM Benson Muite <[e-mail]>
wrote:

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


I don't think this follows at all. There are lots of things in the
Independent Stream
I wouldn't want to see CFRG spend effort on, for instance the GOST
algorithms.

-Ekr


>
> > -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]
>
> _______________________________________________
> CFRG mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>