Yes, Classic McEliece has properties that makes it the best choice in many different applications. Classic McEliece is the most conservative KEM and Classic McEliece category 5 is the best option for protecting various other keys (ML-KEM, ML-DSA, SLH-DSA, FN-DSA, LMS, XMSS, etc.) in transit and storage. Classic McEliece occupies a role similar to SLH-DSA, providing a very conservative security assurance. The small ciphertexts and good performance makes Classic McEliece the best choice for many applications of static encapsulation keys of which there are many (WireGuard, S/MIME, IMSI encryption, File encryption, Noise, EDHOC, etc.). For many such applications, key generation time is not important, and the public key can be provisioned out-of-band. When the public key is provisioned in-band, Classic McEliece has better performance than ML-KEM after just a few hundred encapsulations. For static encapsulation use cases where ML-KEM provides the best performance, Classic McEliece is the best backup algorithm. The memory requirement can be kept low by streaming the key. We think NIST should standardize mceliece348864 (category 1), mceliece460896 (category 3), and one of mceliece6688128, mceliece6960119, and mceliece8192128 (category 5). 261 kB and 524 kB encapsulation keys can be used where 1 MB keys cannot.
We are planning to use Classic McEliece. It has a a different profile from most other KEMs. It is the most conservative and it has the best performance for static encapsulation keys. We are not currently planning to use FrodoKEM, BIKE, HQC, but would like to a subset of them supported as backup algorithms for ephemeral encapsulation keys. We think NIST should standardize Classic McEliece and If there is a NIST specification, I don’t think a draft is needed. Cheers, John From: Loganaden Velvindron <logana...@gmail.com> Date: Wednesday, 22 January 2025 at 20:53 To: Michael Osborne <o...@zurich.ibm.com> Cc: John Mattsson <john.matts...@ericsson.com>, Wang Guilin <wang.gui...@huawei.com>, ipsec <ipsec@ietf.org>, cfrg <c...@irtf.org>, Wang Guilin <wang.gui...@huawei.com> Subject: Re: [CFRG] Re: [IPsec] Re: [IPsec]: FrodoKEM and its usage in IKemEv2 Thanks. I can also see that Classic Mceliece was also deemed as "acceptable". Projects using it include Rosenpass, MullvadVPN, and my understanding is that Ericsson is also planning to adopt it ? Simon started working on an I-D for Classic MCeliece. On Wed, 22 Jan 2025 at 23:37, Michael Osborne <o...@zurich.ibm.com> wrote: > > Hi John > > You want to check this statement " Many European governments are planning to > use FrodoKEM as the main quantum-resistant algorithm for ephemeral-ephemeral > key exchange" > > The Netherlands have already updated guidance such that ML-KEM is > recommended and FrodoKEM is acceptable. > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublications.tno.nl%2Fpublication%2F34643386%2FfXcPVHsX%2FTNO-2024-pqc-en.pdf&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Ca139af6bf7534738cf8b08dd3b1e5924%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638731724156456851%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=oQZ1O6V3ZCC4DslBkWyElNXyzOcjMG9GrRxGjrUAQtY%3D&reserved=0<https://publications.tno.nl/publication/34643386/fXcPVHsX/TNO-2024-pqc-en.pdf> > I understand BSI Germany and others will do the same shortly > Thanks. I can also see that Classic Mceliece was also deemed as "acceptable". > Kind Regards > > Mike > > -----Original Message----- > From: Loganaden Velvindron <logana...@gmail.com> > Sent: Wednesday, January 22, 2025 7:11 PM > To: John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org> > Cc: Wang Guilin <Wang.Guilin=40huawei....@dmarc.ietf.org>; ipsec > <ipsec@ietf.org>; cfrg <c...@irtf.org>; Wang Guilin <wang.gui...@huawei.com> > Subject: [EXTERNAL] [CFRG] Re: [IPsec] Re: [IPsec]: FrodoKEM and its usage in > IKemEv2 > > On Wed, 22 Jan 2025 at 17:05, John Mattsson > <john.mattsson=40ericsson....@dmarc.ietf.org> wrote: > > > > Hi, > > > > > > > > I think IKEv2 should register code points for FrodoKEM and BIKE/HQC > > (depending on which one NIST standardizes). I think it is important with > > backups to ML-KEM. The importance of cryptographic agility has been > > emphasized by several US agencies. A necessity for cryptographic agility is > > to have a cryptographic primitive to switch to. The practice of > > implementing cryptographic backup algorithms has long been a guiding > > principle in the telecom industry. > > > Indeed. Cryptographic agility is good. I've also seen this from wolfssl: > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.wolfssl.com%2Fcoming-soon-frodokem-in-wolfcrypt%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Ca139af6bf7534738cf8b08dd3b1e5924%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638731724156476735%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=lGv6W13jCY%2FiIZo5mji%2Ft%2BwQ5FgnOGV8lnvFAfO1mPs%3D&reserved=0<https://www.wolfssl.com/coming-soon-frodokem-in-wolfcrypt/> > > > > > > > > > FrodoKEM is unstructuctured but still lattice, BIKE/HQC is code-based but > > still structured. Many European governments are planning to use FrodoKEM as > > the main quantum-resistant algorithm for ephemeral-ephemeral key exchange. > > For an ESP association sending 100 GB of data, the overhead of FrodoKEM and > > BIKE/HQC is small. > > > > > > > > Classic McEliece could also be considered but I think it is mostly > > interesting for static encapsulation keys like in HPKE. > > > > > > > > I think CFRG should specify FrodoKEM, but I am also fine with continue > > using frodokem.org as a normative reference. > > > > > > > > Cheers, > > > > John > > > > > > > > From: Wang Guilin <Wang.Guilin=40huawei....@dmarc.ietf.org> > > Date: Wednesday, 6 November 2024 at 15:22 > > To: plonga <plo...@microsoft.com> > > Cc: ipsec <ipsec@ietf.org>, cfrg <c...@irtf.org>, Wang Guilin > > <wang.gui...@huawei.com> > > Subject: [CFRG] [IPsec]: FrodoKEM and its usage in IKemEv2 > > > > Dear Patrick, > > > > > > > > As disccussed during your talk about FrodoKEM in the CFRG meeting, here is > > the info about our draft. > > > > > > > > Post-quantum Hybrid Key Exchange in the IKEv2 with FrodoKEM > > > > draft-wang-hybrid-kem-ikev2-frodo-02 > > > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Ca139af6bf7534738cf8b08dd3b1e5924%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638731724156488310%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Ampi7A2ZOkpSqGUle9CrQS1PtC9JoxdbdQzCBa31K%2Fo%3D&reserved=0<https://datatracker.ietf/> > > . > > org_doc_draft-2Dwang-2Dhybrid-2Dkem-2Dikev2-2Dfrodo_&d=DwIGaQ&c=BSDicq > > BQBDjDI9RkVyTcHQ&r=pgQajsQGPGHfcehiLJAf-Vgf2_A4DiT5oMtsz3qN40Y&m=Gceg8 > > Al9Grbeyiphao9bC6ROOJXKrlXrbYseb8yxCDjlTmStNkuSL0m1jbJzvkku&s=1aNB7LAu > > h7TKISDNJizzulUoe3nI-GH6jFUXDC3rcQI&e= > > > > > > > > Cheers, > > > > > > > > Guilin > > > > > > > > From:Bruckert, Leonie <leonie.bruck...@secunet.com> > > > > To:Wang Guilin <wang.gui...@huawei.com>;ipsec <ipsec@ietf.org> > > > > Date:2024-11-06 10:41:21 > > > > Subject:AW: [IPsec] Comments regarding > > draft-wang-hybrid-kem-ikev2-frodo-02 > > > > > > > > Hi Guilin, > > > > > > > > Thank you for your offer. I am looking forward to working together on this > > draft. > > > > > > > > Cheers, > > Leonie > > > > > > > > Von: Wang Guilin <wang.gui...@huawei.com> > > Gesendet: Dienstag, 5. November 2024 15:06 > > An: Bruckert, Leonie <leonie.bruck...@secunet.com>; ipsec > > <ipsec@ietf.org> > > Cc: Wang Guilin <wang.gui...@huawei.com> > > Betreff: RE: [IPsec] Comments regarding > > draft-wang-hybrid-kem-ikev2-frodo-02 > > > > > > > > > > Hi, Leonie, > > > > > > > > Thanks a lot for your detailed comments. > > > > > > > > A little later, I will integrate them into a new version. I am happy to > > invite you working together on the draft. > > > > > > > > Cheers, > > > > > > > > Guilin > > > > > > > > ________________________________ > > > > > > Wang Guilin > > Mobile: +65-86920345 > > Mail: wang.gui...@huawei.com > > > > From:Bruckert, Leonie <leonie.bruck...@secunet.com> > > > > To:ipsec <ipsec@ietf.org> > > > > Date:2024-11-05 12:15:37 > > > > Subject:[IPsec] Comments regarding > > draft-wang-hybrid-kem-ikev2-frodo-02 > > > > > > > > I had a closer look at the Frodo draft. Please find my comments below. > > > > > > > > Cheers, > > > > Leonie > > > > > > > > General comments: > > > > - The terminology should be aligned throughout the whole document, e.g. > > Frodo should be replaced by FrodoKEM. > > > > - I would add one or two sentences to the introduction like “This document > > uses the terminology defined in “Terminology for Post-Quantum Traditional > > Hybrid Schemes…” > > > > - I am wondering if it is sufficient to refer to the upcoming ISO standard > > or the public FrodoKEM specification document, respectively. Do we want or > > need a FrodoKEM specification from cfrg? > > > > - In general, I would recommend (but not require) to use FrodoKEM in > > addition to the traditional key exchange, and also mention that it can be > > used together with multiple PQ KEMs. > > > > - I found lots of typos, which I tried to correct in my text proposals, but > > there are probably some more. > > > > > > > > Here are some specific comments mainly regarding abstract and introduction: > > > > > > > > Abstract: > > > > When RFC 9370 was written the main motivation was to do a PQC KEM in > > addition to ECDH, but RFC 9370 does not require the first key exchange to > > be ECDH. In principle, you could do a PQC KEM in the first exchange. So, I > > would rewrite the Abstract (I also corrected a number of typos in the NEW > > text), e.g. > > > > > > > > --OLD-- > > > > RFC 9370 specifies a framework that supports mulitple key encapsulation > > mechanisms (KEMs) in the Internet Key Exchange Protocol Version 2 (IKEv2) > > by allowing up to 7 layers of additiona KEMs employed with the oringal ECDH > > to derive the final shared secret keys for IPsec protocols. The primitive > > goal is to mitigate the security threat against quantum computers by > > hybriding additional post-quantum (PQ) KEMs with the orinigal ECDH key > > exchange. This draft specifies how one QP KEMs, FrodoKEM, is instantiated > > in the IKEv2 as the additional KEMs with the main ECDH to achieve hybrid > > key agreement. > > > > > > > > --NEW-- > > > > “Multiple key exchanges in the Internet Key Exchange Protocol Version 2 > > (IKEv2) [RFC9370] specifies a framework that supports multiple key > > encapsulation mechanisms (KEMs) in the Internet Key Exchange Protocol > > Version 2 (IKEv2) by allowing up to 7 layers of additional KEMs to derive > > the final shared secret keys for IPsec protocols. The primary goal is to > > mitigate the “harvest now and decrypt later” threat posed by > > cryptanalytically-relevant quantum computers. For this purpose, usually one > > or more post-quantum KEMs are performed in addition to the traditional > > (EC)DH key exchange. This draft specifies how the post-quantum KEM FrodoKEM > > is instantiated in IKEv2 as an additional key exchange mechanism. > > > > > > > > The link in the EDNOTE points to the wrong draft (terminology draft). > > > > > > > > Introduction: > > > > Some sentences are quite long and complex, so I tried to simplify a bit > > (again correcting typos). Here are my suggestions: > > > > > > > > --OLD-- > > > > To mitigate the security threats on key exchanges again quantum computers, > > especialy the harvest-now-and-decrypt-later (HNDL) attack, the approach of > > hybrid key encapsulation mechanisms (KEMs) has been proposed to achieve > > secure key exchange if at least one of KEMs is still secure. In particular, > > hybrid KEMs is supposed to be used in the scenarios where one or multiple > > traditional KEMs are used together with one or multiple post-quantum KEMs > > [I-D.D24]. The Internet Key Exchange Protocol Version 2 (IKEv2), which > > sepecifies the key exchange procedures of IPSec, has to be updated for > > quantum resistant security. For this purpose, RFC 9370 [RFC9370] describes > > a framework to hybrid mulitple key encapsulation mechanisms (KEMs), which > > extends the IKEv2 by allowing multiple key exchanges to take place for > > deriving shared secret keys during a Security Association (SA) setup. > > Essentially, this speficiation employs the IKE_INTERMEDIATE exchange, which > > is a new IKE message introduced in [RFC9242] so that multiple key exchanges > > can be run to establish an IKE SA via exchanging additional PQ public keys > > and ciphertexts between a client and a server. RFC 9370 also introduces > > IKE_FOLLOWUP_KE, a new IKEv2 exchange for realizing the same purpose when > > the IKE SA is being rekeyed or is creating additional Child SAs. > > > > > > > > --NEW-- > > > > Cryptographically-relevant quantum computers pose a threat to > > cryptographically protected data. In particular, the so-called > > harvest-now-and-decrypt-later (HNDL) attack is considered an imminent > > threat. To mitigate this threat the concept of hybrid key encapsulation > > mechanisms (KEMs) has been proposed to achieve secure key exchange if at > > least one of the KEMs is still secure. “Multiple key exchanges in the > > Internet Key Exchange Protocol Version 2 (IKEv2) [RFC9370] specifies a > > framework to perform hybrid key encapsulation in IKEv2 by allowing multiple > > key exchanges to take place for deriving shared secret keys during a > > Security Association (SA) setup. Essentially, this specification employs > > the IKE_INTERMEDIATE exchange, which is a new IKEv2 message introduced in > > “Intermediate Exchange in the Internet Key Exchange Protocol Version 2 > > (IKEv2)” [RFC9242], so that multiple key exchanges can be run to establish > > an IKE SA via exchanging additional PQ public keys and ciphertexts between > > a client and a server. RFC 9370 also introduces IKE_FOLLOWUP_KE, a new > > IKEv2 exchange for realizing the same purpose when the IKE SA is being > > rekeyed or additional Child SAs are created. > > > > > > > > > > > > --OLD-- > > > > However, RFC 9370 just specifies the framework of hybrid KEMS but it has > > not been instantiated for concrete multiple KEMS. [I-D.KR24] desribes how > > the framework given by RFC 9370 can be run with the post-quantum (PQ) > > ML-KEM [FIPS203], previously called Kyber, which is the standard published > > by NIST in August of 2024. However, on the one hand, FRC 9350 allows up to > > 7 layers of additiona KEMs employed with the oringal ECDH to derive final > > shared secret keys for the IKEv2. On the other hand, for some applications > > (e.g. financial services) demanding high security level, additional PQ KEMs > > may be desired for completing the hybrid KEMs for the IKEv2. Currently, ISO > > is now standardizing three PQ KEM aglorithms: Kyber, FrodoKEM, and classic > > McElliece. Note that Frodo [Frodo] is unstructured lattice based KEM, whose > > security is more conservative compared to ML-KEM, which is based on > > structured lattice. Therefore, this draft is motivated to describe > > concretely how the frame of hybrid KEMs for the IKEv2 specified in RFC 9370 > > can be run via hybriding the ogirinal ECDH and FrodoKEM, even with ML-KEM > > together, if necessary. > > > > > > > > --NEW-- > > > > However, RFC 9370 just specifies the framework of hybrid KEMS and has to be > > been instantiated for concrete KEMS by separate documents. [I-D.KR24] > > describes how the framework given by RFC 9370 can be run with the ML-KEM > > [FIPS203], previously called Kyber. which has been standardized by NIST in > > August 2024. However, on the one hand, RFC 9350 allows up to 7 layers of > > additional KEMs to derive final shared secret keys for the IKEv2. On the > > other hand, for some applications (e.g. financial services) demanding high > > security level, additional PQ KEMs may be desired for use with RFC 9370. > > Currently, ISO is standardizing three PQ KEM algorithms (EDNOTE: we may > > want to change the wording since the ISO standard will be finished > > eventually): Kyber, FrodoKEM, and Classic McEliece. Note that FrodoKEM > > [Frodo] is unstructured lattice based KEM, whose security is more > > conservative compared to ML-KEM, which is based on structured lattice. > > Therefore, this draft is motivated to describe concretely how the frame of > > hybrid KEMs for the IKEv2 specified in RFC 9370 can be instantiated with > > FrodoKEM. FrodoKEM should be used together with a traditional key exchange > > mechanism such as ECDH and in addition, may be used with further KEMs e.g. > > ML-KEM. > > > > > > > > > > > > Further issues in introduction: > > > > - Second bullet point: Add a reference for the break of SIKE > > > > - typos in last paragraph: performace -> performance, triger -> > > trigger > > > > > > > > > > > > More typos: > > > > - section 3, last paragraph: > > stardandization -> standardization > > performace -> performance > > showen -> shown > > roughtly -> roughly > > triger -> trigger > > > > > > > > > > > > > > > > _______________________________________________ > > IPsec mailing list -- ipsec@ietf.org > > To unsubscribe send an email to ipsec-le...@ietf.org > > _______________________________________________ > CFRG mailing list -- c...@irtf.org > To unsubscribe send an email to cfrg-le...@irtf.org
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
