[CFRG] Re: Progressing NTRUPrime/Classic McEliece drafts

[Eric Rescorla <[e-mail]>]

On Thu, Jan 30, 2025 at 5:37 AM Sofia Celi <[e-mail]> wrote:

> Hi, all,
>
> Also speaking as a personal opinion.
>
> I agree with Britta. If we were to standardize different algorithms,
> this decision should be based, among other factors, on their security
> analysis and the extent to which they have been scrutinized over the
> years. This is why I feel less comfortable standardizing algorithms that
> have only recently been introduced and have not undergone a process that
> explicitly encourages rigorous scrutiny.
>

I think this is a key point. The net effect of CFRG documenting an algorithm
is to tell the community that it's OK to use. CFRG obviously has the ability
to do some technical analysis, but inevitably a lot of the assessment will
be based on reviewing the work that has already been done.

-Ekr


> In this regard, I believe McEliece makes sense (assuming it is not
> standardized by NIST, to avoid redundant efforts), as it has been
> extensively analyzed and has withstood cryptanalysis for a very long
> time. Of course, this does not mean that an attack will never be found,
> but rather that its security has been thoroughly attested.
>
> Thank you,
>
> On 30/01/2025 05:14, Hale, Britta (CIV) wrote:
> > All,
> >
> > Speaking as a personal opinion:
> >
> > Like Quynh though, I think it would be wise to have some type of process
> > in the IETF moving ahead with algorithm standards – this is not because
> > there is a problem with having ‘extra’ standardized solutions that are
> > applicable to niche cases, but rather that spreading focus across many
> > algorithms diffuses efforts in analysis and focus, which in turn can
> > lead to subtle gaps. There can be several standards, but we should be
> > careful about how much oversight each is getting before moving any one
> > algorithm forward. At the very least, I recommend a limitation on
> > parallelized efforts, so that sufficient focus can be dedicated at a
> > given time.
> >
> > Analysis should also be a heavy factor in consideration of algorithms.
> > In some cases, such as NTRU, the NIST process stimulated multiple
> > analyses from the cryptographic community that provide insights on its
> > security. Not all algorithms being put forward have had such scrutiny,
> > and all IETF efforts are not guaranteed to have a similar analysis
> > attraction and priority for the cryptographic community as the NIST
> > process had. It would be quite risky to start standardizing algorithms
> > based on e.g., only one or two peer-reviewed papers, as it suggests
> > fewer expert eyes on a problem. Consequently, I recommend that
> > consideration for IETF standardization be based not simply on potential
> > functionality usefulness and likelihood of adoption by the IETF, but
> > also how much analysis it has undergone.
> >
> > Britta
> >
> > *From: *Quynh Dang <[e-mail]>
> > *Date: *Wednesday, January 29, 2025 at 4:51 AM
> > *To: *IRTF CFRG <[e-mail]>
> > *Subject: *[CFRG] Re: Progressing NTRUPrime/Classic McEliece drafts
> >
> > NPS WARNING: *external sender* verify before acting.
> >
> > Hi all,
> >
> > Below is my personal view which does not imply any view from NIST or
> > anybody else.
> >
> > I think the CFRG needs to run a competition process to select a lattice-
> > based KEM to provide a good option for the users who don’t want to use
> > ML-KEM or NIST’s standardized cryptographic methods generally.
> >
> > At least there are 2 candidates we all know right now which are NTRU
> > ( see here https://www.ntru.org/ <https://www.ntru.org/>) and
> > Streamlined NTRU Prime (see here https://ntruprime.cr.yp.to/ <https://
> > ntruprime.cr.yp.to/>) . There are important differences between them;
> > they are not “about” the same. Something is true with NTRU does not mean
> > it is automatically true with Streamlined NTRU Prime (security,
> > performance or IPR etc.).
> >
> > Here are the reports of the second and third rounds of NIST's KEM
> > selection process which had both candidates: https://nvlpubs.nist.gov/
> > nistpubs/ir/2020/NIST.IR.8309.pdf <https://nvlpubs.nist.gov/nistpubs/
> > ir/2020/NIST.IR.8309.pdf>  and https://nvlpubs.nist.gov/nistpubs/
> > ir/2022/NIST.IR.8413-upd1.pdf <https://nvlpubs.nist.gov/nistpubs/
> > ir/2022/NIST.IR.8413-upd1.pdf> .
> >
> > It would be very useful to have performance data of  (many) different
> > implementations of the options of NTRU and Streamlined NTRU Prime on
> > (many) different platforms including constrained ones beside the data we
> > received during the first 3 rounds.
> >
> > Regards,
> >
> > Quynh.
> >
> > PS: I don’t plan to spend my time replying to potential messages asking
> > me all sorts of things. My apologies in advance if I don't reply to your
> > messages.
> >
> > On Wed, Jan 29, 2025 at 6:48 AM John Mattsson
> > <john.mattsson=[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     I agree that CFRG should prioritize things that are likely to be
> >     adopted by IETF, but I think it is important that CFRG is not
> >     limited to things that have a current customer in the IETF. This
> >     would be too limiting for an RG. CFRG must be able to work on things
> >     that are likely to be useful by the IETF long-term.
> >
> >     John
> >
> >     *From: *Kris Kwiatkowski <[e-mail]
> >     <mailto:[e-mail]>>
> >     *Date: *Wednesday, 29 January 2025 at 12:30
> >     *To: *[e-mail] <mailto:[e-mail]> <[e-mail]
> >     <mailto:[e-mail]>>
> >     *Subject: *[CFRG] Re: Progressing NTRUPrime/Classic McEliece drafts
> >
> >         i haven't seen anyone suggest that CFRG should not publish its
> own
> >
> >         specifications regardless of what NIST does. That's certainly not
> >
> >         my position. That would be an odd position to take as CFRG has
> >
> >         already done this a number of times.
> >
> >     For primitives like LMS, XMSS, and HKDF, it was IETF that originally
> >     developed the specifications, with NIST later incorporating them
> >     into its standards.
> >
> >     +1 for CFRG focuses on defining primitives that are likely to be
> >     adopted by IETF, ensuring they are well-vetted before becoming part
> >     of widely used protocols.
> >
> >     _______________________________________________
> >     CFRG mailing list -- [e-mail] <mailto:[e-mail]>
> >     To unsubscribe send an email to [e-mail] <mailto:cfrg-
> >     [e-mail]>
> >
> >
> > _______________________________________________
> > CFRG mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
> --
> Sofía Celi
> @claucece
> Cryptographic research and implementation at many places.
> Reach me out at: [e-mail]
> Website: https://sofiaceli.com/
>
> _______________________________________________
> CFRG mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>