[CFRG] Re: Progressing NTRUPrime/Classic McEliece drafts

[Deirdre Connolly <[e-mail]>]

> CFRG has run elliptic curve and PAKE selection processes. I would assume
Quynh means something like that.

Gotcha, ok

> I don't see any additional lattice based KEMs or NIKE worth standardizing
at the moment.

I would generally agree, but for FrodoKEM - if the ISO standard actually
happens, that is a less accessible specification...

On Sun, Feb 2, 2025, 9:02 AM John Mattsson <[e-mail]>
wrote:

> CFRG has run elliptic curve and PAKE selection processes. I would assume
> Quynh means something like that.
>
> I don't see any additional lattice based KEMs or NIKE worth standardizing
> at the moment. The next couple of years I think IEFT/IRTF should focus on
> integrating ML-KEM, Classic McEliece, and BIKE/HQC, ML-DSA, FN-DSA
>
> Sent from Outlook for iOS <https://aka.ms/o0ukef>
> ------------------------------
> *From:* Deirdre Connolly <[e-mail]>
> *Sent:* Sunday, February 2, 2025 9:17 AM
> *To:* Quynh Dang <[e-mail]>
> *Cc:* IRTF CFRG <[e-mail]>
> *Subject:* [CFRG] Re: Progressing NTRUPrime/Classic McEliece drafts
>
> > I think the CFRG needs to run a competition process
>
> Has CFRG ever done anything like this?
>
> On Wed, Jan 29, 2025, 12:52 PM Quynh Dang <[e-mail]> wrote:
>
>> 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]
>>
>