[CFRG] Re: BLAKE3 I-D

[Phillip Hallam-Baker <[e-mail]>]

+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]
>