RFC 9958
Post-Quantum Cryptography for Engineers
Post-Quantum Cryptography for Engineers ๐ฎ๐
okay so this RFC is RFC 9958 ๐ฆ and it's titled Post-Quantum Cryptography for Engineers. It's from June 2026 and it's Informational, so it's not a standards-track spec, it's here to explain stuff ๐ง โจ. The authors are A. Banerjee, T. Reddy.K, and D. Schoinianakis from Nokia, plus T. Hollebeek from DigiCert and M. Ounsworth from Entrust ๐ . It's on the Independent Submission stream... wait no, it's an IETF document (ISSN 2070-1721), so it's an IETF product ๐ซถ. And since the title block doesn't list any Obsoletes or Updates line, it doesn't replace or update any earlier RFC ๐.
Abstract โจ
bestie, here's the big picture ๐ญ. A cryptographically relevant quantum computer (CRQC) would make the traditional public key algorithms we use today obsolete, because the math they're built on would stop being safe ๐. So protocols and infrastructure need to move over to post-quantum algorithms, which are designed to hold up against both traditional and quantum attacks ๐ฅ. This doc explains why engineers need to get what PQC is about, how CRQCs would hit existing systems, and what's hard about the switch ๐ง. The lowkey plot twist is that this isn't like the earlier crypto upgrades, because PQ algorithms have unique properties that may mean real protocol redesign ๐. periodt ๐ .
Status of This Memo
this is not an Internet Standards Track spec, it's published just for information ๐ธ.
It's a product of the IETF, and it reflects the consensus of the IETF community ๐. It went through public review and got approved by the Internet Engineering Steering Group (IESG) ๐. Not every IESG-approved doc is up for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the deets ๐.
You can find out the current status of this doc, any errata, and how to send feedback at https://www.rfc-editor.org/info/rfc9958 ๐.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved ๐.
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date ๐. Please actually read those, because they spell out your rights and restrictions for this doc ๐ซถ. Code Components pulled out of this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Revised BSD License says โญ.
Table of Contents ๐งพ
1. Introduction
2. Terminology
3. Threat of CRQCs on Cryptography
3.1. Symmetric Cryptography
3.2. Asymmetric Cryptography
3.3. Quantum Side-Channel Attacks
4. Traditional Cryptographic Primitives That Could Be Replaced by
PQC
5. NIST PQC Algorithms
5.1. NIST Candidates Selected for Standardization
5.1.1. PQC Key Encapsulation Mechanisms (KEMs)
5.1.2. PQC Signatures
6. ISO Candidates Selected for Standardization
6.1. PQC Key Encapsulation Mechanisms (KEMs)
7. Timeline for Transition
8. PQC Categories
8.1. Lattice-Based Public Key Cryptography
8.2. Hash-Based Public Key Cryptography
8.3. Code-Based Public Key Cryptography
9. KEMs
9.1. Authenticated Key Exchange
9.2. Security Properties of KEMs
9.2.1. IND-CCA2
9.2.2. Binding
9.3. HPKE
10. PQC Signatures
10.1. Security Properties of PQC Signatures
10.1.1. EUF-CMA and SUF-CMA
10.2. Details of FN-DSA, ML-DSA, and SLH-DSA
10.3. Details of XMSS and LMS
10.3.1. LMS Key and Signature Sizes
10.4. Hash-then-Sign
11. NIST Recommendations for Security and Performance Trade-offs
12. Comparing PQC KEMs/Signatures against Traditional KEMs, Key
Exchanges, and Signatures
13. Post-Quantum and Traditional (PQ/T) Hybrid Schemes
13.1. PQ/T Hybrid Confidentiality
13.2. PQ/T Hybrid Authentication
13.3. Hybrid Cryptographic Algorithm Combinations:
Considerations and Approaches
13.3.1. Hybrid Cryptographic Combinations
13.3.2. Composite Keys in Hybrid Schemes
13.3.3. Key Reuse in Hybrid Schemes
13.3.4. Future Directions and Ongoing Research
14. Impact on Constrained Devices and Networks
15. Security Considerations
15.1. Cryptanalysis
15.2. Cryptographic Agility
15.3. Jurisdictional Fragmentation
15.4. Hybrid Key Exchange and Signatures: Bridging the Gap
Between PQ/T Cryptography
15.5. Caution: Ciphertext Commitment in KEM vs. DH
16. IANA Considerations
17. Further Reading and Resources
18. References
18.1. Normative References
18.2. Informative References
Acknowledgements
Authors' AddressesThat's part 1 done ๐ง๐ Next up is the Introduction and the Terminology section, so stay tuned, bestie โจ
1. Introduction โจ
Okay so quantum computing is no longer just a theory nerd topic ๐ฌ It's a full-on active research area with real practical implications, bestie. Huge amounts of research and enormous corporate and government funding are going into building practical quantum computing systems right now ๐ธ At the time this document is published, cryptographically relevant quantum computers (CRQCs) that can break widely used asymmetric algorithms (also known as public key algorithms) are not yet available. But research and development keeps going, with the goal of building more powerful and scalable quantum computers ๐
One common myth is that quantum computers are faster than conventional CPUs and GPUs at everything. Not the case ๐ โโ๏ธ Just like GPUs only beat general-purpose CPUs on certain types of problems, quantum computers have a niche set of problems they absolutely excel at. Unfortunately for cryptographers ๐ญ integer factorization and discrete logarithms, the math problems holding up a lot of classical public key cryptography, happen to fall right inside that niche. As quantum tech advances, future quantum computers could have a significant impact on current cryptographic systems. Predicting when a CRQC will actually show up is a challenging task, and there's ongoing uncertainty about when they'll become practically feasible [CRQCThreat] ๐ฎ
Extensive research has produced several post-quantum cryptographic algorithms that could help cryptography survive the quantum computing era โจ However, moving to a post-quantum infrastructure is not a straightforward task, and there are numerous challenges to overcome. It takes a mix of engineering efforts, proactive assessment and evaluation of available technologies, and a careful approach to product development and deployment ๐ ๏ธ
PQC is sometimes called "quantum-proof", "quantum-safe", or "quantum-resistant" ๐ก๏ธ It's the development of cryptographic algorithms designed to secure communication and data in a world where quantum computers are powerful enough to break traditional systems like RSA (Rivest-Shamir-Adleman) and ECC (Elliptic Curve Cryptography). PQC algorithms are meant to resist attacks from quantum computers, which use quantum-mechanical phenomena to solve mathematical problems that are infeasible for classical computers ๐ง โก
As the CRQC threat gets closer, engineers who design, maintain, and secure cryptographic systems have to prepare for the big changes that CRQCs will bring ๐ค Engineers need to understand how to implement post-quantum algorithms in applications, how to weigh the trade-offs between security and performance, and how to keep backward compatibility with current systems where needed. This is not merely a one-for-one swap of algorithms ๐ In many cases, moving to PQC means redesigning protocols and infrastructure to handle the significant differences in resource utilization and key sizes between traditional and PQC algorithms. Because these impacts are so wide-ranging, discussions of protocol changes are woven throughout this document instead of being stuck in one section ๐งถ
This document gives general guidance to engineers working on cryptographic libraries, network security, and infrastructure development, where long-term security planning is crucial ๐ It covers topics like selecting appropriate PQC algorithms and understanding the differences between PQC Key Encapsulation Mechanisms (KEMs) and traditional Diffie-Hellman (DH) and RSA-style key exchanges. It also gives insights into the expected differences in keys, ciphertext, signature sizes, and processing times between PQC and traditional algorithms ๐ Plus, it discusses the potential threat to symmetric cryptography and hash functions from CRQCs ๐
Here's the thing to remember: asymmetric algorithms (also known as public key algorithms) are largely used for secure communications between organizations or endpoints that may never have interacted before ๐ค So a lot of coordination between organizations, and within and between ecosystems, needs to be factored in. These transitions are some of the most complicated in the tech industry ๐ตโ๐ซ and will require staged migrations in which upgraded agents need to coexist and communicate with non-upgraded agents, at a scale never before undertaken ๐
The National Security Agency (NSA) of the United States released an article on future PQC algorithm requirements for US national security systems [CNSA2-0], based on the need to protect against deployments of CRQCs in the future ๐บ๐ธ The German Federal Office for Information Security (BSI) also released a PQC migration and recommendations document [BSI-PQC] that largely aligns with United States National Institute of Standards and Technology (NIST) and NSA guidance, but differs in aspects such as specific PQC algorithm profiles ๐ฉ๐ช
CRQCs pose a threat to both symmetric and asymmetric cryptographic schemes, but the threat to asymmetric cryptography is significantly greater because of Shor's algorithm [Shors], which can break widely used public key schemes like RSA and ECC ๐ฅ Symmetric cryptography and hash functions face a lower risk from Grover's algorithm [Grovers]. The impact is less severe and can typically be mitigated by doubling key and digest lengths where the risk applies ๐ฆ It's crucial that you understand that when "PQC" comes up in this document, it means asymmetric cryptography (or public key cryptography), and not symmetric algorithms based on stream ciphers, block ciphers, hash functions, Message Authentication Codes (MACs), etc., which are less vulnerable to quantum computers ๐ This document doesn't cover when traditional algorithms might become vulnerable (for that, check out documents such as [QC-DNS] and others) ๐
Quick aside: this doc is NOT about quantum key distribution (QKD) or quantum key generation. Those are unrelated technologies that use quantum hardware to exploit quantum effects to protect communications and generate keys, respectively. PQC is based on conventional math (not on quantum mechanics) and software, so it can run on any general-purpose computer ๐ป๐ธ
This document doesn't go into the deep mathematics or technical specification of the PQC algorithms ๐ค It's more of an overview for engineers on the current threat landscape and the relevant algorithms designed to help prevent those threats. Also, the cryptographic and algorithmic guidance in this document should be taken as non-authoritative if it conflicts with emerging and evolving guidance from the IRTF's Crypto Forum Research Group (CFRG) ๐ซถ
2. Terminology ๐
Let's get the vocab down so we're all on the same page ๐
- Quantum computer: A computer that performs computations using quantum-mechanical phenomena such as superposition and entanglement.
- Physical qubit: The basic physical unit in a quantum computer, which is prone to noise and errors.
- Logical qubit: A fault-tolerant qubit constructed from multiple physical qubits using quantum error correction. It is the effective unit for reliable quantum computation.
- Post-Quantum Cryptography (PQC): Cryptographic algorithms designed to be secure against quantum and classical attacks.
- Cryptographically Relevant Quantum Computer (CRQC): A quantum computer with sufficient logical qubits to break traditional asymmetric cryptographic algorithms (e.g., RSA or ECC) within a practical timeframe.
- Public Key Cryptography (also called Asymmetric Cryptography): A class of cryptographic algorithms in which separate keys are used for encryption and decryption, or for signing and verification. Throughout this document, the terms Public Key Cryptography and Asymmetric Cryptography are used interchangeably ๐
Now the naming drama ๐ฟ There's ongoing discussion about whether to use the term "post-quantum", "quantum ready", "quantum resistant", or "quantum secure" to describe algorithms that resist CRQCs, and a consensus has not been reached yet ๐คทโโ๏ธ NIST coined the term "post-quantum" to refer to the algorithms that took part in its competition-like selection process. In this context, the term can be read as "the set of algorithms that are designed to still be relevant after quantum computers exist," and it's not a statement about their security. "Quantum resistant" or "quantum secure" is obviously the goal of these algorithms. However, some people have raised concerns that labeling a class of algorithms as "quantum resistant" or "quantum secure" could cause confusion if one or more of those algorithms are later found to be insecure, or to not resist quantum computers as much as theory predicted ๐ฌ "Quantum ready" is often used to refer to a solution (a device, appliance, or software stack) that has reached maturity with regard to integrating these new cryptographic algorithms. That said, the authors recognize there's great variability in how these terms are used. This document uses these terms interchangeably to refer to such algorithms ๐
In this document, the terms "current", "state-of-the-art", and "ongoing" refer to work, research, investigations, deployments, or developments that are applicable at the time of publication โฐ
3. Threat of CRQCs on Cryptography ๐ฅ
Okay, this section is the heart of the threat model, so pay attention ๐ When you're thinking about the security risks of a quantum computer attacking traditional cryptography, it's important to tell apart the impact on symmetric algorithms and on public key ones. Dr. Peter Shor and Dr. Lov Grover developed two algorithms that totally changed the way the world thinks about security in the presence of a CRQC ๐
Quantum computers are, by their nature, hybrids of classical and quantum computational units. For example, Shor's algorithm is a mix of quantum and classical computational steps ๐งฉ So the term "quantum adversary" should be thought of as "quantum-enhanced adversary", meaning they have access to both classical and quantum computational techniques ๐
Although large-scale quantum computers don't exist yet to experiment on, the theoretical properties of quantum computation are very well understood ๐ This lets engineers and researchers reason about the upper limits of quantum-enhanced computation, and design cryptographic algorithms that are resistant to any conceivable form of quantum cryptanalysis ๐ฆธโโ๏ธโจ
3.1. Symmetric Cryptography โจ
okay bestie, let's talk symmetric crypto ๐ For unstructured data like symmetric encrypted data or cryptographic hashes, CRQCs can search for specific solutions across all possible input combinations (e.g., Grover's algorithm), but no quantum algorithm is known to break the underlying security properties of these classes of algorithms ๐ Symmetric-key cryptography includes keyed primitives like block ciphers (e.g., AES) and message authentication mechanisms (e.g., HMAC-SHA256). It relies on secret keys shared between the sender and receiver and stays secure even in a post-quantum world ๐ Symmetric cryptography also includes hash functions (e.g., SHA-256) that do secure message digesting without any shared key material. HMAC (Hashed Message Authentication Code) is a specific construction that uses a cryptographic hash function and a secret key shared between the sender and receiver to produce a message authentication code ๐
Grover's algorithm is a quantum search algorithm with a theoretical quadratic speedup for searching an unstructured database, compared to traditional search algorithms. This has sparked the common misconception that symmetric key lengths need to be doubled for quantum security ๐ When you treat the mapping of hash values to their corresponding hash inputs (also known as pre-image), or of ciphertext blocks to the corresponding plaintext blocks, as an unstructured database, then Grover's algorithm theoretically requires doubling the key sizes of the symmetric algorithms that are currently deployed at the time of publication, to counter the quadratic speedup and maintain the current security level. This is because Grover's algorithm reduces the number of operations needed to break 128-bit symmetric cryptography to 2^64 quantum operations, which might sound computationally feasible. However, quantum operations are fundamentally different from classical ones. 2^64 classical operations can be efficiently parallelized, but 2^64 quantum operations must be performed serially, which makes them infeasible on practical quantum computers ๐
Grover's algorithm is highly non-parallelizable. Even if you deploy 2^c computational units in parallel to brute-force a key using Grover's algorithm, it will complete in time proportional to 2^((128-c)/2). Put simply, using 256 quantum computers will only reduce runtime by a factor of 16, 1024 quantum computers will only reduce runtime by a factor of 32, and so forth (see [NIST] and [Cloudflare]) ๐ Because of this inherent limitation, the general expert consensus is that AES-128 remains secure in practice, and key sizes do not necessarily need to be doubled ๐
It would be natural to ask whether future research will develop a superior algorithm that could outperform Grover's algorithm in the general case. However, Christof Zalka has shown that Grover's algorithm achieves the best possible complexity for this type of search, meaning no significantly faster quantum approach is expected [Grover-Search] ๐
Finally, in their evaluation criteria for PQC, NIST is assessing the security levels of proposed post-quantum algorithms by comparing them against the equivalent traditional and quantum security of AES-128, AES-192, and AES-256. This indicates that NIST is confident in the stable security properties of AES, even in the presence of both traditional and quantum attacks. As a result, 128-bit algorithms can be considered quantum-safe for the foreseeable future โจ However, for compliance purposes, some organizations, such as the French National Agency for the Security of Information Systems (ANSSI) [ANSSI] and the National Security Agency (NSA) (CNSA 2.0) [CNSA2-0], recommend the use of AES-256 ๐ซถ
3.2. Asymmetric Cryptography ๐ฆ
"Shor's algorithm" efficiently solves the integer factorization problem (and the related discrete logarithm problem), which underpin the foundations of the vast majority of public key cryptography the world uses today. This implies that, if a CRQC is developed, today's public key algorithms (e.g., RSA, Diffie-Hellman, and ECC, as well as less commonly used variants such as ElGamal [RFC6090] and Schnorr signatures [RFC8235]) and protocols would need to be replaced by algorithms and protocols that can offer cryptanalytic resistance against CRQCs. Note that Shor's algorithm cannot run solely on a classical computer; it requires a CRQC ๐ญ
For example, studies show that, if a CRQC existed, it could break RSA-2048 in hours or even seconds, depending on assumptions about error correction [RSAShor] [RSA8HRS] [RSA10SC]. While such machines are purely theoretical at the time of writing, this illustrates the eventual vulnerability of RSA to CRQCs ๐ง
For structured data such as public keys and signatures, CRQCs can fully solve the underlying hard problems used in traditional cryptography (see Shor's algorithm). Because an increase in the size of the key pair would not provide a secure solution (short of RSA keys that are many gigabytes in size [PQRSA]), a complete replacement of the algorithm is needed. Therefore, post-quantum public key cryptography must rely on problems that are different from the ones used in traditional public key cryptography (i.e., the integer factorization problem, the finite-field discrete logarithm problem, and the elliptic-curve discrete logarithm problem) ๐ฅ
3.3. Quantum Side-Channel Attacks ๐ธ
Cryptographic side-channel attacks exploit physical implementations (such as timing, power consumption, or electromagnetic leakage) to recover secret keys ๐
The field of cryptographic side-channel attacks potentially stands to gain a boost in attacker power once cryptanalytic techniques can be enhanced with quantum computation techniques [QuantSide]. While a full discussion of quantum side-channel techniques is beyond the scope of this document, implementers of cryptographic hardware should be aware that current best practices for side-channel resistance may not be sufficient against quantum adversaries ๐
4. Traditional Cryptographic Primitives That Could Be Replaced by PQC ๐
Any asymmetric cryptographic algorithm based on integer factorization, finite field discrete logarithms, or elliptic-curve discrete logarithms will be vulnerable to attacks using Shor's algorithm on a CRQC. This document focuses on the principal functions of asymmetric cryptography:
- Key agreement and key transport: Key agreement schemes, typically referred to as Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH), as well as key transport, typically using RSA encryption, are used to establish a shared cryptographic key for secure communication. They are one of the mechanisms that can be replaced by PQC, as they are based on existing public key cryptography and are therefore vulnerable to Shor's algorithm. A CRQC can employ Shor's algorithm to efficiently find the prime factors of a large public key (in the case of RSA), which, in turn, can be exploited to derive the private key. In the case of DH, a CRQC has the potential to calculate the discrete logarithm of the (short- or long-term) DH public key. This, in turn, would reveal the secret required to derive the symmetric encryption key ๐๏ธ
- Digital signatures: Digital signature schemes are used to authenticate the identity of a sender, detect unauthorized modifications to data, and underpin trust in a system. Similar to key agreement, signatures also depend on a public-private key pair based on the same mathematics as key agreement and key transport. Because of this, a break in existing public key cryptography will also affect traditional digital signatures, hence the importance of developing post-quantum digital signatures โ๏ธ
- Boneh-Boyen-Shacham (BBS) signatures: BBS signatures are a privacy-preserving signature scheme that offers zero-knowledge proof-like properties by allowing selective disclosure of specific signed attributes without revealing the entire set of signed data. The security of BBS signatures relies on the hardness of the discrete logarithm problem, making them vulnerable to Shor's algorithm. A CRQC can break the data authenticity security property of BBS but not the data confidentiality (Section 6.9 of [BBS-SIG-SCHEME]) ๐ต๏ธโโ๏ธ
- Content encryption: Content encryption typically refers to the encryption of the data using symmetric key algorithms, such as AES, to ensure confidentiality. The threat to symmetric cryptography is discussed in Section 3.1 ๐
5. NIST PQC Algorithms ๐
At the time of writing, NIST has standardized three PQC algorithms, with more expected to be standardized in the future (see [NISTFINAL]). These algorithms are not necessarily drop-in replacements for traditional asymmetric cryptographic algorithms. For instance, RSA [RSA] and ECC [RFC6090] can be used as both a KEM and a signature scheme, whereas there is currently no post-quantum algorithm that can perform both functions. When upgrading protocols, it is important to replace the existing use of traditional algorithms with either a PQC KEM or a PQC signature method, depending on how the traditional algorithm was previously being used. Additionally, KEMs, as described in Section 9, present a different API than either key agreement or key transport primitives. As a result, they may require protocol-level or application-level changes in order to be incorporated ๐งฉ
5.1. NIST Candidates Selected for Standardization ๐
5.1.1. PQC Key Encapsulation Mechanisms (KEMs) ๐
- ML-KEM: Module-Lattice-Based Key-Encapsulation Mechanism. See FIPS 203 [ML-KEM].
- HQC: Hamming Quasi-Cyclic. See [HQC]. The coding algorithm based on the hardness of the syndrome decoding problem for quasi-cyclic concatenated Reed-Muller and Reed-Solomon (RMRS) codes in the Hamming metric. Reed-Muller (RM) codes are a class of block error-correcting codes commonly used in wireless and deep-space communications, while Reed-Solomon (RS) codes are widely used to detect and correct multiple-bit errors. HQC has been selected as part of the NIST post-quantum cryptography project but has not yet been standardized ๐
5.1.2. PQC Signatures โ๏ธ
- ML-DSA: Module-Lattice-Based Digital Signature Algorithm. See FIPS 204 [ML-DSA].
- SLH-DSA: Stateless Hash-Based Digital Signature Algorithm. See FIPS 205 [SLH-DSA].
- FN-DSA: Fast-Fourier Transform over NTRU-Lattice-Based Digital Signature Algorithm. See [FN-DSA]. Note that NIST has named this algorithm "FN-DSA" and assigned "FIPS 206" for its specification, but at the time of this document's publication, it has not yet been released ๐
For more information about these, see Sections 8.1, 8.2, and 10.2 ๐
6. ISO Candidates Selected for Standardization ๐ท
At the time of writing, ISO has selected three PQC KEM algorithms as candidates for standardization. These are mentioned in the following subsection ๐ซ
6.1. PQC Key Encapsulation Mechanisms (KEMs) ๐ฆ
okay bestie, here are the KEMs ๐
- FrodoKEM: a KEM built on the hardness of learning with errors in algebraically unstructured lattices ๐ธ See [FrodoKEM].
- ClassicMcEliece: a KEM based on the hardness of syndrome decoding of Goppa codes. Goppa codes are a class of error-correcting codes that can fix a certain number of errors in a transmitted message ๐ง The decoding problem is about getting the original message back out of the received noisy codeword. See [ClassicMcEliece].
- NTRU: a KEM based on "N-th degree Truncated polynomial Ring Units" (NTRU) lattices ๐ One variant is Streamlined NTRU Prime (
sntrup761), which gets leveraged for use in SSH [RFC9941]. See [NTRU].
7. Timeline for Transition โณ
okay so the timeline and the big "why do we need to move" motivation are a little different for data confidentiality (think encryption ๐) and data authentication (think signatures โ๏ธ).
For data confidentiality, we're worried about the so-called "harvest now, decrypt later" (HNDL) attack ๐ฌ That's where a malicious actor with serious resources stores sensitive encrypted data today, hoping to decrypt it once a CRQC exists. This means that every single day, sensitive encrypted data is at risk if you're not using quantum-safe strategies, because that data might get deciphered later on ๐
For authentication, signatures often have a very short lifetime between signing and verifying (like during a TLS handshake) ๐ค But some authentication use cases need long lifetimes, like signing firmware or software that will be active for decades, signing legal documents, or signing certificates that get embedded into hardware devices such as smart cards ๐ Even for short-lived signature use cases, the infrastructure often leans on long-lived root keys, and those can be hard to update or replace on in-field devices ๐ซ
+------------------------+----------------------------+
| | |
| y | x |
+------------------------+----------+-----------------+
| | <--------------->
| z | Security gap
+-----------------------------------+
Figure 1: Mosca ModelThis is the vibe the so-called Mosca model captures so nicely ๐ (it's discussed in [Threat-Report]). In Figure 1, "x" is how long systems and data need to stay secure, "y" is the number of years it takes to fully migrate to a PQC infrastructure, and "z" is how long until a CRQC that can break current cryptography shows up โก The model assumes that either encrypted data can be intercepted and stored before the migration finishes in "y" years, or that signatures will still be relied upon for "x" years after they were created. That data stays vulnerable for the whole "x" years of its lifetime, so the sum "x+y" gives us an estimate of the full timeframe the data stays insecure ๐ญ The model basically asks how you're preparing your IT systems during those "y" years (or in other words, how you can minimize those "y" years) so the transition to a PQC infrastructure is as short as possible and the risk of data getting exposed later is as low as possible ๐ง
Other factors could speed up the arrival of a CRQC, and you should not underestimate them ๐ Think faster-than-expected advances in quantum computing, or more efficient versions of Shor's algorithm that need fewer qubits. Innovation comes in waves, so it's good for the industry to stay vigilant and prep as early as possible ๐ Also, the industry tracks advances from public research institutions like universities and from companies that publish their results, but there's also a ton of large-budget quantum research happening privately by various national interests ๐ต๏ธโโ๏ธ So the true state of quantum computer advancement is likely several years ahead of the publicly available research at the date this document is published ๐คฏ
Organizations also need to think honestly about what their migration timeline "y" really is ๐ง If you only count the time between getting a patch from your technology vendor and rolling it out, then "y" might seem as short as a few weeks. But that's the minority of migration cases! More often, a PQC migration involves at least some hardware replacement ๐ ๏ธ For example, performance-sensitive applications will need CPUs with PQC hardware acceleration. Security-sensitive applications will need PQC TPMs, Trusted Execution Environments (TEEs), secure enclaves, and other cryptographic co-processors. Smart card applications will require replacing the cards and the readers. And the readers come in lots of form factors: tap-for-entry door and turnstile readers, PIN pad machines, laptops with built-in smart card readers, and many others ๐ณ
"y" also includes more than just deployment time. It covers preparation time too: integration, testing, auditing, and recertification of cryptographic environments ๐ Consider upstream effects that add to "y" as well, like lead times for vendors to produce PQC-ready products (which may include auditing and certification delays), time for regulating bodies to adopt PQC policies, and time for auditors to get familiar with the new requirements, etc. ๐ If you measure the full migration time "y" from when your vendors start implementing PQC functionality until you switch off your last non-PQC-capable device, then "y" can be quite long, likely measured in years for even most moderately sized organizations ๐ข That long tail should not discourage early action though, bestie ๐
Organizations responsible for protecting long-lived sensitive data or running critical infrastructure will need to start transitioning immediately, especially where data is vulnerable to HNDL attacks ๐จ Post-quantum and traditional (PQ/T) Section 13 or PQ key exchange is relatively self-contained and typically only requires changes to the cryptographic library (e.g., OpenSSL) โจ Migrating to post-quantum or PQ/T digital signatures is a whole different energy, though. It involves broader ecosystem changes, including updates to certificates, certification authorities (CAs), Certificate Management Protocols, HSMs, and trust anchors ๐ฐ Starting early with hybrid key exchange deployments lets organizations gain operational experience, while prototyping and planning for PQ/T or PQ digital signature integration helps spot ecosystem-wide impacts early ๐ This phased approach reduces long-term migration risks and makes sure everyone's ready for the more complex updates ๐
8. PQC Categories ๐งฉ
The post-quantum cryptographic schemes standardized by NIST can be sorted into three main groups: lattice-based, hash-based, and code-based ๐๏ธ Other approaches, like isogeny-based, multivariate-based, and MPC-in-the-Head-based cryptography, are also being explored in research and standardization efforts ๐ NIST also put out a call for additional digital signature proposals to expand the set of post-quantum signatures under evaluation [AddSig] ๐ฃ
8.1. Lattice-Based Public Key Cryptography ๐
Lattice-based public key cryptography uses the simple construction of lattices (i.e., a regular collection of points in a Euclidean space that are evenly spaced) to build "trapdoor" problems ๐ช These problems are efficient to compute if you have the secret information, but challenging to compute otherwise ๐ Examples include the shortest vector, closest vector, short integer solution, learning with errors, module learning with errors, and learning with rounding problems. All of these problems come with strong proofs for worst-to-average case reduction, which basically relates the hardness of the average case to the worst case ๐ง Iconic math, honestly ๐ค
Lattice-based public keys and signatures are bigger than those of classical schemes like RSA or ECC ๐ฆ But the gap is typically less than an order of magnitude for public keys (about 6-10x) and roughly one to two orders of magnitude for signatures (about 10-100x), rather than several orders of magnitude. That's what makes them the best available candidates for general-purpose use, such as replacing RSA in PKIX certificates ๐
Examples of this class of algorithms include ML-KEM, FN-DSA, ML-DSA, and FrodoKEM ๐
It's noteworthy that lattice-based encryption schemes need a rounding step during decryption ๐ณ That step has a non-zero probability of "rounding the wrong way" and causing a decryption failure, meaning valid encryptions get decrypted incorrectly. BUT the parameters of the NIST PQC candidates are carefully chosen so that the probability of such a failure is cryptographically negligible, far lower than the probability of random transmission errors and implementation bugs ๐ In practical terms, these rare decryption failures can be handled the same way as any fatal transport error: both sides simply perform a fresh KEM operation, generating a new ciphertext and shared secret ๐
In cryptanalysis, an oracle is a system an attacker can query to learn whether decryption succeeded or failed ๐ If one exists, an attacker could significantly reduce the security of lattice-based schemes that have a relatively high failure rate. For most of the NIST PQC proposals, though, the number of oracle queries needed to force a decryption failure is above practical limits, as shown in [LattFail1] ๐ก๏ธ More recent works have improved on the results in [LattFail1], showing that the cost of searching for additional failing ciphertexts after one or more have already been found can be sped up dramatically [LattFail2] ๐๏ธ Still, at the time this document is published, the PQC candidates by NIST are considered secure under these attacks, and constant monitoring continues as cryptanalysis research goes on ๐ญ
8.2. Hash-Based Public Key Cryptography ๐งฑ
okay so hash-based public key cryptography (Hash-based PKC) has been around since the 1970s ๐ฐ๏ธ ๐ it was developed by Lamport and Merkle, and it's used to make digital signature algorithms. the security comes from the security of the underlying cryptographic hash function, which is honestly so iconic ๐ฅ
there are so many hash-based signature (HBS) variants since the 1970s, including the recent XMSS [RFC8391], HSS/LMS [RFC8554], or BPQS [BPQS] schemes ๐ธ but here's the lowkey tricky part: unlike a lot of other digital signature techniques, most hash-based signature schemes are stateful ๐ญ that means signing needs you to update and carefully track the state of the secret key. if you produce multiple signatures using the same secret key state, you lose security, and it can ultimately enable signature forgery attacks against that key ๐ not me having to babysit a key's state like that
stateful hash-based signatures with long service lifetimes need extra operational complexity compared to other signature types ๐ง for example, picture a 20-year root key ๐๏ธ you can expect that 20 years is longer than the lifetime of the hardware the key is stored on, so at some point the key will need to be migrated to new hardware. disaster-recovery scenarios, where the primary node fails without warning, can be just as tricky ๐ this needs careful operational and compliance consideration so that no private key state can be reused across the migration or disaster-recovery event. one way to dodge all of this is to only use stateful HBSs for short-term use cases that don't need horizontal scaling, like signing a batch of firmware images and then retiring the signing key โจ very main character energy for a key, honestly
โ ๏ธ reusing private key state across a migration or disaster-recovery event is the nightmare scenario. compliance and operations folks need to watch this one closely, bestie ๐ซถ
the SLH-DSA algorithm, which NIST standardized ๐ uses the HORST (Hash to Obtain Random Subset with Trees) technique and is still the only standardized hash-based signature scheme that's stateless, so it skips all the state-management headaches ๐ฆ SLH-DSA is an upgrade on SPHINCS that shrinks the signature sizes compared to SPHINCS and makes them more compact ๐
8.3. Code-Based Public Key Cryptography ๐
this area of cryptography kicked off in the 1970s and 1980s ๐ it was built on the seminal work of McEliece and Niederreiter, and it's all about cryptosystems based on error-correcting codes. some popular error-correcting codes are Goppa codes (used in McEliece cryptosystems), the encoding and decoding syndrome codes used in HQC, and quasi-cyclic moderate density parity check (QC-MDPC) codes ๐ง โจ
the examples include all the unbroken NIST Round 4 finalists: Classic McEliece, HQC (selected by NIST for standardization), and Bit Flipping Key Encapsulation (BIKE) [BIKE] ๐๐ the squad is strong
9. KEMs ๐
okay this one is a big deal ๐ฅ a Key Encapsulation Mechanism (KEM) is a cryptographic technique for securely exchanging symmetric key material between two parties over an insecure channel ๐ซถ it's commonly used in hybrid encryption schemes, where a combo of asymmetric (public key) and symmetric encryption is used ๐ธ the encapsulation operation of a KEM gives you a fixed-length symmetric key that can be used with a symmetric algorithm (typically a block cipher) in one of two ways:
- to derive a data encryption key (DEK) to encrypt the data ๐
- to derive a key encryption key (KEK) used to wrap a DEK ๐
these techniques are often referred to as the Hybrid Public Key Encryption (HPKE) [RFC9180] mechanism ๐ฆ
the word "encapsulation" was chosen on purpose ๐ to show that KEM algorithms behave differently at the API level from the key agreement, key encipherment, and key transport mechanisms we use today. with key agreement, both parties contribute a public-private key pair to the exchange ๐ค with key encipherment and key transport, the symmetric key material is chosen by one party and "encrypted" or "wrapped" for the other party ๐ฆ KEMs are different: they behave according to the following API primitives [PQCAPI] ๐ง
def kemKeyGen() -> (pk, sk)def kemEncaps(pk) -> (ss, ct)def kemDecaps(ct, sk) -> ss
where pk is the public key, sk is the secret key, ct is the ciphertext representing an encapsulated key, and ss is the shared secret ๐ here's a sample flow of a KEM-based key exchange, shown in Figure 2 โจ
+---------+ +---------+
| Client | | Server |
+---------+ +---------+
+----------------------+ | |
| pk, sk = kemKeyGen() |-| |
+----------------------+ | |
| |
| pk |
|---------->|
| | +-----------------------+
| |-| ss, ct = kemEncaps(pk)|
| | +-----------------------+
| |
| ct |
|<----------|
+------------------------+ | |
| ss = kemDecaps(ct, sk) |-| |
+------------------------+ | |
| |
Figure 2: KEM-Based Key Exchange9.1. Authenticated Key Exchange โจ
Okay bestie, so Authenticated Key Exchange (AKE) with KEMs, where both parties put a KEM public key into the session key, is interactive, same as in Section 9.4 of [RFC9528] ๐ซถ. But a single-sided KEM is a different vibe. That's when one peer has a KEM key sitting in a certificate and the other peer just wants to encrypt for it, like in S/MIME or OpenPGP email. That one can be done with non-interactive HPKE [RFC9180] ๐. Here's how the DH key exchange plays out:
+---------+ +---------+
| Client | | Server |
+---------+ +---------+
+-----------------------+ | |
| Long-term client key: | | |
| sk1, pk1 |-| |
+-----------------------+ | |
| |
| pk1 |
|---------->|
| | +------------------------+
| |-| Long-term server key: |
| | | sk2, pk2 |
| | | ss = KeyEx(pk1, sk2) |
| | +------------------------+
| |
| pk2|
|<----------|
+-------------------------+ | |
| ss = KeyEx(pk2, sk1) | | |
| encryptContent(ss) |-| |
+-------------------------+ | |
| encrypted |
| content |
|---------->|
| | +------------------------+
| | | decryptContent(ss) |
| | +------------------------+Figure 3: DH-Based AKE
Look at that flow ๐. The shared secret ss comes from key material on both the client and the server side, so it counts as an AKE ๐ค. There's also a separate property called Non-Interactive Key Exchange (NIKE). That one asks whether the sender can work out ss and encrypt content without any back-and-forth network messages with the recipient ๐จ. Figure 3 is a DH key exchange, so it's an AKE because both parties use long-term keys that can carry established trust (for example, via certificates) ๐. But it's not a NIKE, because the client has to wait for the network exchange to get the receiver's public key pk2 before it can compute ss and start encrypting ๐ญ. Still, a DH key exchange can be an AKE and a NIKE at the same time if the sender already knows the receiver's public key ahead of time (see Figure 4). Lots of Internet protocols lean on this trick with DH-based key exchanges ๐.
+---------+ +---------+
| Client | | Server |
+---------+ +---------+
+-----------------------+ | |
| Long-term client key: | | |
| sk1, pk1 |-| |
| Long-term server key: | | |
| pk2 | | |
| ss = KeyEx(pk2, sk1) | | |
| encryptContent(ss) |-| |
+-----------------------+ | |
| |
| pk1, |
| encrypted |
| content |
|---------->|
| | +------------------------+
| |-| Long-term server key: |
| | | sk2, pk2 |
| | | ss = KeyEx(pk1, sk2) |
| | | decryptContent(ss) |
| | +------------------------+Figure 4: Simultaneous DH-Based AKE and NIKE
Now the KEM plot twist ๐. A KEM Encaps() is non-deterministic, meaning it uses randomness picked by the sender of that message. So to do an AKE, the client has to wait for the server to generate that randomness and run Encaps() against the client's key, and that always takes a full network round-trip ๐ซ. That means a KEM-based protocol can be an AKE or a NIKE, but it can't be both at once ๐. Because of that, some Internet protocols are going to need a redesign to handle this split, either by adding extra round trips or by trading off some security properties ๐.
+---------+ +---------+
| Client | | Server |
+---------+ +---------+
+------------------------+ | |
| pk1, sk1 = kemKeyGen() |-| |
+------------------------+ | |
| |
|pk1 |
|---------->|
| | +--------------------------+
| |-| ss1, ct1 = kemEncaps(pk1)|
| | | pk2, sk2 = kemKeyGen() |
| | +--------------------------+
| |
| ct1,pk2|
|<----------|
+--------------------------+ | |
| ss1 = kemDecaps(ct1, sk1)| | |
| ss2, ct2 = kemEncaps(pk2)|-| |
| ss = Combiner(ss1, ss2) | | |
+--------------------------+ | |
| |
|ct2 |
|---------->|
| | +--------------------------+
| |-| ss2 = kemDecaps(ct2, sk2)|
| | | ss = Combiner(ss1, ss2) |
| | +--------------------------+Figure 5: KEM-Based AKE
In that figure, Combiner(ss1, ss2) (aka a KEM combiner) is a crypto construction that takes two shared secrets and spits out one combined shared secret ๐งฉ. The simplest version is plain concatenation, ss1 || ss2, but combiners can get way more complicated depending on what cryptographic properties you need ๐ค. For example, if the combined result has to keep IND-CCA2 (see Section 9.2.1) of either input, even when the other input is chosen maliciously, then you need a more complex construct ๐. Another thing to think about with combiner design is the so-called "binding properties" from [KEEPINGUP], which might mean the ciphertexts and recipient public keys need to be included in the combiner ๐. KEM combiner security analysis gets even messier in hybrid setups, where the two KEMs are different algorithms, like ML-KEM plus ECDH ๐. If you want the deep dive on KEM combiners, check out [KEEPINGUP], [KEM-COMBINER], and [PQ-KEM] ๐โจ.
9.2. Security Properties of KEMs ๐
The security properties in this section (IND-CCA2 and binding) are NOT a complete list of every possible KEM security consideration ๐. They were picked because they're fundamental for judging whether a KEM fits a protocol design, and they come up constantly in current PQC work ๐ธ.
9.2.1. IND-CCA2 ๐ก๏ธ
IND-CCA2 (INDistinguishability under adaptive Chosen-Ciphertext Attack) is an advanced security notion for encryption schemes ๐. It keeps the plaintext confidential and holds up against chosen-ciphertext attacks ๐. You can find an appropriate definition of IND-CCA2 security for KEMs in [CS01] and [BHK09]. ML-KEM [ML-KEM] and Classic McEliece both provide IND-CCA2 security ๐.
Understanding IND-CCA2 is essential for anyone designing or implementing cryptographic systems and protocols ๐ง . It's how you figure out how strong an algorithm is, whether it's a good fit for a particular use case, and whether data confidentiality and security requirements are actually met โ . That said, understanding IND-CCA2 is generally not necessary for developers who are just migrating to an IETF-vetted KEM inside a given protocol or flow ๐ซถ. IND-CCA2 is a widely accepted security notion for public key encryption mechanisms, so it's suitable for a broad range of applications ๐. When an IETF specification defines a new KEM, its security considerations should fully describe the relevant cryptographic properties, including IND-CCA2 ๐.
9.2.2. Binding ๐ฆ
KEMs have another set of properties to think about when you build protocols around them: binding [KEEPINGUP] ๐งต. That can be "ciphertext binding", "public key binding", "context binding", or any other property where you don't want stuff getting swapped between KEM invocations ๐. In general, a KEM binds a certain value if an attacker substituting that value will necessarily result in a different shared secret being derived ๐จ. For example, if an attacker can build two different ciphertexts that decapsulate to the same shared secret, the construction isn't ciphertext binding ๐ฌ. If they can make one ciphertext decapsulate to the same shared secret under two different public keys, it isn't public key binding ๐. And if they can swap whole KEM exchanges from one session into another, it isn't context binding ๐ซฃ. Protocol designers may also want to bind protocol state, like a transaction ID or nonce, so that replaying ciphertexts from one session inside a different session gets blocked at the cryptographic level ๐. The server derives a different shared secret in that case, so it can't decrypt the content ๐.
The fix for binding is mostly a protocol design thing ๐ ๏ธ. It's recommended to avoid using the KEM output shared secret directly without integrating it into an appropriate protocol ๐ก. KEM algorithms give you key secrecy, but they don't inherently ensure source authenticity, protect against replay attacks, or guarantee freshness ๐ค. Those properties have to come from putting the KEM into a protocol that's been analyzed for those protections ๐. Even though modern KEMs like ML-KEM produce full-entropy shared secrets, it's still advisable for binding reasons to run the shared secret through a key derivation function (KDF) and also include every value you want bound ๐. Once you do that, you end up with a shared secret that's safe to use at the protocol level ๐โจ.
9.3. HPKE โจ
okay so, hybrid encryption is an old, iconic idea ๐ You use an asymmetric algorithm to set up a key, then a symmetric algorithm does the heavy lifting on the bulk content ๐ The earlier sections covered important security properties of KEMs, like IND-CCA2 security and binding, and honestly they must be supported by proper protocol design ๐ซถ One widely deployed scheme that pulls this off is Hybrid Public Key Encryption (HPKE) [RFC9180] ๐
HPKE [RFC9180] works with a combo of KEMs, KDFs, and Authenticated Encryption with Associated Data (AEAD) schemes ๐ฆ It has three authenticated variants: one authenticates possession of a pre-shared key, and two optional ones authenticate possession of a KEM private key ๐ธ HPKE can also be extended to support hybrid post-quantum KEMs [PQ-HPKE] โจ ML-KEM doesn't support the static-ephemeral key exchange that lets HPKE work with DH-based KEMs and its optional authenticated modes, as discussed in Section 1.5 of [X-WING] ๐ So that's a real plot twist, bestie ๐ญ
10. PQC Signatures ๐
Any digital signature scheme that provides a construction defining security under a post-quantum setting falls under this category of PQC signatures ๐ง
10.1. Security Properties of PQC Signatures ๐
10.1.1. EUF-CMA and SUF-CMA ๐
EUF-CMA (existential unforgeability under chosen message attack) [GMR88] is a security notion for digital signature schemes ๐ It guarantees that an adversary, even with access to a signing oracle, cannot forge a valid signature for an arbitrary message ๐ EUF-CMA gives strong protection against forgery attacks, keeping the integrity and authenticity of digital signatures intact by blocking unauthorized modifications and fraudulent signatures ๐ฅ ML-DSA, FN-DSA, and SLH-DSA all provide EUF-CMA security โจ
SUF-CMA (strong unforgeability under chosen message attack) builds on EUF-CMA by requiring that an adversary cannot produce a different valid signature for a message that the signing oracle has already signed ๐ฆ Like EUF-CMA, it gives robust assurances for digital signature schemes and boosts their security posture even more ๐ ML-DSA, FN-DSA, and SLH-DSA also achieve SUF-CMA security ๐
Understanding EUF-CMA and SUF-CMA is essential if you're designing or implementing cryptographic systems, so the security, reliability, and robustness of your signature schemes actually hold up ๐ซถ These notions make informed decision-making possible, along with vulnerability analysis, compliance with standards, and designing systems with strong protection against forgery attacks ๐ธ For developers migrating to an IETF-vetted PQC signature scheme within a given protocol or flow, a deep understanding of EUF-CMA and SUF-CMA may not be necessary, because the schemes vetted by the IETF already meet these stringent security standards ๐
EUF-CMA and SUF-CMA are considered strong security benchmarks for public key signature algorithms, which makes them suitable for most applications ๐ Authors of IETF specifications should include all security concerns in the "Security Considerations" section of the relevant RFC, and they should not assume that implementers are experts in cryptographic theory ๐ฅบ Please, be kind to your implementers ๐
10.2. Details of FN-DSA, ML-DSA, and SLH-DSA ๐
ML-DSA [ML-DSA] is a digital signature algorithm based on the hardness of lattice problems over module lattices (i.e., the Module Learning with Errors (MLWE) problem) ๐ Its design follows the "Fiat-Shamir with Aborts" [Lyu09] framework introduced by Lyubashevsky, which uses rejection sampling to make lattice-based Fiat-Shamir (FS) schemes compact and secure ๐ ML-DSA samples uniformly distributed random numbers over small integers to compute coefficients in error vectors, which makes it easier to implement compared to FN-DSA [FN-DSA] ๐ฆ FN-DSA uses Gaussian-distributed numbers, which means it needs floating-point arithmetic during signature generation ๐ค
ML-DSA offers both deterministic and randomized signing and is instantiated with three parameter sets that provide different security levels ๐ธ You can read about its security properties in Section 9 of [RFC9881] ๐
FN-DSA [FN-DSA] is based on the GPV hash-and-sign lattice-based signature framework introduced by Gentry, Peikert, and Vaikuntanathan ๐ง That framework requires a certain class of lattices and a trapdoor sampler technique ๐ฅ
The main design principle of FN-DSA is compactness, meaning it's designed to achieve a minimal total memory bandwidth requirement (the sum of the signature size plus the public key size) โจ This is possible thanks to the compactness of NTRU lattices ๐ FN-DSA also offers very efficient signing and verification procedures ๐ซถ The main potential downsides are the non-triviality of its algorithms and the need for floating-point arithmetic support to do Gaussian-distributed random number sampling, where the other lattice schemes use the less efficient but easier-to-support uniformly distributed sampling ๐ญ
Implementers of FN-DSA need to be aware that FN-DSA signing is highly susceptible to side-channel attacks unless constant-time 64-bit floating-point operations are used ๐ This requirement is extremely platform-dependent, as noted in NIST's report [NIST] ๐
The performance characteristics of ML-DSA and FN-DSA may differ based on the specific implementation and hardware platform ๐ Generally, ML-DSA is known for its relatively fast signature generation, while FN-DSA can provide more efficient signature verification ๐ฆ The choice may depend on whether your application needs more frequent signature generation or more frequent signature verification (see [LIBOQS]) ๐ For more clarity on the sizes and security levels, check out the tables in Sections 11 and 12 ๐
SLH-DSA [SLH-DSA] uses the concept of stateless hash-based signatures, where each signature is unique and unrelated to any previous signature (as discussed in Section 8.2) ๐ธ That property removes the need to maintain state information during signing ๐ง SLH-DSA was designed to sign up to 2^64 messages under a given key pair, and it offers three security levels โจ The parameters for each level were chosen to provide 128 bits of security, 192 bits of security, and 256 bits of security ๐ฅ Compared to ML-DSA and FN-DSA, SLH-DSA has smaller public key sizes, but larger signature sizes, slower signature generation, and slower verification ๐ฅน It doesn't introduce a new hardness assumption beyond those inherent to the underlying hash functions ๐ It builds on established foundations in cryptography, which makes it a reliable and robust digital signature scheme for a post-quantum world ๐
All of these algorithms (ML-DSA, FN-DSA, and SLH-DSA) include two signature modes: pure mode, where the entire content is signed directly, and pre-hash mode, where a digest of the content is signed ๐ฆ
10.3. Details of XMSS and LMS ๐ท
The eXtended Merkle Signature Scheme (XMSS) [RFC8391] and the Hierarchical Signature Scheme (HSS) / Leighton-Micali Signature (LMS) [RFC8554] are stateful hash-based signature schemes, where the secret key state changes over time ๐ In both schemes, reusing a secret key state compromises the cryptographic security guarantees, so be careful, bestie ๐ฑ
XMSS and LMS can be used to sign a potentially large but fixed number of messages, and the number of signing operations depends on the size of the tree ๐ณ They provide cryptographic digital signatures without relying on the conjectured hardness of mathematical problems, and instead they lean on the properties of cryptographic hash functions ๐ Multi-tree XMSS and LMS (i.e., XMSS-MT and HSS, respectively) use a hyper-tree-based hierarchical approach, with a Merkle tree at each level of the hierarchy ๐ [RFC8391] describes both single-tree and multi-tree variants of XMSS, while [RFC8554] describes the Leighton-Micali One-Time Signature (LM-OTS) system as well as the LMS and HSS N-time signature systems ๐ฆ The comparison of XMSS and LMS is discussed in Section 10 of [RFC8554] ๐ธ
The number of tree layers in multi-tree XMSS and HSS gives you a trade-off between signature size on one side and key generation and signing speed on the other ๐ง Increasing the number of layers reduces key generation time exponentially and signing time linearly, at the cost of increasing the signature size linearly ๐ HSS allows for customization of each subtree, whereas XMSS-MT doesn't, and instead it uses the same structure for each subtree ๐
Due to the complexities described above, XMSS and LMS aren't suitable replacements for traditional signature schemes like RSA or ECDSA ๐ Applications that expect a long lifetime for a signature, like firmware update or secure boot, are the typical use cases where those schemes can be successfully applied ๐ซถ
10.3.1. LMS Key and Signature Sizes ๐
The LMS scheme is characterized by four distinct parameter sets: the underlying hash function (SHA2-256 or SHAKE-256), the length of the digest (24 or 32 bytes), the LMS tree height parameter that controls the maximal number of signatures the private key can produce, and the width of the Winternitz coefficients (see [RFC8554], Section 4.1), which can be used to trade off signing time for signature size ๐ Parameters can be mixed, which gives you 80 possible parameterizations of the scheme ๐คฏ
The public (PK) and private (SK) key sizes depend on the length of the digest (M) ๐ The signature size depends on the digest, the Winternitz parameter (W), the LMS tree height (H), and the length of the digest again ๐ฆ The table below gives key and signature sizes for the parameterization with digest size M=32 ๐ธ
+====+====+===+======+======+======+======+======+
| PK | SK | W | H=5 | H=10 | H=15 | H=20 | H=25 |
+====+====+===+======+======+======+======+======+
| 56 | 52 | 1 | 8684 | 8844 | 9004 | 9164 | 9324 |
+----+----+---+------+------+------+------+------+
| 56 | 52 | 2 | 4460 | 4620 | 4780 | 4940 | 5100 |
+----+----+---+------+------+------+------+------+
| 56 | 52 | 4 | 2348 | 2508 | 2668 | 2828 | 2988 |
+----+----+---+------+------+------+------+------+
| 56 | 52 | 8 | 1292 | 1452 | 1612 | 1772 | 1932 |
+----+----+---+------+------+------+------+------+
Table 110.4. Hash-then-Sign โจ
okay so bestie, let's talk about hash-then-sign ๐ฆ the idea is that you hash the message before you sign it ๐ which means the whole job of stopping existential forgeries now leans super hard on the collision-resistance of whatever hash function you're using ๐ญ the upside is it can seriously boost application performance, because you're shrinking the signed message that has to get passed between the application and the cryptographic module ๐ซถ and it makes the signature size predictable and manageable ๐ the tradeoff? hashing is still required even for short messages ๐ which piles extra computation onto the verifier ๐ so the performance gets more consistent, but not necessarily faster โจ
hashing the message down to a fixed-size digest also means the signature plays nicely with a wide range of systems and protocols, no matter how big or what shape the message is ๐ and hot take: this is especially clutch for hardware security modules ๐ฅ it cuts down how much data has to get sent and processed by an HSM ๐ picture a networked HSM sitting in a totally different data center from the app calling it, or a smart card plugged in over USB ๐ง streaming a message that's megabytes or gigabytes long could mean real network lag, slow on-device signing, or even running out of on-device memory ๐
also, the vast majority of Internet protocols that sign big messages already do some kind of content hashing at the protocol level ๐ so this is more of a concern for proprietary crypto protocols and protocols from non-IETF standards bodies ๐ TLS 1.3 and DNSSEC both use hash-then-sign ๐ธ in TLS 1.3 [RFC8446] CertificateVerify messages, the signed content includes the transcript hash output (Section 4.4.1 of [RFC8446]) ๐ฆ and DNSSEC [RFC4034] uses it to provide origin authentication and integrity assurance for DNS data โจ the Cryptographic Message Syntax (CMS) [RFC5652] is giving the same energy too, with a mandatory message digest step before the signature algorithm gets invoked ๐
now for the PQC crew ๐ ML-DSA internally bakes in the necessary hash operations as part of its signing algorithm ๐ฅ it takes the original message directly, applies a hash function internally, and then uses that hash value for signature generation ๐ SLH-DSA does its own randomized message compression using a keyed hash function that can handle arbitrary-length messages ๐ง and FN-DSA uses the SHAKE-256 hash function as part of the signature process to derive a digest of the message being signed ๐
so ML-DSA, FN-DSA, and SLH-DSA are lowkey more secure than the traditional hash-then-sign setup ๐ญ because they mix dynamic key material into the message digest, a precomputed hash collision on the message no longer gives you a signature forgery ๐ซถ that's the main reason it's iconic ๐ applications that really want the performance and bandwidth perks of hash-then-sign can still pre-hash at the protocol level before calling ML-DSA, FN-DSA, or SLH-DSA ๐ but protocol designers, be aware: doing that brings back the weakness where hash collisions directly yield signature forgeries ๐ so if your app can handle it, signing the full un-digested message is recommended ๐
11. NIST Recommendations for Security and Performance Trade-offs ๐ธ
okay so this bit is a reprint of info from the NIST PQC project [NIST], as of the time this document is published ๐ Table 2 shows the five security levels NIST provides for PQC algorithms ๐ and neither NIST nor the IETF makes any specific recommendation about which level to use ๐ protocols usually include algorithm choices at multiple levels, so users can pick whatever fits their policies and data classification ๐ฆ kinda like how orgs today pick which size of RSA key to use ๐ the levels are defined as requiring computational resources comparable to or greater than an attack on AES (128, 192, and 256) and SHA2/SHA3 algorithms, aka exhaustive key recovery for AES and optimal collision search for SHA2/SHA3 โจ
+=============+=====================+===========================+
| PQ Security | AES/SHA(2/3) | PQC Algorithm |
| Level | hardness | |
+=============+=====================+===========================+
| 1 | AES-128 (exhaustive | ML-KEM-512, FN-DSA-512, |
| | key recovery) | SLH-DSA-SHA2/SHAKE-128f/s |
+-------------+---------------------+---------------------------+
| 2 | SHA-256/SHA3-256 | ML-DSA-44 |
| | (collision search) | |
+-------------+---------------------+---------------------------+
| 3 | AES-192 (exhaustive | ML-KEM-768, ML-DSA-65, |
| | key recovery) | SLH-DSA-SHA2/SHAKE-192f/s |
+-------------+---------------------+---------------------------+
| 4 | SHA-384/SHA3-384 | No algorithm tested at |
| | (collision search) | this level |
+-------------+---------------------+---------------------------+
| 5 | AES-256 (exhaustive | ML-KEM-1024, FN-DSA-1024, |
| | key recovery) | ML-DSA-87, SLH-DSA-SHA2/ |
| | | SHAKE-256f/s |
+-------------+---------------------+---------------------------+
Table 2so the SLH-DSA-x-yf/s "f/s" bit in that table ๐ง tells you whether SLH-DSA uses SHAKE or SHA-2 as its underlying hash function "x", and whether it's the fast (f) or small (s) version for the "y" bit AES security level ๐ check out [RFC9814] for more deets on SLH-DSA algorithms ๐
next up, the table comparing signature sizes across SLH-DSA categories at equivalent security levels, using the "simple" version ๐ซถ the categories are "f" for fast signature generation and "s" for smaller signatures and faster verification (though signature generation is slower) ๐ญ SHA-256 and SHAKE-256 parameterizations produce the same signature sizes, so they're grouped together here ๐
+==========+===========================+========+=======+===========+
| PQ | Algorithm | Public |Private| Signature |
| Security | | key |key | size (in |
| Level | | size |size | bytes) |
| | | (in |(in | |
| | | bytes) |bytes) | |
+==========+===========================+========+=======+===========+
| 1 | SLH-DSA-{SHA2,SHAKE}-128f | 32 |64 | 17088 |
+----------+---------------------------+--------+-------+-----------+
| 1 | SLH-DSA-{SHA2,SHAKE}-128s | 32 |64 | 7856 |
+----------+---------------------------+--------+-------+-----------+
| 3 | SLH-DSA-{SHA2,SHAKE}-192f | 48 |96 | 35664 |
+----------+---------------------------+--------+-------+-----------+
| 3 | SLH-DSA-{SHA2,SHAKE}-192s | 48 |96 | 16224 |
+----------+---------------------------+--------+-------+-----------+
| 5 | SLH-DSA-{SHA2,SHAKE}-256f | 64 |128 | 49856 |
+----------+---------------------------+--------+-------+-----------+
| 5 | SLH-DSA-{SHA2,SHAKE}-256s | 64 |128 | 29792 |
+----------+---------------------------+--------+-------+-----------+
Table 3and this one ๐ shows how performance hits different security levels, in terms of private key sizes, public key sizes, and ciphertext/signature sizes ๐ฆ
+==========+=============+============+============+================+
| PQ | Algorithm | Public key | Private | Ciphertext/ |
| Security | | size (in | key size | signature |
| Level | | bytes) | (in bytes) | size (in |
| | | | | bytes) |
+==========+=============+============+============+================+
| 1 | ML-KEM-512 | 800 | 1632 | 768 |
+----------+-------------+------------+------------+----------------+
| 1 | FN-DSA-512 | 897 | 1281 | 666 |
+----------+-------------+------------+------------+----------------+
| 2 | ML-DSA-44 | 1312 | 2560 | 2420 |
+----------+-------------+------------+------------+----------------+
| 3 | ML-KEM-768 | 1184 | 2400 | 1088 |
+----------+-------------+------------+------------+----------------+
| 3 | ML-DSA-65 | 1952 | 4032 | 3309 |
+----------+-------------+------------+------------+----------------+
| 5 | FN-DSA-1024 | 1793 | 2305 | 1280 |
+----------+-------------+------------+------------+----------------+
| 5 | ML-KEM-1024 | 1568 | 3168 | 1588 |
+----------+-------------+------------+------------+----------------+
| 5 | ML-DSA-87 | 2592 | 4896 | 4627 |
+----------+-------------+------------+------------+----------------+
Table 412. Comparing PQC KEMs/Signatures against Traditional KEMs, Key Exchanges, and Signatures โจ
okay so this section is basically a glow-up face-off ๐ It puts PQC KEMs and signatures side by side with the traditional ones at similar security levels. The numbers that matter here are secret key sizes, public key sizes, and ciphertext/signature sizes. Bestie, the vibes are very "why is everything so thicc now" ๐ญ
The first table compares traditional and PQC KEMs on security, public and private key sizes, and ciphertext sizes ๐
+=============+=====================+========+=========+============+
| PQ Security | Algorithm | Public | Private | Ciphertext |
| Level | | key | key | size (in |
| | | size | size | bytes) |
| | | (in | (in | |
| | | bytes) | bytes) | |
+=============+=====================+========+=========+============+
| Traditional | P256_HKDF_SHA-256 | 65 | 32 | 65 |
+-------------+---------------------+--------+---------+------------+
| Traditional | P521_HKDF_SHA-512 | 133 | 66 | 133 |
+-------------+---------------------+--------+---------+------------+
| Traditional | X25519_HKDF_SHA-256 | 32 | 32 | 32 |
+-------------+---------------------+--------+---------+------------+
| 1 | ML-KEM-512 | 800 | 1632 | 768 |
+-------------+---------------------+--------+---------+------------+
| 3 | ML-KEM-768 | 1184 | 2400 | 1088 |
+-------------+---------------------+--------+---------+------------+
| 5 | ML-KEM-1024 | 1568 | 3168 | 1568 |
+-------------+---------------------+--------+---------+------------+Table 5 ๐ฆ
The next table does the same thing for signature schemes: security, public and private key sizes, and signature sizes ๐ธ
+=============+=============+============+============+===========+
| PQ Security | Algorithm | Public key | Private | Signature |
| Level | | size (in | key size | size (in |
| | | bytes) | (in bytes) | bytes) |
+=============+=============+============+============+===========+
| Traditional | RSA2048 | 256 | 256 | 256 |
+-------------+-------------+------------+------------+-----------+
| Traditional | ECDSA-P256 | 64 | 32 | 64 |
+-------------+-------------+------------+------------+-----------+
| 1 | FN-DSA-512 | 897 | 1281 | 666 |
+-------------+-------------+------------+------------+-----------+
| 2 | ML-DSA-44 | 1312 | 2560 | 2420 |
+-------------+-------------+------------+------------+-----------+
| 3 | ML-DSA-65 | 1952 | 4032 | 3309 |
+-------------+-------------+------------+------------+-----------+
| 5 | FN-DSA-1024 | 1793 | 2305 | 1280 |
+-------------+-------------+------------+------------+-----------+
| 5 | ML-DSA-87 | 2592 | 4896 | 4627 |
+-------------+-------------+------------+------------+-----------+Table 6 ๐ง
As you can see in the tables, PQC KEMs and signature schemes usually have way bigger keys and ciphertexts/signatures than their traditional counterparts ๐ Those bigger sizes can cause actual problems in protocols. The example given is IKEv2, which sends its messages over UDP. The annoying part is that IKE fragmentation can't be used in the first IKE_SA_INIT exchange, so putting a PQC KEM into IKEv2 is tricky ๐ [RFC9242] fixes this by adding a new exchange called the "Intermediate Exchange", which can be fragmented with the IKE fragmentation mechanism. Then [RFC9370] uses that Intermediate Exchange to do the PQC key exchange after the initial IKEv2 exchange and before IKE_AUTH. Literally so smart ๐
There's another example in Section 6.3.3 of [SP-1800-38C]. Bigger keys and signatures mean the key exchange messages get spread across more network packets. More packets means a higher total loss probability per packet, so in lossy network conditions the key exchange can get slower. Not a vibe ๐ญ
13. Post-Quantum and Traditional (PQ/T) Hybrid Schemes ๐
The move to PQC is kind of unprecedented in modern digital cryptography. Neither the traditional algorithms nor the post-quantum algorithms are fully trusted to protect data for the lifetimes that are required. Traditional algorithms like RSA and ECDH will fall to quantum cryptanalysis ๐ Meanwhile the PQ algorithms come with their own uncertainty: the underlying mathematics, compliance issues, unknown vulnerabilities, and hardware and software implementations that haven't had enough time to mature and rule out traditional cryptanalytic attacks and implementation bugs. Both sides have baggage, bestie ๐ซถ
During the transition from traditional to post-quantum algorithms, there may be a desire or a requirement for protocols that use both types of algorithm. [RFC9794] defines the terminology for PQ/T hybrid schemes ๐
13.1. PQ/T Hybrid Confidentiality ๐
The PQ/T Hybrid Confidentiality property can help mitigate both "harvest now, decrypt now" and HNDL attacks, which are described in Section 7. If the PQ portion turns out to have a flaw, the traditional (T) algorithm is still secure against today's attackers, so it stops immediate decryption ("harvest now, decrypt now") ๐ก๏ธ If the T algorithm gets broken later by CRQCs, the PQ portion (assuming it's still secure) stops later decryption, which is the HNDL case. So a hybrid construction gives confidentiality as long as at least one component stays secure. It's giving redundancy, no cap โจ Two types of hybrid key agreement schemes are discussed below.
- Concatenated hybrid key agreement scheme: The final shared secret that goes into the key derivation function is the concatenation of the secrets established by each key agreement scheme. For example, in [TLS-HYB-KEY-EXCH], the client uses the TLS supported groups extension to advertise support for a PQ/T hybrid scheme, and the server can select that group if it supports the scheme. The hybrid-aware client and server establish a hybrid secret by concatenating the two shared secrets, and that becomes the shared secret in the existing TLS 1.3 key schedule. Iconic teamwork ๐ค
- Cascaded hybrid key agreement scheme: The final shared secret is computed by running the key derivation function as many times as there are key agreement schemes in the hybrid key agreement scheme. For example, [RFC9370] extends IKEv2 so that one or more PQC algorithms can be used alongside the traditional algorithm to derive the final IKE Security Association (SA) keys with the cascade method, as explained in Section 2.2.2 of [RFC9370] ๐ฆ
There are lots of different ways to build these two types of hybrid key agreement, and you have to be careful about which one you pick ๐ The scheme chosen for protocols like TLS 1.3 [TLS-HYB-KEY-EXCH] has IND-CCA2 robustness. In other words, IND-CCA2 security is guaranteed for that scheme as long as at least one of the component algorithms is IND-CCA2 secure ๐
13.2. PQ/T Hybrid Authentication ๐ชช
The PQ/T hybrid authentication property protects against catastrophic breaks or unforeseen vulnerabilities in PQC algorithms. It gives systems extra time to stabilize before they fully migrate to pure PQ deployments ๐ง
This property makes sure authentication using a PQ/T hybrid scheme stays secure as long as at least one component algorithm remains secure. For example, a PQ/T hybrid certificate [ML-DSA-X.509] can be used to support a PQ/T hybrid authentication protocol. However, a PQ/T hybrid authentication protocol doesn't have to use a PQ/T hybrid certificate. Separate certificates can be used for the individual component algorithms [RFC9763]. When separate certificates are used, attackers may be able to take them apart or put them together in unexpected ways, and that can enable cross-protocol attacks ๐ The exact risks depend heavily on the protocol and use case, so a full security analysis is needed. Best practices for making sure pairs of certificates are only used as intended are discussed in more detail in Sections 13.3.2 and 13.3.3 of this document.
Deciding whether and when to support the PQ/T Hybrid Authentication property means weighing how often and how long system upgrades take against when CRQCs will become widely available โณ
13.3. Hybrid Cryptographic Algorithm Combinations: Considerations and Approaches ๐
13.3.1. Hybrid Cryptographic Combinations ๐
You can also use more than two algorithms together in a hybrid scheme, and there are different ways to combine them. For post-quantum transition purposes, pairing a post-quantum algorithm with a traditional one is the most straightforward option, and it's the one recommended. Using multiple post-quantum algorithms with different mathematical bases has also been considered. Combining algorithms so that both have to be used together gives stronger security. Combinations that don't require both will give up some security, but they offer other perks like backwards compatibility and crypto agility ๐ And including a traditional key alongside a post-quantum key often has minimal bandwidth impact. Lowkey the easiest win of the whole section ๐
13.3.2. Composite Keys in Hybrid Schemes โจ
okay so when you're combining keys in an "and" mode, it might make more sense to treat them as one composite key instead of two separate keys ๐. This usually means way fewer changes across PKI ecosystems, because a lot of them aren't ready to handle two keys or dual signatures ๐. To protocol and application parsers, a "composite" algorithm made of two "component" algorithms is just a new algorithm, and supporting new algorithms is already something they do ๐ . Treating multiple "component" keys as one "composite" key also has security advantages ๐ฅ. It prevents cross-protocol reuse of the individual component keys, and it guarantees that all the component keys get revoked or retired together at the same time, especially if the composite is handled as a single object all the way down into the cryptographic module ๐.
All that needs to be done is standardize the formats for how the two keys from the two algorithms get combined into one data structure, and how the two resulting signatures or KEMs get combined into one signature or KEM โจ. The answer can be as simple as concatenation if the lengths are fixed or easily determined. At the time this document is published, security research is still ongoing about the security properties of concatenation-based composite signatures and KEMs, versus fancier signature and KEM combiners and protocol contexts where those simpler combiners are good enough ๐ง.
One last thing is which pairs of algorithms can be combined ๐. Protocols have been trending toward only allowing a small number of "known good" configurations that make sense, often called a "ciphersuite" in cryptography, instead of letting you mix any individual configuration choices that might interact in dangerous ways ๐ . The current consensus is that the same approach should be followed when combining cryptographic algorithms. "Known good" pairs should be explicitly listed ("explicit composite") instead of just allowing any combination of any two cryptographic algorithms ("generic composite") ๐.
The same considerations apply when using multiple certificates to transport a pair of related keys for the same subject ๐. Exactly how two certificates should be managed to avoid some of the pitfalls above is still an active area of investigation ๐ฌ. Using two certificates keeps the certificate tooling simple and straightforward, but in the end it just moves problems (i.e., problems with the requirement that both certificates be used as a pair, that two signatures that must be carried separately, and that both validate) over to the certificate management layer, where addressing these concerns robustly can be hard ๐ญ.
At least one scheme has been proposed that lets the pair of certificates exist as a single certificate when being issued and managed, but dynamically split into individual certificates when needed (see [ENC-PAIR-CERTS]) ๐ฆ.
13.3.3. Key Reuse in Hybrid Schemes ๐จ
An important security note, especially when using hybrid signature keys but also (to a lesser extent) hybrid KEM keys, is key reuse ๐ฑ. In traditional cryptography, so-called "cross-protocol attacks" can happen when the same key is used for multiple protocols, like signing TLS handshakes and signing S/MIME emails. Reusing keys within the same protocol, like using the same key for multiple S/MIME certificates for the same user, isn't best practice, but it isn't generally catastrophic for security. Key reuse becomes a huge security problem within hybrid schemes though ๐.
Consider an {RSA, ML-DSA} hybrid key where the RSA key also appears within a single-algorithm certificate. In this case, an attacker could perform a "stripping attack" ๐. They take some piece of data signed with the {RSA, ML-DSA} key, remove the ML-DSA signature, and present the data as if it was intended for the RSA-only certificate. This leads to a set of security definitions called "non-separability properties", which refers to how well the signature scheme resists various complexities of downgrade/stripping attacks [HYBRID-SIG-SPECT]. Therefore, it is recommended that implementers either reuse the entire hybrid key as a whole or perform fresh key generation of all component keys per usage, and must not take an existing key and reuse it as a component of a hybrid key ๐ซถ.
13.3.4. Future Directions and Ongoing Research ๐ญ
Many aspects of hybrid cryptography are still under investigation ๐งช. The LAMPS Working Group at IETF is actively exploring the security properties of these combinations, and future standards will reflect the evolving consensus on these issues ๐.
14. Impact on Constrained Devices and Networks ๐ง
PQC algorithms generally have larger keys, ciphertext, and signature sizes than traditional public key algorithms ๐ฆ. This has a particularly big impact on constrained devices that operate with limited data rates ๐ฅบ. In the IoT space, these constraints have historically driven significant optimization efforts in the IETF (e.g., in the LAKE and CoRE Working Groups) to adapt security protocols to resource-constrained environments โญ.
As the transition to PQC progresses, these environments will face similar challenges ๐ฌ. Larger message sizes can increase handshake latency, raise energy consumption, and require fragmentation logic ๐. Work is ongoing in the IETF to study how PQC can be deployed in constrained devices (see [CONSTRAIN-DEV-PCQ]) ๐.
15. Security Considerations ๐ก๏ธ
15.1. Cryptanalysis
Traditional cryptanalysis exploits weaknesses in algorithm design, mathematical vulnerabilities, or implementation flaws that are exploitable with classical (i.e., non-quantum) hardware. Quantum cryptanalysis, on the other hand, harnesses the power of CRQCs to solve specific mathematical problems more efficiently ๐คฏ. Quantum side-channel attacks are another form of quantum cryptanalysis. In such attacks, a device under threat is directly connected to a quantum computer, which then injects entangled or superimposed data streams to exploit hardware that lacks protection against quantum side channels ๐ฑ. Both pose threats to the security of cryptographic algorithms, including those used in PQC. It is crucial to develop and adopt new cryptographic algorithms that are resilient against these threats, to ensure long-term security in the face of advancing cryptanalysis techniques ๐.
Recent attacks on side-channel implementations using deep learning-based power analysis have also shown that you need to be cautious while implementing the required PQC algorithms in hardware ๐. Two of the most recent works include one attack on ML-KEM [KyberSide] and one attack on Saber [SaberSide]. An evolving threat landscape points to the fact that lattice-based cryptography is indeed more vulnerable to side-channel attacks, as in [SideCh] and [LatticeSide]. Consequently, some mitigation techniques for side-channel attacks have been proposed; see [Mitigate1], [Mitigate2], and [Mitigate3] ๐ ๏ธ.
15.2. Cryptographic Agility
Cryptographic agility is recommended for both traditional and quantum cryptanalysis, because it enables organizations to adapt to emerging threats, adopt stronger algorithms, comply with standards, and plan for long-term security in the face of evolving cryptanalytic techniques and the advent of CRQCs ๐ฆ.
Several PQC schemes are available that need to be tested, cryptography experts around the world are pushing for the best possible solutions, and the first standards that will ease the introduction of PQC are being prepared ๐. This is of paramount importance and is a call for imminent action for organizations, bodies, and enterprises to start evaluating their cryptographic agility, assess the complexity of implementing PQC into their products, processes, and systems, and develop a migration plan that achieves their security goals to the best possible extent ๐ฃ.
An important and often overlooked step in achieving cryptographic agility is maintaining a cryptographic inventory ๐. Modern software stacks incorporate cryptography in numerous places, making it challenging to identify all instances. Therefore, cryptographic agility and inventory management take two major forms. First, application developers responsible for software maintenance should actively search for instances of hard-coded cryptographic algorithms within applications. When possible, they should design the choice of algorithm to be dynamic, based on application configuration. Second, administrators, policy officers, and compliance teams should take note of any instances where an application exposes cryptographic configurations. These instances should be managed through either organization-wide written cryptographic policies or automated cryptographic policy systems ๐๏ธ.
Numerous commercial solutions are available for detecting hard-coded cryptographic algorithms in source code and compiled binaries, as well as providing cryptographic policy management control planes for enterprise and production environments ๐ผ.
15.3. Jurisdictional Fragmentation
Another potential application of hybrid schemes bears mentioning, even though it is not directly related to PQC: using hybrids to navigate inter-jurisdictional cryptographic connections ๐บ๏ธ. Traditional cryptography is already fragmented by jurisdiction. Consider that while most jurisdictions support ECDH, those in the United States will prefer the NIST curves while those in Germany will prefer the Brainpool curves. China, Russia, and other jurisdictions have their own national cryptography standards. This situation of fragmented global cryptography standards is unlikely to improve with PQC. If "and" mode hybrid schemes become standardized for the reasons mentioned above, then one could imagine leveraging them to create ciphersuites in which a single cryptographic operation simultaneously satisfies the cryptographic requirements of both endpoints ๐.
15.4. Hybrid Key Exchange and Signatures: Bridging the Gap Between PQ/T Cryptography ๐โจ
Okay bestie, so the post-quantum algorithms that got picked for standardization are super new ๐ฑ. They haven't had anywhere near the same depth of study as the traditional algorithms, which is a lot to process ๐ญ. The PQC implementations are brand new too, so they're more likely to have implementation bugs than the battle-tested crypto we rely on today ๐. Some deployments also might have to keep traditional algorithms because of regulatory stuff, like FIPS [SP-800-56C] or Payment Card Industry (PCI) compliance [PCI] ๐. Hybrid key exchange is recommended to level up your security against the HNDL attack ๐ก๏ธ. And hybrid signatures give you time to react if somebody announces a devastating attack against any one algorithm, all without fully ditching traditional cryptosystems ๐ซถ.
Hybrid key exchange runs a classical key exchange and a post-quantum key exchange side by side, at the same time โก. That's giving redundancy ๐, since it protects you against potential weaknesses in PQC algorithms. It also lets trust in PQC algorithms transition gradually ๐ฆ. In backward-compatible designs, it lets things roll out gradually without breaking existing systems ๐. Like, in TLS 1.3, a hybrid key exchange can pair a widely supported classical algorithm, such as X25519, with a post-quantum algorithm like ML-KEM ๐. Legacy clients keep using the classical algorithm, and upgraded clients get to proceed with the hybrid key exchange ๐ง. The main character energy here is everyone gets included ๐ฅน.
Then there are the overhead-spreading hybrid designs, which focus on cutting down the PQ overhead ๐. Approaches like the ones in [PQ-MLS] amortize PQ costs by selectively applying PQ updates during key exchange processes ๐ง . That lets systems balance security and efficiency โ๏ธ. The result is a post-quantum secure channel that keeps the overhead manageable, which makes it especially suitable for constrained environments ๐.
Now the honest part ๐. Some hybrid key exchange options add extra computational and bandwidth overhead. The impact of the traditional key exchange algorithms (e.g., key size) is usually small, though, so the overall jump in resource usage stays manageable for most systems ๐ธ. In highly constrained environments, those hybrid key exchange protocols might be impractical because they need more resources than pure post-quantum or traditional key exchange approaches ๐ฌ. But some hybrid key exchange designs spread out the PQC overhead, which makes them better suited for constrained environments ๐. Ultimately, the right hybrid key exchange design depends on the specific system requirements and use case, so the best approach can vary ๐ .
15.5. Caution: Ciphertext Commitment in KEM vs. DH ๐
Okay, so the ciphertext a KEM generates isn't necessarily directly linked to the shared secret it produces ๐คฏ. KEMs let multiple ciphertexts encapsulate the same shared secret, which gives you flexibility in key management without forcing a strict one-to-one relationship between ciphertexts and shared secrets ๐ฆ. That means you can reuse a secret across different recipients, sessions, or operational contexts without making a new secret every single time โจ. It simplifies key distribution and reduces computational overhead too ๐.
Diffie-Hellman is a different vibe ๐. It inherently links the public key to the derived shared secret, so any change in the public key results in a different shared secret ๐. Totally different energy, and you need to know which one you're working with ๐.
16. IANA Considerations ๐
This document has no IANA actions ๐ท.
17. Further Reading and Resources ๐
If you want a good book on modern cryptography, check out "Serious Cryptography, 2nd Edition" by Jean-Philippe Aumasson [Serious-Crypt] ๐.
The Open Quantum Safe (OQS) Project [OQS] is an open-source project that aims to support the transition to quantum-resistant cryptography ๐.
The IETF's PQUIP Working Group [PQUIP-WG] maintains a list of PQC-related protocol work within the IETF ๐งโโ๏ธ.
18. References ๐
18.1. Normative References ๐
[ClassicMcEliece]"Classic McEliece",<https://classic.mceliece.org/>.[FN-DSA]"FALCON: Fast Fourier lattice-based compact signatures over NTRU",<https://falcon-sign.info/>.[FrodoKEM]"FrodoKEM",<https://frodokem.org/>.[Grovers]Grover, L. K., "A fast quantum mechanical algorithm for database search", STOC '96: Proceedings of the twenty-eighth annual ACM symposium on Theory of Computing, pp. 212-219, DOI 10.1145/237814.237866, 1 July 1996,<https://dl.acm.org/doi/10.1145/237814.237866>.[ML-DSA]NIST, "Module-Lattice-Based Digital Signature Standard", NIST FIPS 204, DOI 10.6028/NIST.FIPS.204, August 2024,<https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf>.[ML-KEM]NIST, "Module-Lattice-Based Key-Encapsulation Mechanism Standard", NIST FIPS 203, DOI 10.6028/nist.fips.203, August 2024,<https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf>.[NTRU]"NTRU",<https://ntru.org/index.shtml>.[RFC4034]Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005,<https://www.rfc-editor.org/info/rfc4034>.[RFC6090]McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, DOI 10.17487/RFC6090, February 2011,<https://www.rfc-editor.org/info/rfc6090>.[RFC8235]Hao, F., Ed., "Schnorr Non-interactive Zero-Knowledge Proof", RFC 8235, DOI 10.17487/RFC8235, September 2017,<https://www.rfc-editor.org/info/rfc8235>.[RFC8391]Huelsing, A., Butin, D., Gazdag, S., Rijneveld, J., and A. Mohaisen, "XMSS: eXtended Merkle Signature Scheme", RFC 8391, DOI 10.17487/RFC8391, May 2018,<https://www.rfc-editor.org/info/rfc8391>.[RFC8446]Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,<https://www.rfc-editor.org/info/rfc8446>.[RFC8554]McGrew, D., Curcio, M., and S. Fluhrer, "Leighton-Micali Hash-Based Signatures", RFC 8554, DOI 10.17487/RFC8554, April 2019,<https://www.rfc-editor.org/info/rfc8554>.[RFC9180]Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180, February 2022,<https://www.rfc-editor.org/info/rfc9180>.[RFC9242]Smyslov, V., "Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 9242, DOI 10.17487/RFC9242, May 2022,<https://www.rfc-editor.org/info/rfc9242>.[RFC9370]Tjhai, CJ., Tomlinson, M., Bartlett, G., Fluhrer, S., Van Geest, D., Garcia-Morchon, O., and V. Smyslov, "Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 9370, DOI 10.17487/RFC9370, May 2023,<https://www.rfc-editor.org/info/rfc9370>.[RFC9881]Massimo, J., Kampanakis, P., Turner, S., and B. E. Westerbaan, "Internet X.509 Public Key Infrastructure -- Algorithm Identifiers for the Module-Lattice-Based Digital Signature Algorithm (ML-DSA)", RFC 9881, DOI 10.17487/RFC9881, October 2025,<https://www.rfc-editor.org/info/rfc9881>.[RSA]Rivest, R. L., Shamir, A., and L. Adleman, "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems", Communications of the ACM, vol. 21, no. 2, pp. 120-126, DOI 10.1145/359340.359342, February 1978,<https://dl.acm.org/doi/pdf/10.1145/359340.359342>.[Shors]Shor, P., "Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer", arXiv:quant-ph/9508027v2, 25 January 1996,<https://arxiv.org/pdf/quant-ph/9508027>.[SLH-DSA]NIST, "Stateless Hash-Based Digital Signature Standard", NIST FIPS 205, DOI 10.6028/NIST.FIPS.205, August 2024,<https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.205.pdf>.
18.2. Informative References ๐
[AddSig]NIST, "Post-Quantum Cryptography: Additional Digital Signature Schemes",<https://csrc.nist.gov/Projects/pqc-dig-sig/standardization>.[ANSSI]ANSSI, "ANSSI views on the Post-Quantum Cryptography transition (2023 follow up)", 21 December 2023,<https://cyber.gouv.fr/sites/default/files/document/follow_up_position_paper_on_post_quantum_cryptography.pdf>.[BBS-SIG-SCHEME]Looker, T., Kalos, V., Whitehead, A., and M. Lodder, "The BBS Signature Scheme", Work in Progress, Internet-Draft, draft-irtf-cfrg-bbs-signatures-10, 8 January 2026,<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-bbs-signatures-10>.[BHK09]Bellare, M., Hofheinz, D., and E. Kiltz, "Subtleties in the Definition of IND-CCA: When and How Should Challenge-Decryption be Disallowed?", Cryptology ePrint Archive, Paper 2009/418, 2009,<https://eprint.iacr.org/2009/418>.[BIKE]"BIKE",<https://bikesuite.org/>.[BPQS]Chalkias, K., Brown, J., Hearn, M., Lillehagen, T., Nitto, I., and T. Schroeter, "Blockchained Post-Quantum Signatures", Cryptology ePrint Archive, Paper 2018/658,<https://eprint.iacr.org/2018/658>.[BSI-PQC]BSI, "Quantum-safe cryptography - fundamentals, current developments and recommendations", 18 May 2022,<https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Brochure/quantum-safe-cryptography.html?nn=916626>.[Cloudflare]Westerbaan, B., "NIST's pleasant post-quantum surprise", Cloudflare Blog, 8 July 2022,<https://blog.cloudflare.com/nist-post-quantum-surprise/>.[CNSA2-0]NSA, "Announcing the Commercial National Security Algorithm Suite 2.0", September 2022,<https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF>.[CONSTRAIN-DEV-PCQ]Reddy.K, T., Wing, D., Salter, B., and K. Kwiatkowski, "Adapting Constrained Devices for Post-Quantum Cryptography", Work in Progress, Internet-Draft, draft-ietf-pquip-pqc-hsm-constrained-05, 1 April 2026,<https://datatracker.ietf.org/doc/html/draft-ietf-pquip-pqc-hsm-constrained-05>.[CRQCThreat]Jaques, S., "Landscape of Quantum Computing",<https://sam-jaques.appspot.com/quantum_landscape_2024>.[CS01]Cramer, R. and V. Shoup, "Design and Analysis of Practical Public-Key Encryption Schemes Secure against Adaptive Chosen Ciphertext Attack", Cryptology ePrint Archive, Paper 2001/108, 2001,<https://eprint.iacr.org/2001/108>.[ENC-PAIR-CERTS]Bonnell, C., Gray, J., Hook, D., Okubo, T., and M. Ounsworth, "A Mechanism for Encoding Differences in Paired Certificates", Work in Progress, Internet-Draft, draft-bonnell-lamps-chameleon-certs-07, 18 October 2025,<https://datatracker.ietf.org/doc/html/draft-bonnell-lamps-chameleon-certs-07>.- [GMR88] Goldwasser, S., Micali, S., and R. L. Rivest, "A digital signature scheme secure against adaptive chosen-message attacks", SIAM Journal on Computing, vol. 17, no. 2, pp. 281-308, DOI 10.1137/0217017, April 1988,
https://people.csail.mit.edu/silvio/Selected%20Scientific%20Papers/Digital%20Signatures/A_Digital_Signature_Scheme_Secure_Against_Adaptive_Chosen-Message_Attack.pdf. - [Grover-Search] Zalka, C., "Grover's quantum searching algorithm is optimal", Physical Review A, vol. 60, no. 4, pp. 2746-2751, DOI 10.1103/PhysRevA.60.2746, October 1999,
https://link.aps.org/doi/10.1103/PhysRevA.60.2746. - [HQC] "HQC",
http://pqc-hqc.org/. - [HYBRID-SIG-SPECT] Bindel, N., Hale, B., Connolly, D., and F. D, "Hybrid signature spectrums", Work in Progress, Internet-Draft, draft-ietf-pquip-hybrid-signature-spectrums-07, 20 June 2025,
https://datatracker.ietf.org/doc/html/draft-ietf-pquip-hybrid-signature-spectrums-07. - [KEEPINGUP] Cremers, C., Dax, A., and N. Medinger, "Keeping Up with the KEMs: Stronger Security Notions for KEMs and automated analysis of KEM-based protocols", Cryptology ePrint Archive, Paper 2023/1933, 2023,
https://eprint.iacr.org/2023/1933. - [KEM-COMBINER] Ounsworth, M., Wussler, A., and S. Kousidis, "Combiner function for hybrid key encapsulation mechanisms (Hybrid KEMs)", Work in Progress, Internet-Draft, draft-ounsworth-cfrg-kem-combiners-05, 31 January 2024,
https://datatracker.ietf.org/doc/html/draft-ounsworth-cfrg-kem-combiners-05. - [KyberSide] Ji, Y., Wang, R., Ngo, K., Dubrova, E., and L. Backlund, "A Side-Channel Attack on a Hardware Implementation of CRYSTALS-Kyber", Cryptology ePrint Archive, Paper 2022/1452, 2022,
https://eprint.iacr.org/2022/1452. - [LattFail1] D'Anvers, J., Guo, Q., Johansson, T., Nilsson, A., Vercauteren, F., and I. Verbauwhede, "Decryption Failure Attacks on IND-CCA Secure Lattice-Based Schemes", Public-Key Cryptography - PKC 2019, Lecture Notes in Computer Science, vol. 11443, pp. 565-598, DOI 10.1007/978-3-030-17259-6_19, 6 April 2019,
https://link.springer.com/chapter/10.1007/978-3-030-17259-6_19. - [LattFail2] D'Anvers, J., Rossi, M., and F. Virdia, "(One) Failure Is Not an Option: Bootstrapping the Search for Failures in Lattice-Based Encryption Schemes", Advances in Cryptology - EUROCRYPT 2020, Lecture Notes in Computer Science, vol. 12107, pp. 3-33, DOI 10.1007/978-3-030-45727-3_1, 1 May 2020,
https://link.springer.com/chapter/10.1007/978-3-030-45727-3_1. - [LatticeSide] Ravi, P., Roy, S. S., Chattopadhyay, A., and S. Bhasin, "Generic Side-channel attacks on CCA-secure lattice-based PKE and KEM schemes", Cryptology ePrint Archive, Paper 2019/948, 2019,
https://eprint.iacr.org/2019/948. - [LIBOQS] "LibOQS - Open Quantum Safe", commit 97f6b86, November 2025,
https://github.com/open-quantum-safe/liboqs. - [Lyu09] Lyubashevsky, V., "Fiat-Shamir With Aborts: Applications to Lattice and Factoring-Based Signatures", ASIACRYPT 2009,
https://www.iacr.org/archive/asiacrypt2009/59120596/59120596.pdf. - [Mitigate1] Hoffmann, C., Libert, B., Momin, C., Peters, T., and F. Standaert, "POLKA: Towards Leakage-Resistant Post-Quantum CCA-Secure Public Key Encryption", Cryptology ePrint Archive, Paper 2022/873, 2022,
https://eprint.iacr.org/2022/873. - [Mitigate2] Tsai, T., Huang, S., Tseng, Y., Chuang, Y., and Y. Hung, "Leakage-Resilient Certificate-Based Authenticated Key Exchange Protocol", IEEE Open Journal of the Computer Society, vol. 3, pp. 137-148, DOI 10.1109/OJCS.2022.3198073, 2022,
https://ieeexplore.ieee.org/document/9855226. - [Mitigate3] Azouaoui, M., Kuzovkova, Y., Schneider, T., and C. V. Vredendaal, "Post-Quantum Authenticated Encryption against Chosen-Ciphertext Side-Channel Attacks", Cryptology ePrint Archive, Paper 2022/916, 2022,
https://eprint.iacr.org/2022/916. - [ML-DSA-X.509] Ounsworth, M., Gray, J., Pala, M., Klauรner, J., and S. Fluhrer, "Composite Module-Lattice-Based Digital Signature Algorithm (ML-DSA) for use in X.509 Public Key Infrastructure", Work in Progress, Internet-Draft, draft-ietf-lamps-pq-composite-sigs-19, 21 April 2026,
https://datatracker.ietf.org/doc/html/draft-ietf-lamps-pq-composite-sigs-19. - [NIST] NIST, "Post-Quantum Cryptography Standardization",
https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization. - [NISTFINAL] NIST, "NIST Releases First 3 Finalized Post-Quantum Encryption Standards", 13 August 2024,
https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards. - [OQS] "Open Quantum Safe Project",
https://openquantumsafe.org/. - [PCI] PCI Security Standards Council, "Payment Card Industry Data Security Standard", PCI DSS: v4.0.1,
https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0_1.pdf. - [PQ-HPKE] Barnes, R. and D. Connolly, "Post-Quantum and Post-Quantum/Traditional Hybrid Algorithms for HPKE", Work in Progress, Internet-Draft, draft-ietf-hpke-pq-04, 2 March 2026,
https://datatracker.ietf.org/doc/html/draft-ietf-hpke-pq-04. - [PQ-KEM] Connolly, D., Barnes, R., and P. Grubbs, "Hybrid PQ/T Key Encapsulation Mechanisms", Work in Progress, Internet-Draft, draft-irtf-cfrg-hybrid-kems-11, 7 May 2026,
https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hybrid-kems-11. - [PQ-MLS] Tian, X., Hale, B., Mularczyk, M., and J. Alwen, "Amortized PQ MLS Combiner", Work in Progress, Internet-Draft, draft-ietf-mls-combiner-02, 22 October 2025,
https://datatracker.ietf.org/doc/html/draft-ietf-mls-combiner-02. - [PQCAPI] NIST, "PQC - API notes",
https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/documents/example-files/api-notes.pdf. - [PQRSA] Bernstein, D. J., Heninger, N., Lou, P., and L. Valenta, "Post-quantum RSA", 19 April 2017,
https://cr.yp.to/papers/pqrsa-20170419.pdf. - [PQUIP-WG] IETF, "Post-Quantum Use In Protocols (pquip)",
https://datatracker.ietf.org/group/pquip/documents/. - [QC-DNS] Hoffman, P., "Quantum Computing and the DNS", ICANN Office of the Chief Technology Officer, OCTO-031v2, 22 April 2024,
https://www.icann.org/octo-031-en.pdf. - [QuantSide] Xu, C., Erata, F., and J. Szefer, "Exploration of Quantum Computer Power Side-Channels", arXiv:2304.03315v2, 9 May 2023,
https://arxiv.org/pdf/2304.03315. - [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009,
https://www.rfc-editor.org/info/rfc5652. - [RFC9528] Selander, G., Preuร Mattsson, J., and F. Palombini, "Ephemeral Diffie-Hellman Over COSE (EDHOC)", RFC 9528, DOI 10.17487/RFC9528, March 2024,
https://www.rfc-editor.org/info/rfc9528. - [RFC9763] Becker, A., Guthrie, R., and M. Jenkins, "Related Certificates for Use in Multiple Authentications within a Protocol", RFC 9763, DOI 10.17487/RFC9763, June 2025,
https://www.rfc-editor.org/info/rfc9763. - [RFC9794] Driscoll, F., Parsons, M., and B. Hale, "Terminology for Post-Quantum Traditional Hybrid Schemes", RFC 9794, DOI 10.17487/RFC9794, June 2025,
https://www.rfc-editor.org/info/rfc9794. - [RFC9814] Housley, R., Fluhrer, S., Kampanakis, P., and B. Westerbaan, "Use of the SLH-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS)", RFC 9814, DOI 10.17487/RFC9814, July 2025,
https://www.rfc-editor.org/info/rfc9814. - [RFC9941] Friedl, M., Mojzis, J., and S. Josefsson, "Secure Shell (SSH) Key Exchange Method Using Hybrid Streamlined NTRU Prime sntrup761 and X25519 with SHA-512: sntrup761x25519-sha512", RFC 9941, DOI 10.17487/RFC9941, April 2026,
https://www.rfc-editor.org/info/rfc9941. - [RSA10SC] QuintessenceLabs, "Breaking RSA Encryption - an Update on the State-of-the-Art", 13 June 2019,
https://www.quintessencelabs.com/blog/breaking-rsa-encryption-update-state-art. - [RSA8HRS] Gidney, C. and M. Ekera, "How to factor 2048 bit RSA integers in 8 hours using 20 million noisy qubits", arXiv:1905.09749v3, 13 April 2021,
https://arxiv.org/abs/1905.09749. - [RSAShor] Beauregard, S., "Circuit for Shor's algorithm using 2n+3 qubits", arXiv:quant-ph/0205095v3, 21 February 2003,
https://arxiv.org/pdf/quant-ph/0205095.pdf. - [SaberSide] Ngo, K., Dubrova, E., and T. Johansson, "A side-channel attack on a masked and shuffled software implementation of Saber", Journal of Cryptographic Engineering, vol. 13, pp. 443-460, DOI 10.1007/s13389-023-00315-3, 25 April 2023,
https://link.springer.com/article/10.1007/s13389-023-00315-3. - [Serious-Crypt] Aumasson, J., "Serious Cryptography, 2nd Edition", ISBN 9781718503847, August 2024.
- [SideCh] Ngo, K., Wang, R., Dubrova, E., and N. Paulsrud, "Side-Channel Attacks on Lattice-Based KEMs Are Not Prevented by Higher-Order Masking", Cryptology ePrint Archive, Paper 2022/919, 2022,
https://eprint.iacr.org/2022/919. - [SP-1800-38C] Newhouse, W., Souppaya, M., Barke, W., Brown, C., Kampanakis, P., Goodman, J., Prat, J., Larrieu, R., Gray, J., Ounsworth, M., Viana, C., Gong, H. L. V., Kwiatkowsk, K., Hu, A., Burns, R., Paquin, C., Gilbert, J., Scinta, G., Kim, E., and V. Krumme, "Migration to Post-Quantum Cryptography Quantum Readiness: Testing Draft Standards, Volume C: Quantum-Resistant Cryptography Technology Interoperability and Performance Report", Preliminary Draft, NIST SP 1800-38C, December 2023,
https://www.nccoe.nist.gov/sites/default/files/2023-12/pqc-migration-nist-sp-1800-38c-preliminary-draft.pdf.
[SP-800-56C] ๐ง Barker, E., Chen, L., and R. Davis, "Recommendation for Key-Derivation Methods in Key-Establishment Schemes", NIST SP 800-56Cr2, DOI 10.6028/NIST.SP.800-56Cr2, August 2020, https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr2.pdf.
[Threat-Report] ๐ฅ Mosca, M. and M. Piani, "Quantum Threat Timeline Report 2020", Global Risk Institute, 27 January 2021, https://globalriskinstitute.org/publications/quantum-threat-timeline-report-2020/.
[TLS-HYB-KEY-EXCH] ๐ Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid key exchange in TLS 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-hybrid-design-16, 7 September 2025, https://datatracker.ietf.org/doc/html/draft-ietf-tls-hybrid-design-16.
[X-WING] ๐ฆ Connolly, D., Schwabe, P., and B. Westerbaan, "X-Wing: general-purpose hybrid post-quantum KEM", Work in Progress, Internet-Draft, draft-connolly-cfrg-xwing-kem-10, 2 March 2026, https://datatracker.ietf.org/doc/html/draft-connolly-cfrg-xwing-kem-10.
Acknowledgements ๐ซถ
okay bestie, the authors gotta give credit where it's due ๐ This document borrows text from an earlier Internet-Draft by Paul Hoffman โจ Huge thanks to Dan Wing, Florence D, Thom Wiggers, Sophia Grundner-Culemann, Panos Kampanakis, Ben S, Sofia Celi, Melchior Aelmans, Falko Strenzke, Deirdre Connolly, Hani Ezzadeen, Britta Hale, Scott Rose, Hilarie Orman, Thomas Fossati, Roman Danyliw, Mike Bishop, Maliลกa Vuฤiniฤ, รric Vyncke, Deb Cooley, Dirk Von Hugo, and Daniel Van Geest for the discussion, review and comments ๐ธ The whole squad showed up.
In particular, the authors would like to acknowledge the contributions to this document by Kris Kwiatkowski. ๐
Authors' Addresses ๐
Here are the people who wrote it, with their homes and emails ๐
Aritra Banerjee ๐
Aritra Banerjee
Nokia
London
United Kingdom
Email: aritra.banerjee@nokia.comTirumaleswar Reddy.K ๐ฆ
Tirumaleswar Reddy.K
Nokia
Bangalore
Karnataka
India
Email: k.tirumaleswar_reddy@nokia.comDimitrios Schoinianakis โญ
Dimitrios Schoinianakis
Nokia
Athens
Greece
Email: dimitrios.schoinianakis@nokia-bell-labs.comTimothy Hollebeek ๐
Timothy Hollebeek
DigiCert
Pittsburgh, PA
United States of America
Email: tim.hollebeek@digicert.comMike Ounsworth ๐ง
Mike Ounsworth
Entrust Limited
2500 Solandt Road, Suite 100
Ottawa, Ontario K2K 3G5
Canada
Email: mike@ounsworth.caAnd that's a wrap on RFC 9958, bestie! ๐โจ๐
๐ฆ where this page comes from
- ietf: rfc9958 2026-06
- ๐ girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms