[CFRG] Re: Progressing NTRUPrime/Classic McEliece drafts

[Deirdre Connolly <[e-mail]>]

Agreed with Britta

On Thu, Jan 30, 2025, 5:15 AM Hale, Britta (CIV) <[e-mail]>
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/) and Streamlined NTRU Prime (see here
> 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  and
> 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]> 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]>
> *Date: *Wednesday, 29 January 2025 at 12:30
> *To: *[e-mail] <[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]
> To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> CFRG mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>