[CFRG] Re: Progressing NTRUPrime/Classic McEliece drafts

[John Mattsson <[e-mail]>]

Thom Wiggers wrote:
>I would prefer any further (NIST- or CFRG-) standardized KEM to enable some use case in protocol design/implementation that we can’t do (well) with ML-KEM.

I mostly agree with this, but I think an additional thing that is needed is a backup algorithm to ML-KEM. BIKE and HQC do to my knowledge not have any performance, size, and feature benefits compared to ML-KEM (performance and sizes are worse) but they are based on a very different problem than ML-KEM and can therefore be expected to remain secure even if some attack is found on ML-KEM. I hope NIST decides to standardize Classic McEliece and BIKE or HQC.

_IF_ CFRG wants to specify an additional lattice-based algorithm, I agree with Quynh that CFRG should have a competition process. Also, CFRG should not restrict itself to algorithms from the NIST competition. That would also be deferring crypto authority to NIST. There has quite a lot published on Lattice based crypto since 2017, in addition to BATs and HAWK, some examples are
https://eprint.iacr.org/2023/663.pdf
https://eprint.iacr.org/2023/271
https://eprint.iacr.org/2022/1664.pdf
https://eprint.iacr.org/2022/579.pdf

Thanks for the link to BAT, very interesting. ML-KEM is just too big for the most constrained IoT radio systems. The only alternatives are to keep ECC or migrate to symmetric group keys without Perfect Forward Secrecy (PFS) and identity protection… I think that instead of stating that it will not have an additional KEM competition, NIST should announce that,  if practical candidates for standardization emerge, it will initiate the standardization of additional KEMs and NIKEs with small public keys and ciphertexts. But I would be equally happy with a CFRG specification. BATs might not be small enough to make a difference. Optimally I would like a NIKE with CSIDH sizes and ML-KEM performance, but maybe that is not theoretically possible…

Cheers,
John

From: Thom Wiggers <[e-mail]>
Date: Wednesday, 29 January 2025 at 14:08
To: Quynh Dang <[e-mail]>
Cc: IRTF CFRG <[e-mail]>
Subject: [CFRG] Re: Progressing NTRUPrime/Classic McEliece drafts
Hi all,

My personal opinion is that enough people’s expensive lawyers seem sufficiently happy with ML-KEM that I’m willing to defer to them. I would prefer any further (NIST- or CFRG-) standardized KEM to enable some use case in protocol design/implementation that we can’t do (well) with ML-KEM. Classic McEliece could fall in this boat (especially if NIST doesn’t pick up that glove).

So if CFRG is going down this road, let me point at BAT [1] for the list of things to discuss. BAT has ~500 byte public keys/ciphertexts (and ~200 bytes for its IoT profile (80 bits security)). Its expensive keygen makes it not very suitable for ephemeral key exchange, but it could be great in e.g. KEM-based authentication protocols.

Cheers,

Thom Wiggers


[1] https://eprint.iacr.org/2022/031


Op 29 jan 2025, om 13:50 heeft Quynh Dang <[e-mail]> het volgende geschreven:

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]<mailto:[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]<mailto:[e-mail]>>
Date: Wednesday, 29 January 2025 at 12:30
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
_______________________________________________
CFRG mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]