PQC Dialogue with Government Stakeholders - Recording, Transcript, and Slides

[John Mattsson]

Hi,

 

Thanks to everybody that participated in the side-meeting! The meeting was a great success with well over 100 participants from governments, industry, and academia. The goal of the meeting was to promote open dialogue and understanding between technical experts and government officials regarding the transition to PQC. EU, Sweden, Germany, UK, US, and Canada all presented their plans for PQC timelines and algorithm recommendations. My feeling is that people were very happy with the meeting, and I have already received questions if I can help to arrange follow-up meetings.

 

Recording, transcript, and slides from the meeting are now available [1-2]. Shortly after the meeting, UK NCSC published their timelines as promised [3]. The European commission will soon publish their timelines [4]. US timelines can be found here [5-8]. Government timelines and algorithms recommendations from Canada, Germany, France, and China can be found here [9-18].

 

If I missed something important, just send a reply and let the list know.

 

Cheers,

John Preuß Mattsson

Expert Cryptography and Security Protocols, Ericsson

 

My personal summary:

 

• John Preuß Mattsson presented that IETF is essential for PQC migration in many industries including critical infrastructure such as 5G and 6G mobile networks.
• The European Commission will publish PQC timelines in mid-May 2025 and technical recommendations in mid-May 2026. Transition for ”Harvest now, decrypt later” should be done by the end of 2030 and in general, the whole transition by the end of 2035. The recommendations are for public administration and critical infrastructure, not national security. The roadmap will be divided into different sectors. Not legally binding but might become law in the future.
• UK NCSC will publish broad recommendations in March 2025. For government use, critical infrastructure, and the everyday citizen. Approves all NIST algorithms and highlights ML-KEM-768 and ML-DSA-65. PQC only is the end goal but use hybrids if that speeds up migration.
• German BSI recommends hybridization of lattice-based algorithms and that will likely be a requirement for common criteria certification in Europe. The SOGIS group will soon publish an updated ACM document with PQC. BSI still recommends FrodoKEM for more conservative applications.
• US NIST provides recommendations for non-classified systems. Cryptographers and industry globally have participated in the NIST PQC project. FIPS 203, 204, and 205 published. Draft speciation of FN-DSA expected in 2025. NIST has started specification of HQC but it will take some time. NIST will follow deployment of Classic McEliece and see if it gets widespread use. NIST has received very promising algorithms in the ramp-on signature project and recently published a report. NIST recommend everyone to move to PQC by 2035, PQC only or hybrid are both fine.
• Canada Cyber Centre has published PQC guidance for government use and critical infrastructure. Partners with NIST on the cryptographic module validation program. Recommends NIST PQC standards. PQC only or hybrid are both permitted. Concerned that specifications on PQC in IETF protocols are not progressing to RFCs fast enough.
• Very strong agreement that PQC is the priority. BSI says QKD is not mature and even long-term the only possible use case would be defense-in-depth in niche application. UK NCSC and NIST does not endorse QKD. Sweden says that QKD will never be useful.
• Several industries express that the lack of technical PQC recommendations or conflicting recommendations from governments are a problem. Discussion on the huge costs of migrating existing infrastructure.
• Tanja Lange states that it is surprising that recommendations to do hybrids is not included in the first document from the NIS corporation group. Without technical recommendations it is unclear what people should migrate to. Discussion about the use of hybrid cryptography, with some advocating for pure post-quantum migration and others highlighting the benefits of hybrids in certain scenarios. Deidre Connolly strongly encourages people to consider pure PQC. BSI states that they recommend hybrids for everything except for hash-based signatures.
• Discussion about paywalled standards. EU and US courts have decided that access to standards referenced by law is a human right.

 

[1] PQC Dialogue with Government Stakeholders – Recording, summary, and transcript

https://ietf.webex.com/recordingservice/sites/ietf/recording/1e87f518ecb1413b9357e607cf825642/playback

 

[2] PQC Dialogue with Government Stakeholders – Slides

https://emanjon.github.io/Slides/2025%20PQC%20side-meeting.pdf

 

[3] UK NCSC, Timelines for migration to post-quantum cryptography
https://www.ncsc.gov.uk/guidance/pqc-migration-timelines

 

[4] European Commission, NIS Cooperation Group

https://digital-strategy.ec.europa.eu/en/policies/nis-cooperation-group

 

