[CFRG] Re: BLAKE3 I-D

[Benson Muite <[e-mail]>]

On 28/08/2024 19.21, Jean-Philippe Aumasson wrote:
> Thank you guys for your input, we appreciate your taking the time to
> clarify IETF/CFRG's mission and how B3 would fit (or not). We'll think
> about it and further evaluate the relevance of B3 to IETF.
>  
> I would just like to respond to 2 statements: 
> 
> Benson wrote  "Nevertheless, neither BLAKE2 nor BLAKE3 are designed as
> cryptographically secure hash functions, so it might not be a good fit
> for CFRG."
> 
> and Phillip wrote "I don't see a need for a Blake 3. Applications using
> Blake 2 can simply transition to SHA-2 + SHA-3."
> 
> I don't know if Benson's statement is exactly what they intended to
> convey, but it's obviously not correct: both B2 and B3 are, obviously,
> designed to be cryptographically secure hash functions. B3 is also a
> PRF, MAC, KDF, and XOF. Regarding the need for B3: the SHA-2 family does
> not offer those extra functionalities. The SHA-3 family does but at much
> slower speed. K12/TurboSHAKE are faster than 24-round SHA-3s but are
> significantly less used than B3, be it in open-source and proprietary
> projects.

Ok. Thanks for the clarification.

> 
> 
> 
> On Mon, Aug 26, 2024 at 6:19 PM Phillip Hallam-Baker
> <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     +1 EKR
> 
>     Sort of. I think he understates the case.
> 
>     IETF doesn't select algorithms on its own, it is a part of the wider
>     industry and the primary means by which IETF chooses algorithms is
>     by public competition sponsored by a major stakeholder. To date,
>     that stakeholder has been NIST for historical reasons, UK doesn't
>     put its country on its stamps because Rowland Hill and NIST holds
>     cryptographic algorithm competitions. But if NIST stopped doing
>     that, we would find or build an alternative.

NIST has done well, but some algorithms are not submitted to it.  For
example many algorithms used in the Commonwealth of Independent States
are submitted as IETF informational RFCs after going through a different
review process.

> 
>     We had a public competition for digest algorithms not so long ago.
>     The Blake proposals were not selected. The outcome of the
>     competition was that we came to the conclusion SHA-2 is actually fit
>     for purpose but came up with SHA-3 as an alternative. We thus have
>     two digest algorithms that we have a high degree of confidence in. I
>     don't see a need for a Blake 3. Applications using Blake 2 can
>     simply transition to SHA-2 + SHA-3.

One of the motivations for an IETF document is for inclusion of Blake3
in OpenSSL.

> 
>     CFRG is chartered for "discussing and reviewing uses of
>     cryptographic mechanisms, both for network security in general and
>     for the IETF in particular." I don't see adding a third digest as
>     helping either cause.
> 
>     The security of any application is determined by the weakest
>     algorithm it accepts. There is a good argument for having a backup
>     algorithm but having more than one backup seems more likely to hurt
>     than help. At the very least it means having to spend time and
>     effort tracking an additional random variable.

Concerns about tracking an additional algorithm are reasonable.

> 
>     Even if people are nervous about SHA-2, we can always use SHA-2-512.
>     In a world where we are having to implement PQC algorithms, I can't
>     really see an argument for using SHA-2-256 any more. Just use 512
>     bits and be done, the chance of 512 bits being broken at the same
>     time as 256 is not zero but it means all bets are off. That is not
>     an eventuality it makes sense to plan for because if that falls,
>     nothing we know today can be relied on.
> 
>     CFRG is chartered for "discussing and reviewing uses of
>     cryptographic mechanisms, both for network security in general and
>     for the IETF in particular." 

If CFRG is not appropriate, independent stream could still be useful to
document BLAKE3 as my understanding is that there are situations where
it is more appropriate, but maybe am also incorrect on this.

> 
> 
> 
> 
> 
>     On Sat, Aug 24, 2024 at 1:30 PM Eric Rescorla <[e-mail]
>     <mailto:[e-mail]>> 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
>         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]>
>             > <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.
>             >
>             >
>             >
>             >
>             >         _______________________________________________
>             >         CFRG mailing list -- [e-mail]
>             <mailto:[e-mail]> <mailto:[e-mail]
>             <mailto:[e-mail]>>
>             >         To unsubscribe send an email to
>             [e-mail] <mailto:[e-mail]>
>             >         <mailto:[e-mail]
>             <mailto:[e-mail]>>
>             >
>             >     _______________________________________________
>             >     CFRG mailing list -- [e-mail]
>             <mailto:[e-mail]> <mailto:[e-mail]
>             <mailto:[e-mail]>>
>             >     To unsubscribe send an email to [e-mail]
>             <mailto:[e-mail]>
>             >     <mailto:[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] <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] <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]