[CFRG] Re: BLAKE3 I-D

[Jean-Philippe Aumasson <[e-mail]>]

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.



On Mon, Aug 26, 2024 at 6:19 PM Phillip Hallam-Baker <[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.
>
> 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.
>
> 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.
>
> 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."
>
>
>
>
>
> On Sat, Aug 24, 2024 at 1:30 PM Eric Rescorla <[e-mail]> wrote:
>
>>
>>
>> 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]
>>>
>> _______________________________________________
>> 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]
>