[5] US NSA, “The Commercial National Security Algorithm Suite 2.0 and Quantum Computing FAQ”
https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF

https://en.wikipedia.org/wiki/Commercial_National_Security_Algorithm_Suite#/media/File:CNSA_2p0_timeline.png

 

[6] US NIST, Announcing Approval of Three Federal Information Processing Standards (FIPS) for Post-Quantum Cryptography

https://csrc.nist.gov/news/2024/postquantum-cryptography-fips-approved

 

[7] US NIST, Post-Quantum Cryptography

https://csrc.nist.gov/projects/post-quantum-cryptography

 

[8] US NIST, IR 8547, ”Transition to Post-Quantum Cryptography Standards”
https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf

 

[9] Canada Cyber Centre, Cryptographic algorithms for UNCLASSIFIED, PROTECTED A, and PROTECTED B information
https://www.cyber.gc.ca/en/guidance/cryptographic-algorithms-unclassified-protected-protected-b-information-itsp40111

 

[10] Canada Cyber Centre, National Quantum Strategy roadmap: Quantum communication and post-quantum cryptography
https://ised-isde.canada.ca/site/national-quantum-strategy/en/national-quantum-strategy-roadmap-quantum-communication-and-post-quantum-cryptography

 

[11] German BSI, Cryptographic Mechanisms: Recommendations and Key Lengths

https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.html?nn=916626

 

[12] German BSI, Post-Quantum Policy & Roadmap of the BSI

https://pkic.org/events/2023/pqc-conference-amsterdam-nl/pkic-pqcc_stephan-ehlen_bsi_post-quantum-policy-and-roadmap-of-the-bsi.pdf

 

[13] French ANSSI, “Guide des Mécanismes cryptoraphiques”
https://cyber.gouv.fr/sites/default/files/2021/03/anssi-guide-mecanismes_crypto-2.04.pdf

 

[14] French ANSSI, ANSSI views on the Post-Quantum Cryptography transition

https://cyber.gouv.fr/sites/default/files/document/follow_up_position_paper_on_post_quantum_cryptography.pdf

 

[15] French ANSSI, ANSSI plan for post-quantum transition

https://pkic.org/events/2023/pqc-conference-amsterdam-nl/pkic-pqcc_jerome-plut_anssi_anssi-plan-for-post-quantum-transition.pdf

 

[16] Europe, SOGIS Group, supporting documents

https://www.sogis.eu/uk/supporting_doc_en.html

 

[17] China ICCS, Call for Comments on Submission Requirements for Public-Key Cryptographic Algorithms

https://niccs.org.cn/en/notice/

 

[18] German BSI, French ANSSI, Dutch and Swedish NCSA, ”Position Paper on Quantum Key Distribution”
https://www.forsvarsmakten.se/contentassets/f7199ed1b90f41529b76970bdb5fce1c/position-paper-on-quantum-key-distribution.pdf

 

[Arne Padmos]

Hi John,

Thanks a lot for organising the session and for sharing the recording and summary.

A key point missing from your summary is the relevance of the Cyber Resilience Act (CRA), especially if your goal is getting PQC deployed in practice. The CRA has a much broader remit than NIS2 and the timelines are more stringent than the dates of 2030 and 2035 in the NIS2 guidance mentioned during the session. Also, NIS2 is a regulation and thus has to be transposed into national law, unlike the CRA which is a regulation that is automatically binding.

The CRA identifies several categories of products with digital elements (PwDE). Any individual product placed on the market on of after 11 December 2027 will have to comply with the relevant requirements in Annex I of the CRA. How those provisions are evidenced depends on the category of PwDE. Typically this is: self-attestation based on Annex I for products not otherwise categorised; self-attestation based on one or more harmonised standards (if available) for Class I important products; or third-party analysis of the producer's quality systems (think CSMS) and/or third-party analysis of representative product samples plus technical and process documentation using a notified body – i.e. a security lab – for Class II important products and for critical products, with mandatory use of an EU certification scheme for the latter if a respective delegated act has been adopted (see CRA Article 32). What is/isn't in scope of the different categories is specified in Annexes III and IV, with more detailed descriptions to be published by the European Commission in an implementing act.

I know you're very much against closed standards and the development of standards behind closed doors, but the current situation is that (depending on the vertical or horizontal standards involved) ETSI, CEN, and/or CENELEC are working on the CRA standards, at least some of which are intended to be horizontal standards with the aim of having them cited in the Official Journal of the European Union. Such closed fora are very much not ideal, but it's what we have at the moment.

