[CFRG] Re: [EXT] Re: Progressing NTRUPrime/Classic McEliece drafts

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

There could be use cases for McEliece, especially when you can afford to pre-provision the static public key. Thus, defining how it can be used, would be good. 

I do not think there are any benefits in standardizing NTRU at this day and age, in any shape or form. 
—
Regards,
Uri

Secure Resilient Systems and Technologies
MIT Lincoln Laboratory

> On Jan 29, 2025, at 03:49, John Mattsson <john.mattsson=[e-mail]> wrote:
> 
> 
> This Message Is From an External Sender
> This message came from outside the Laboratory.
> 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]