[CFRG] Re: BLAKE3 I-D

[Benson Muite <[e-mail]>]

On 24/08/2024 20.29, Eric Rescorla wrote:
> 
> 
> On Fri, Aug 23, 2024 at 11:56 PM Benson Muite
> <[e-mail] <mailto:[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
>     <https://datatracker.ietf.org/doc/html/rfc7693>
>     2) https://www.rfc-editor.org/about/independent/
>     <https://www.rfc-editor.org/about/independent/>
> 
> 
> I don't think this follows at all. There are lots of things in the
> Independent Stream

Just indicating that the independent stream is another option.  Possible
users of BLAKE3 might however be willing to review it through other options.

> I wouldn't want to see CFRG spend effort on, for instance the GOST
> algorithms.

Many of the references to BLAKE2 have come from CFRG. Nevertheless,
neither BLAKE2 nor BLAKE3 are designed as cryptographically secure hash
functions, so it might not be a good fit for CFRG. Nevertheless, BLAKE2
is used in Argon which has an RFC9106 produced by CFRG, so may be of
interest to CFRG.  BLAKE2 is also used in Babel, so BLAKE3 might also be
of interest to the Babel working group.

https://datatracker.ietf.org/doc/rfc9106/
https://datatracker.ietf.org/wg/babel/about/

> 
> -Ekr
> 
> 
> 
>     > -Ekr
>     >
>     >
>     > On Wed, Aug 21, 2024 at 9:51 AM Chris Barber
>     <[e-mail] <mailto:[e-mail]>
>     > <mailto:[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]>
>     >     <mailto:[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> <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.
>     >
>     >