As Fabiana Da Pieve from the European Commission highlighted, the CRA contains provisions for secure communication. Specifically, Annex I of the CRA includes the statement that if deemed relevant based on a risk assessment, the PwDE must 'protect the confidentiality of stored, transmitted or otherwise processed data, personal or other, such as by encrypting relevant data at rest or in transit by state of the art mechanisms, and by using other technical means'. As described in CRA Article 13(2), this risk assessment goes beyond the design phase and for example also includes maintenance. Depending on the support period, this means that if PQC is not included from the get-go, retrofitting through security updates or even product recall may be necessary. This will again be risk-based and dependent on the state of the art. That's one of the reasons why moving the MLKEM768X25519 codepoint 0x11EC of TLS and their equivalents in SSH, IPsec, and JOSE/COSE to RECOMMENDED=Y in the IANA registries is so critical. Such details shape the interpretation of what is considered state of the art.

The timelines for the horizontal and vertical CRA standards are extremely tight as the review rounds of (final) drafts are very long. Timing-wise, the key drafts are coming together, and the window for input is quickly closing. Of course, NIST's publication of FIPS 203 and the related guidance from e.g. BSI, NCSC-NL, EUCC, etc., highlight that hybrid ECDH plus PQC KEMs can be considered to be state of the art. However, having that made explicit in harmonised standards and additional guidance on risk management really makes a difference. The EU provides funding to join the standardisation work. Note that the 6th call – out of a total of 7 calls – for funding through CYBERSTAND.eu is closing this Friday the 16th May 2025 at 17:00 CEST (see https://cyberstand.eu/6th-specific-service-procedure). It seems that review of the relevant standards for PQC coverage might be a promising funding request.

Of course, rolling MLKEM768X25519 out to 40% of browsers and enabling it by default in OpenSSH 10.0 is great, but there's a long tail of PQC debt being designed and developed today. The CRA harmonised standards and related guidance documents are a key lever to drive adoption. Specifically, the vertical standard on embedded and standalone browsers being developed by ETSI TC CYBER could use a push for hybrid PQC support. Additionally, the risk management guidance from the CRA Expert Group should integrate a section on when PQC support is mandatory, both when it comes to the kinds of data being handled as well as providing specific timelines. Besides being targeted at a different audience, the timelines for the NIS2 PQC recommendations are too far out. Manufacturers need clarity now. For example, a manufacturer working on say an MRI machine handling sensitive medical information needs to know by when they need to add PQC support – and if they don't ship a product with PQC support on 11 December 2027, by when they'll need to ship a security update. Without clarity on these points, it'll be up to the courts to find answers to these questions.

Finally, I'd like to come back to the topic of open versus closed standards. If you are against closed standards, you can always do a public domain dedication of your own work and clearly flag this when making contributions to closed standardisation bodies – clearly not ideal, but that's reality. Also, as highlighted during the session, the question of access to legally mandated standards is currently being played out in the courts. In their standardisation request to ETSI, CEN, and CENELEC, the European Commission highlighted that 'the harmonised standards [...] may be subject to access to documents requests [...] [as] the Court recognised that there is an overriding public interest [...] justifying the disclosure of harmonised standards'. Of course, ETSI, CEN, and CENELEC see this as a threat to their business model.

Those who enjoy spending time on FOIA requests and other legal adventures will probably have a field day targeting the 41 CRA standards once they're cited. But possibly even more interesting are critical underlying documents that form an integral part of the interpretation of legal requirements. For example, if EUCC certification becomes mandatory, I don't see how the confidentiality of a key JHAS document keeping track of state-of-the-art hardware and software attacks remains tenable. Note that I hope that EUCC certification doesn't become mandatory in it's current form, as it's strongly biased against open source solutions like OpenTitan Earl Grey and Darjeeling (not surprising given that CC originated in the defence and smart-card industries where security through obscurity is rife, as well as the intelligence community's crusade against cryptographic proliferation, even in the face of harm to critical infrastructure like TETRA TEA1). Given the near miss with the CRA almost killing off open source in the EU, the explicit requirement in the CRA standardisation request to give the needs of the open source community particular attention, as well as the requirement according to CRA Article 8(1) to carry out a market impact assessment, I'm tentatively hopeful that the EUCC won't be steamrollered over nascent open source hardware security efforts.

