[CFRG] Re: Progressing NTRUPrime/Classic McEliece drafts

[Watson Ladd <[e-mail]>]

On Sun, Feb 2, 2025 at 12:16 AM Deirdre Connolly
<[e-mail]> wrote:
>
> > I think the CFRG needs to run a competition process
>
> Has CFRG ever done anything like this?

Yes and once it was a complete catastrophe (the curves process), and
extremely slow and messy (the PAKE contest). With PAKE contest I think
the differentiating criteria for the winner was something that can't
easily be integrated into protocols for some reason I don't understand
(someting something UC).

We should avoid doing this in the future IMHO. Getting a bunch of
acceptable entries and selecting between them isn't something the
rough consensus process shines at, and it can be unnecessarily taxing
and contentious because of the inherent stakes.

>
> 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]
>
> _______________________________________________
> CFRG mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]



-- 
Astra mortemque praestare gradatim