[CFRG] Re: Progressing NTRUPrime/Classic McEliece drafts

[Deirdre Connolly <[e-mail]>]

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