Regards,
Arne

PS. None of the above is legal advice, consult a lawyer, etc., etc.

PPS. 'Fun' fact: the provisions of the CRA will fully apply 123 months after the Mirai botnet became world-famous.

PPPS. For those not following the IETF PQC mailing list, Stephan Ehlen shared the recent publication of version 2 of the EUCC Guidelines on Cryptography available here: https://certification.enisa.europa.eu/publications/eucc-guidelines-cryptography_en.

[Peter Campbell]

John,

 

Thanks for the summary of the meeting.  I just wanted to correct the UK NCSC position: we’re not recommending the use of hybrids to speed up migration.

 

Our 2024 whitepaper says that technical system and risk owners should weigh the reasons for and against hybrids when deciding how to migrate.  One of the reasons for considering hybrids is that, when used in a flexible protocol, they could help with a phased migration in large networks.  Another is when protocol constraints mean that it is difficult to remove the traditional algorithm.  However, these still need to be balanced against the increased cost and complexity.  The only recommendation is that, if a hybrid is chosen, it is used as an interim measure that allows a straightforward migration to PQ-only in the future.

 

There are no recommendations about hybrids in our recent migration timelines.

 

Best,

 

Peter

--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/GVXPR07MB96788A01934A6D20C21693768996A%40GVXPR07MB9678.eurprd07.prod.outlook.com.

[bruno]

Hi,

Australia has also published timelines and is not recommending hybrids but, "it is not prohibited" [1].

I think i am slowly changing my mind given the timeline (2030 for gov in AU), the lack of support and visibility with Hybrid in regard to signing. hybrid and KEM might be a given.

This email represent my personal view but i think the topic is very interesting and questionable. May be not as an interim measure [non PQC + PQC] but later [PQC1 + PQC2]?

Will AD support hybrid and which technology (chameleon, composite)? there is no RFC approved so far as far as i know.

We also see problem coming with single signing and size with protocols (TLS vs KEMTLS) so it is lowering the appetite for hybrid.

Regards

[1] https://www.cyber.gov.au/resources-business-and-government/essential-cybersecurity/ism/cybersecurity-guidelines/guidelines-cryptography

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAAny96JXgy1ex%3D6bwapsXEpC9iL3oLw63vek4XDintZhJzV4EA%40mail.gmail.com.

[Oscar Smith]

Why is anyone not recommending hybrids?  We know that the PQC algorithms are dramatically slower than the classical ones, so hybrid overhead will be very small (<10%). We also know that algorithms for breaking lattice cryptography are continuing to improve at a fairly rapid rate, and SIKE went from secure to broken before it was even ratified.

If you are worried about store now, decrypt later threats, is there any PQC algorithm that can confidently be given a < 1 in 10 chance of being breakable on a laptop in the next 10 years?

[gard...@gmail.com]

@Oscar, are you suggesting that we have standardized algorithms which have a >10% chance of being broken on a consumer device like a laptop in the next few years?

I think the main reason for not doing hybrid is timelines.  And I think that's why the Australian Signals Directorate was very prescriptive in only allowing a specific size for ML-DSA and ML-KEM.  Implementation, testing and integration of a wide set of algorithmic choices across many industries when they aren't even yet fully defined for many use cases seems like a recipe for failure even if there is wiggle room on the target date.  

[Markku-Juhani O. Saarinen]

Hi,

Since many vendors need to track U.S. NSS regulations too, perhaps it is worth noting that https://www.cnss.gov/CNSS/issuances/Policies.cfm (site uses DoD Root cert) now has two versions of CNSSP 15, old (from 2016) and a new one (from December 2024 / March 2025).

The new CNSSP 15 only has PQC algorithms (ML-KEM-1024 and ML-DSA-87 being the "general purpose algorithms") and there is no mention of explicit hybrids.

Here's the bit about timelines:

"While products incorporating validated implementations of CNSA 2.0 are to be prefrerred, CNSA 1.0 algorithms are acceptable in all products through 31 December 2025. Beginning 1 January 2027, unless otherwise excepted through public messaging on nsa.gov, protection profile, capabilities package, or waived through the waiver process, CNSA 2.0 algorithms will be required in all new products and services that provide cryptographic protection for users or for updates. Barring such an exception, equipment and services which cannot or will not be updated to CNSA 2.0 algorithms must be phased out and replaced with equipment or services which support CNSA 2.0 algorithms by 31 December 2030. CNSA 2.0 algorithms are to be preferred in protocol negotiations once compatible equipment is deployed. CNSA 2.0 algorithms are mandated for all protocol use by 31 December 2031, unless excepted as noted above or waived through the waiver process."

