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

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

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.

Why?

And if we’re talking about an IETF competition for a Lattice-based alternative to NIST standards - then what can be a better candidate for replacement than ML-DSA, with its huge public key and signature sizes?

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]