I'm obviously no expert in NSS matters but from what I know especially about PQC PKI technologies, this seems rather optimistic. Previously U.S. DoD had planned to transition authentication in their main networks (NIPRNet and SIPRNet) from RSA-2048 PKI to RSA-3072/4096 only after 2027. https://dl.dod.cyber.mil/wp-content/uploads/pki-pke/pdf/unclass-memo_dodcryptoalgorithms.pdf

Cheers,
-markku

[Oscar Smith]

I think if we look at the history of the NIST PQC standardization, it would be hard to be confident that it's much lower than that. Of the round 3 finalists and candidates, Rainbow, and SIKE were completely broken, and Kyber required changes  to remain secure. That puts us at 1/7 finallists broken (with another partially broken), and 1/8 alternates broken. (For comparison to the AES challenge 1 of 10 algorithms with more than 1 positive vote from round 2 was found slightly weak but fixable, and all 5 finalists have remained secure, with no practical attacks)

It's completely uncontroversial that  every PQC algorithm has better than brute force attacks, and these attacks have improved significantly over the past decade. These attacks are very complicated, and I don't think anyone can say with a straight face that the current publicly known versions of these attacks are optimal and that they won't continue to improve. By comparison, factoring has had no notable advances since the GNFS in the 90s, and ECDLP has similarly had no notable advances in recent memory.

My 10% chance is necessarily unscientific. Predictions are hard (especially about the future), but if we're comparing the odds of total breakage for PQC vs classical algorithms, it seems impossible to me to claim that PQC algorithms have been as robustly studied and held up to anywhere near as much scrutiny as the algorithms we have deployed ubiquitously for the past 30 years.

> I think the main reason for not doing hybrid is timelines

What is the timeline concern? Encrypting/KEM twice is not exactly a difficult algorithm (especially when one of the algorithms is already ubiquitously deployed

[Brent Kimberley]

At the risk of “holding the stick from the wrong end”, I had the feeling that p-256 was the “bee's knees” 😉

 

 

 

Dr. Buchanan

From: pqc-...@list.nist.gov <pqc-...@list.nist.gov> On Behalf Of Markku-Juhani O. Saarinen
Sent: May 15, 2025 11:00 AM
To: pqc-forum <pqc-...@list.nist.gov>
Cc: bruno <bruno.p...@gmail.com>; Peter Campbell <campbe...@gmail.com>; John Mattsson <john.m...@ericsson.com>
Subject: Re: [pqc-forum] PQC Dialogue with Government Stakeholders - Recording, Transcript, and Slides

 

⚠️CAUTION: This email is from an external source. Verify sender before opening links and attachments.⚠️

 

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/29244a39-c9ca-473d-a3ac-2ebdb4af22can%40list.nist.gov.

THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to any privilege have been waived. If you are not the intended recipient, you are hereby notified that any review, re-transmission, dissemination, distribution, copying, conversion to hard copy, taking of action in reliance on or other use of this communication is strictly prohibited. If you are not the intended recipient and have received this message in error, please notify me by return e-mail and delete or destroy all copies of this message.

[bruno]

Hi, I wrote a private note to articulate options and clarify my ideas. this is not academic and i will not share it.

Below is where i landed. 

Basically today May 2025, I would recommend to accept the risk of using one scheme (ML-DSA) but to monitor the emergence of hybrid.

Hybrid is more secure in the transition and my preference is composite (unforgeability/non separability) but it is not mature as far as i can think.

I already did change my mind once on this topic and i think i can later change again. so the control is to review the temporarily decision later if that make sense.

IMO

[John Mattsson]

Arne Padmos wrote:

>the timelines for the NIS2 PQC recommendations are too far out.

Yes, it's very clear that EU is behind. Likely because of some ill-guided focus on QKD, which is quite irrelevant and at best could be used as defence-in-depth for a very small fraction of public-key use cases in the long-term future. When the NIS2 PQC technical recommendations come out in 2026, most standardization and product decisions will already have been made.

 

The time to start inventory, planning, and prioritization was in 2022 when NSM-10 [1] came out. If you wait until you have a full inventory of your cryptographic assets, you'll never get started. The key is to begin transitioning high-value assets now (or even better yesterday).

 

I like a lot in the UK NCSC timelines [3], but  working on inventory until 2028 and then complete migration off high-priority deployed systems in just a few years (2028-2031), seems optimistic. I would like more governments stating that you should begin migration as much as possible already now. This is what I am hearing from Swedish government and I fully agree. I would also like to see more focus on firmware and software update. I agree with CNSA 2.0 that this is prioritized. HW roots-of-trust can typically not be updated after manufacturing and hardware in infrastructure often lives for decades. If you are not prioritizing firmware and software updates, you either have to live with quantum-vulnerable infrastructure, or take the cost and replace hardware long before otherwise needed.

 

Arne Padmos wrote:

>I know you're very much against closed standards

I think the most important thing is that the final standards are freely available. ETSI standards, except these for national security, is to my knowledge freely available. Hopefully paywalled standards referenced in laws is a thing of the past. I completely agree with the EU and US courts have decided that access to standards referenced by law is a human right. I love that the European Commision has publised several ISO standards that were previously paywalled. The IETF is also doing its part and RFC8446bis (TLS 1.3) will remove all normative references to paywalled standards. I think paywalled standards are extra problematic for cryptography and I consider them a major cybersecurity risk. Not only are paywalled standards more likely to contain vulnerabilities, they also vastly increase the risk of implementations vulnerabilities, and enables distribution of backdoored specifications to specific users (which happened in the past with Swiss Crypto AG [2]).

 

Oscar Smith wrote:

>Why is anyone not recommending hybrids?

Many European agencies are not just recommending but requiring hybridization of lattice-based crypto.

 

gard...@gmail.com wrote:

>I think the main reason for not doing hybrid is timelines.

That makes sense for signatures where things are very unclear. I start to doubt that hybrids will ever be widely used and talking to major ICT companies, I get the feeling noone want to do hybrid signatures. For KEMs I think the opposite is true. ML-KEM hybrids like X25519MLKEM768 have far more implementation and deployments than standalone ML-KEM in TLS and SSH. IKEv2 will only do hybrid KEMs, even in CNSA 2.0 systems. This is also what the TLS WG has concluded in their prioritization.. If you want to migrate asap, hybrid KEMs is the clear answer.

 

[1] National Security Memorandum on Promoting United States Leadership in Quantum Computing While Mitigating Risks to Vulnerable Cryptographic Systems

https://bidenwhitehouse.archives.gov/briefing-room/statements-releases/2022/05/04/national-security-memorandum-on-promoting-united-states-leadership-in-quantum-computing-while-mitigating-risks-to-vulnerable-cryptographic-systems/

 

[2] Crypto AG

https://en.wikipedia.org/wiki/Crypto_AG

[Alex Railean]

Hi everyone,

> Oscar Smith wrote: Why is anyone not recommending hybrids?

That is not the case.

- Quote from "A joint statement from partners from 18 EU member states" [1]: "we currently strongly recommend to **deploy PQC in hybrid solutions** for most use-cases" (emphasis in original).

- A Japanese report [2] targeting financial institutions lists hybrids as a potential solution. Not including a quote here because I only have a machine-translated version, but see the bottom of page 47.

Alex

[1] https://www.bsi.bund.de/EN/Service-Navi/Presse/Pressemitteilungen/Presse2024/241127_Post-Quantum_Cryptography.html

[2] https://www.fsa.go.jp/news/r6/singi/20241126.html

[bruno]

John thanks for this comments. he has to be written to be discussed but because the cost of this controls for KEM is nothing versus the cost of the impact then It is already here.

so nobody will discuss that hopefully,

May be we could negative that rationale for signing?

gard...@gmail.com wrote:

>I think the main reason for not doing hybrid is timelines.

That makes sense for signatures where things are very unclear. I start to doubt that hybrids will ever be widely used and talking to major ICT companies, I get the feeling noone want to do hybrid signatures. For KEMs I think the opposite is true. ML-KEM hybrids like X25519MLKEM768 have far more implementation and deployments than standalone ML-KEM in TLS and SSH. IKEv2 will only do hybrid KEMs, even in CNSA 2.0 systems. This is also what the TLS WG has concluded in their prioritization.. If you want to migrate asap, hybrid KEMs is the clear answer.

 I completely agree from day 0