1. The short version / before you read / where this fits in the series

• Public-key encryption is built on trust in "computational hardness": RSA relies on factoring being hard, and Diffie-Hellman and elliptic-curve cryptography on the discrete logarithm being hard. Quantum computers are known to have an efficient method (Shor's algorithm) for both[Ref. 7, 9]
• The remedy is to switch to other "hard problems": on 13 August 2024 NIST published ML-KEM (key establishment, FIPS 203) and ML-DSA (signatures, FIPS 204), both based on lattices, and SLH-DSA (signatures, FIPS 205), based on hash functions[Ref. 19, 21, 22, 23]. For shared-key ciphers such as AES the response centres on longer keys
• Hardness is something that keeps being checked: new hard problems are examined over years. In 2022 two candidates in the standardisation process were broken by attacks on ordinary computers[Ref. 29, 30]. That is why the "hybrid approach" that uses a classical scheme and PQC together has also been standardised[Ref. 33]

2. The foundations again: shared-key and public-key encryption

There are two broad kinds of encryption (see Fig. 2 of the previous article). Shared-key encryption has the sender and receiver hold the same key, locking and unlocking with it. It is fast and suits large data, but raises the question of how to hand over the first key safely. Public-key encryption hands out "padlocks" (public keys) to anyone, and only the holder of the secret key can open them, so no key has to be delivered in advance.

Public-key cryptography has another important use: the digital signature. A signature lets anyone check, with the public key, that "this data was made by the holder of this secret key and was not altered on the way"[Ref. 22]. It is used to confirm that a website is genuine and to verify software updates. PQC replaces both key establishment (making a key) and signatures (confirming authenticity).

3. Trying public-key encryption with small numbers

What does it mean that public-key cryptography is made of "computational hardness"? Here we try two schemes with small numbers. The only mathematics is "remainders after division". A clock goes round at 12, so "5 hours after 10 o'clock" is "15 divided by 12, remainder 3, i.e. 3 o'clock". We multiply and take powers in this "world of remainders" (clock arithmetic).

(1) Making a shared secret in public: Diffie-Hellman

The scheme shown by Diffie and Hellman in 1976 lets two parties make a secret only they share, even while talking in public[Ref. 1]. First the paint analogy. Yellow paint is shared in public. Alice mixes in her private red to make orange, and Bob his private blue to make green, and they swap the mixtures in public. Each mixes their own private colour into what they received, and both end up with the same brown. An eavesdropper who sees yellow, orange and green cannot make that brown (the analogy is that mixing is easy but recovering the original colours from a mixture is hard).

In numbers, "mixing colours" corresponds to "raise a number to a power and take the remainder". With small numbers an eavesdropper can find the secret number by trial, but with numbers hundreds of digits long, finding it (the discrete logarithm problem) is believed to be extremely hard[Ref. 1]. Elliptic-curve cryptography does the same thing on a different mathematical object, an elliptic curve, and was introduced by Koblitz and others in the 1980s[Ref. 4].

(2) Multiplying is easy, finding the factors is hard: RSA

RSA, introduced by Rivest, Shamir and Adleman in 1978, relies on the fact that multiplying two primes is easy, but finding the original primes from the product (factoring) is hard[Ref. 2]. The public key contains the product, and the secret key can be made only by someone who knows the original primes.

With small numbers, "which two numbers multiply to 3233?" is found at once by trial. But a real key is 2048 bits (617 decimal digits). As a record for factoring on classical computers, Boudot et al. reported in a 2020 paper the factoring of RSA-240, a 795-bit number (240 digits)[Ref. 5]. A 2048-bit number is far larger. RSA has been considered safe because today's ordinary computers cannot solve this in realistic time.

4. Why quantum computers threaten it

In 1994 Shor showed that a quantum computer could solve factoring and discrete logarithms efficiently[Ref. 6, 7]. A 2016 NIST report explains that this could defeat many public-key schemes such as RSA, Diffie-Hellman and elliptic-curve cryptography[Ref. 9]. Here is the mechanism, in concept only.

The key is that factoring can be turned into the problem of finding a period. The sequence of "a to the power x, mod N" always repeats with some period. Once that period is known, an ordinary computer can calculate the prime factors of N. No method is known to find the period of a large N on a classical computer, and that is the difficulty of factoring. A quantum computer can find the period by "interference of waves" (adding up the waves of the arrows so that the correct period reinforces itself) (concept; see our explainer on quantum algorithms).

Another quantum algorithm is Grover's search algorithm of 1996[Ref. 8], which makes search "quadratically faster". The 2016 NIST report says it does not make cryptography obsolete but may require longer keys even for shared-key ciphers, gives the rule of thumb that doubling the key length preserves security, and adds that it is not known whether Grover's algorithm will ever be practically relevant[Ref. 9]. The NIST PQC FAQ also explains that in practical attacks, needs such as parallelisation reduce the advantage of Grover's algorithm[Ref. 28].

So when will it become a threat? Being honest that it is unknown

NIST describes quantum computers as machines that "may be years or decades away but could eventually break many of today's widely used cryptographic systems"[Ref. 19]. The timing cannot be asserted. Estimates of the scale needed are reported under assumptions. Gidney and Ekerå estimated that 2048-bit RSA could be factored in 8 hours with 20 million noisy qubits[Ref. 10]. In 2025 Gidney reported, under the same assumptions (a surface code, a gate error rate of 0.1%, a code cycle of one microsecond and so on), a lower estimate of fewer than a million qubits and less than a week[Ref. 11].

Experts' views also vary. The 2025 report by the Global Risk Institute and evolutionQ (published 9 March 2026) says that in a survey of 26 experts, respondents considered a cryptographically relevant quantum computer (CRQC) "quite possible (28-49%)" within 10 years and "likely (51-70%)" within 15[Ref. 12]. This is a survey of opinion, not a basis for prediction. Given that the estimated requirement fell greatly within a few years (the two estimates above) and that expert views span a range, not asserting "when" and instead estimating the time needed to prepare is the subject of the next article.

5. A new "hard problem": lattices

Several kinds of problem are believed to be hard for quantum computers. The foundation of ML-KEM and ML-DSA, standardised by NIST in 2024, is a problem about lattices[Ref. 21, 22].

(1) What a lattice is: a regularly spaced net of points

A lattice is the set of points made by "adding whole-number multiples of two (or many) arrows". Like the crossings on graph paper, the points are regularly spaced. The same lattice can be generated by many choices of arrows (the basis): a pair that is short and nearly at right angles (a good basis) or a pair that is long and skewed (a bad basis).

Consider the problem of finding the lattice point closest to a marked point. As in the figure, with a good basis a simple rounding recipe finds the closest point; the same recipe with a bad basis lands on a farther point (distances 31 and 45 in this example). In two dimensions either basis lets you find it by trial. But when the dimension reaches hundreds or a thousand, finding a good basis itself is believed to become extremely hard. Cryptography uses this hardness[Ref. 15].

If the secret key is likened to the "good basis" and the public key to the "bad basis", you get a lock in which someone who sees only the public key cannot find the close point, while the holder of the secret can (limit of the analogy: the real ML-KEM and ML-DSA do not take the form in this figure but use the "equations with errors" explained next).

(2) "Equations with errors" (LWE)

In 2005 Regev showed that mixing tiny errors into simultaneous equations makes them extremely hard to solve, linking this to the hardness of lattice problems (Learning With Errors, LWE)[Ref. 13]. Equations without errors can be solved by anyone who has as many equations as unknowns. But once each equation carries a slight error, no exact solution exists and it becomes a search for the "closest solution".

The small example in the figure (two unknowns, working mod 17) can be solved by trying 289 candidates. In the real ML-KEM-768 there are 768 unknowns, in a world of remainders mod 3329. The table of FIPS 203 gives the number of polynomial coefficients n = 256, the modulus q = 3329 and the parameter k = 3 (ML-KEM-768)[Ref. 21]. 3329 to the power 768 is about 10 to the power 2705, so trying all candidates is out of the question (Our calculation; however, real security is judged not by brute force but by the best attacks such as lattice reduction).

ML-KEM rests on LWE with a structure called a "module" (Module-LWE). Langlois and Stehlé gave grounds for the hardness of module-lattice problems[Ref. 14]. The scheme from which it was standardised is CRYSTALS-Kyber, designed by Bos et al.[Ref. 16]. FIPS 203 says it is named ML-KEM because it is based on the Module-LWE assumption[Ref. 21].

(3) What a "key-encapsulation mechanism" (KEM) is

ML-KEM is not for directly encrypting a message but a part for two parties to make a "shared secret". In the words of FIPS 203, a key-encapsulation mechanism (KEM) is a set of algorithms by which two parties can establish a shared secret key over a public channel[Ref. 21]. In the padlock analogy, Alice makes a "shared secret" herself, locks it inside Bob's padlock (the public key) (encapsulation) and sends it, and Bob opens it with his secret key (decapsulation). Both now hold the same shared secret, which they use for later encryption.

6. Signatures: lattices and hash functions

There are two families of standards for signatures.

• ML-DSA (FIPS 204): a lattice-based signature. It derives from CRYSTALS-Dilithium, designed by Ducas et al.[Ref. 17, 22]. The signature size is 3,309 bytes for ML-DSA-65 (table in the next chapter).
• SLH-DSA (FIPS 205): a signature based on hash functions alone. It derives from SPHINCS+, designed by Bernstein et al.[Ref. 18, 23]. FIPS 205 says its security depends on the presumed difficulty of finding preimages for hash functions and several related properties[Ref. 23]. Because it does not rely on lattice assumptions, it serves as insurance should lattices be broken (our commentary).

How hash-based signatures work: a tree that gathers "one-time keys"

A hash function turns any data into a fixed-length "fingerprint" and is very hard to reverse. Hash-based signatures are built from such fingerprints alone. The basic part is a one-time signing key that can be used only once. Many one-time keys are made, their fingerprints are gathered into a tree (a hash tree) and only the fingerprint at the top is published as the public key. A signature carries the signature of the key used and the path up to the top of the tree (fingerprints for checking).

NIST SP 800-208 (2020) deals with stateful hash-based signatures (LMS and XMSS)[Ref. 24]. "Stateful" means the signer must remember, with every signature, which one-time key was used. Signing two messages with the same one-time key could let an attacker forge signatures, so the signer must guarantee that a key is used only once[Ref. 24]. SP 800-208 says that because this state management is difficult these schemes are not for general use and are mainly intended for uses such as signing firmware updates, where code is hard to change once devices are deployed[Ref. 24]. SLH-DSA stacks the tree in layers and chooses a key at random each time so that no state has to be remembered, at the price of larger signatures[Ref. 23].

Other families: codes, isogenies and multivariate schemes

In NIST's selection, besides ML-KEM, ML-DSA and SLH-DSA, the signature scheme Falcon and the key-establishment scheme HQC were chosen for standardisation. HQC was selected on 11 March 2025, and the rationale is in NIST IR 8545[Ref. 19, 26]. As of the checking date (16 October 2026), NIST's selection page shows "FIPS coming soon" for both Falcon and HQC, so they are not yet standards[Ref. 20].

7. Where the NIST standards stand (checked 16 October 2026)

After an international call that ran for several years, NIST published its first three PQC standards (FIPS 203, 204, 205) on 13 August 2024[Ref. 19]. NIST says these three should provide the foundation for most PQC deployments and "can and should be put into use now"[Ref. 19].

Sourced / Not yet confirmed. Sizes are from the tables of FIPS 203, 204 and 205. Even a "final" standard can have corrections scheduled.

FIPS 203 claims that ML-KEM-512, 768 and 1024 fall into the security strength categories 1, 3 and 5 defined by NIST. Instead of a single number such as "128 bits", strength is expressed as "at least as hard as a key search against AES of a given key length, or finding collisions in a hash function"[Ref. 21]. And NIST recommends ML-KEM-768 as the default parameter set, since it provides a large security margin at a reasonable performance cost[Ref. 21].

8. Larger keys and signatures

One big difference with PQC is that keys, signatures and ciphertexts are larger. The next figure sets the values from the FIPS tables beside the sizes of classical schemes (Ed25519, X25519, RSA-2048).

Our calculation. Numerators are values from the FIPS tables; denominators are X25519 = 32 bytes, an Ed25519 signature = 64 bytes and an RSA-2048 signature = 256 bytes (RFC 7748, RFC 8032, 2048 bits = 256 bytes)[Ref. 38].

The difference in size affects traffic, memory and processing time. A change from some hundreds of bytes to some kilobytes per key exchange is small for PCs and servers, but can require a redesign for devices with narrow bandwidth, embedded devices with little memory, and protocols that assume one message fits in a small packet (our commentary).

9. The hybrid approach

The new "hard problems" have a short history, and a new way of solving them may be found in the future. So the hybrid approach runs both a classical scheme and PQC and mixes the two shared secrets into one key. IETF RFC 9954 explains hybrid key exchange as using several key-exchange algorithms simultaneously and combining the results, aiming to stay secure "even if a way is found to defeat the encryption for all but one of the component algorithms"[Ref. 34].

In August 2026 the IETF defined, in RFC 10024 (a Standards Track document), three hybrid key agreements for TLS 1.3 (X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024)[Ref. 33]. According to RFC 10024, X25519MLKEM768 is widely deployed and often the most practical choice for TLS 1.3. The client's value is 1,216 bytes, the server's reply 1,120 bytes and the shared secret 64 bytes[Ref. 33]. The general construction behind it is set out in RFC 9954 (July 2026, informational), and the terminology in RFC 9794 (June 2025, informational)[Ref. 34, 35].

PQC standardisation is also moving in other settings. For X.509 certificates, ML-DSA is in RFC 9881 (October 2025), ML-KEM in RFC 9935 (March 2026) and SLH-DSA in RFC 9909 (December 2025), and OpenPGP is in RFC 9980 (June 2026), all Standards Track documents[Ref. 36, 37]. Pure ML-KEM for TLS (not hybrid) was, in the IETF datatracker as of 12 October 2026, in the RFC Editor queue (we confirmed this from the datatracker display).

ETSI technical specification TS 103 744 (V1.2.2, February 2026), "Quantum-safe Hybrid Key Establishment", specifies how to derive keys from several shared secrets obtained from ECDH and a post-quantum key-encapsulation mechanism[Ref. 32]. NIST also explains in its FAQ that hybrid key establishment in a FIPS 140 approved mode can be done with the generic composition technique of SP 800-56C (updated 18 November 2024)[Ref. 28].

10. Implementation cautions and lessons from broken schemes

For PQC it is not enough that "the mathematics is safe". There are two lessons.

• Lesson 1: the "hardness" of mathematics is confirmed over time. In 2022 two candidates in the standardisation process were broken by attacks on ordinary computers. The scheme based on supersingular isogenies (SIDH/SIKE) fell to the attack of Castryck and Decru[Ref. 29], and the multivariate scheme Rainbow fell to an attack by Beullens that is reported to have broken a key on a laptop over a weekend[Ref. 30]. It is an example of the open examination of standardisation (call and evaluation) finding problems before the scheme became a standard (our commentary). It is no guarantee that ML-KEM, ML-DSA and SLH-DSA will stay safe in the future.
• Lesson 2: implementations can have holes. KyberSlash is a paper reporting that several software implementations of Kyber (the scheme from which ML-KEM derives), including the official reference code, had a weakness in which the time taken by a division depends on secret values. The paper explains the cause as the code being meant to run in constant time at source level while compilers can emit division instructions whose duration varies, and states that after responsible disclosure the affected libraries were patched[Ref. 31]. It is a hole in implementation, not in mathematics, a lesson of the same kind as the device holes of QKD in the previous article (our commentary; the procedure of the attack is not covered here).

11. How to read evaluations and standards

The progress of PQC is measured by (1) whether it is a standard (number and status), (2) the security strength category (NIST's 1, 3 and 5), (3) how much open scrutiny it has received (years, and examples of schemes that were broken), (4) checks on implementations (cryptographic module validation, inspection for implementation holes) and (5) size and speed. Checked 16 October 2026.

The organisation of the table is Our calculation (arrangement). Numbers and status checked on the official NIST, IETF and ETSI pages (checked 16 October 2026).

Cautions in reading (for materials engineers)

• Check which algorithm "PQC-ready" means: what became a standard in FIPS 203, 204 and 205 differs in status from what is only selected (Falcon, HQC). If a product says "PQC-ready", check which standard, which parameter set and in which protocol.
• Even a "final" standard can have corrections coming: FIPS 203 and 204 point to matters to be corrected in future revisions[Ref. 21, 22]. It helps to appoint someone to follow updates to the standards (our commentary).
• Do not compare on the size of a number alone: "smaller signature" or "faster" must be compared with the security strength category and the way of use (stateful or stateless, number of signatures) aligned.
• Check whether an RFC is Standards Track or informational: RFC 10024 is Standards Track, while RFC 9954 and 9794 are informational[Ref. 33, 34, 35].

12. Glossary

13. References (primary sources)

1. Diffie W., Hellman M. "New directions in cryptography", IEEE Trans. Inf. Theory 22, 644–654 (1976), DOI 10.1109/TIT.1976.1055638 — doi.org/10.1109/TIT.1976.1055638
2. Rivest R. L., Shamir A., Adleman L. "A method for obtaining digital signatures and public-key cryptosystems", Commun. ACM 21, 120–126 (1978), DOI 10.1145/359340.359342 — doi.org/10.1145/359340.359342
3. Wootters W. K., Zurek W. H. "A single quantum cannot be cloned", Nature 299, 802–803 (1982), DOI 10.1038/299802a0 — doi.org/10.1038/299802a0
4. Koblitz N. "Elliptic curve cryptosystems", Math. Comp. 48, 203–209 (1987), DOI 10.1090/S0025-5718-1987-0866109-5 — doi.org/10.1090/S0025-5718-1987-0866109-5
5. Boudot F., Gaudry P., Guillevic A., Heninger N., Thomé E., Zimmermann P. "Comparing the Difficulty of Factorization and Discrete Logarithm: A 240-Digit Experiment", CRYPTO 2020, LNCS 12171, 62–91 (2020), DOI 10.1007/978-3-030-56880-1_3 (ePrint 2020/697) — eprint.iacr.org/2020/697
6. Shor P. W. "Algorithms for quantum computation: discrete logarithms and factoring", Proc. 35th Annual Symposium on Foundations of Computer Science, 124–134 (1994), DOI 10.1109/SFCS.1994.365700 — doi.org/10.1109/SFCS.1994.365700
7. Shor P. W. "Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer", SIAM J. Comput. 26, 1484–1509 (1997), DOI 10.1137/S0097539795293172 — doi.org/10.1137/S0097539795293172
8. Grover L. K. "A fast quantum mechanical algorithm for database search", Proc. 28th ACM Symposium on Theory of Computing (STOC '96), 212–219 (1996), DOI 10.1145/237814.237866 — doi.org/10.1145/237814.237866
9. Chen L., Jordan S., Liu Y.-K., Moody D., Peralta R., Perlner R., Smith-Tone D. "Report on Post-Quantum Cryptography", NIST IR 8105 (2016), DOI 10.6028/NIST.IR.8105 — doi.org/10.6028/NIST.IR.8105
10. Gidney C., Ekerå M. "How to factor 2048 bit RSA integers in 8 hours using 20 million noisy qubits", Quantum 5, 433 (2021), DOI 10.22331/q-2021-04-15-433 — doi.org/10.22331/q-2021-04-15-433
11. Gidney C. "How to factor 2048 bit RSA integers with less than a million noisy qubits", arXiv:2505.15917 (2025) — arxiv.org/abs/2505.15917
12. Mosca M., Piani M. (Global Risk Institute and evolutionQ) "Quantum Threat Timeline Report 2025" (published 9 March 2026; survey of 26 experts) — globalriskinstitute.org/publication/quantum-threat-timeline-report-2025b/
13. Regev O. "On lattices, learning with errors, random linear codes, and cryptography", J. ACM 56 (6), article 34 (2009), DOI 10.1145/1568318.1568324 — doi.org/10.1145/1568318.1568324
14. Langlois A., Stehlé D. "Worst-case to average-case reductions for module lattices", Des. Codes Cryptogr. 75, 565–599 (2015), DOI 10.1007/s10623-014-9938-4 — doi.org/10.1007/s10623-014-9938-4
15. Peikert C. "A Decade of Lattice Cryptography", Found. Trends Theor. Comput. Sci. 10, 283–424 (2016), DOI 10.1561/0400000074 — doi.org/10.1561/0400000074
16. Bos J. et al. "CRYSTALS - Kyber: A CCA-Secure Module-Lattice-Based KEM", 2018 IEEE European Symposium on Security and Privacy, 353–367 (2018), DOI 10.1109/EuroSP.2018.00032 — doi.org/10.1109/EuroSP.2018.00032
17. Ducas L. et al. "CRYSTALS-Dilithium: A Lattice-Based Digital Signature Scheme", IACR TCHES 2018 (1), 238–268, DOI 10.46586/tches.v2018.i1.238-268 — doi.org/10.46586/tches.v2018.i1.238-268
18. Bernstein D. J., Hülsing A., Kölbl S., Niederhagen R., Rijneveld J., Schwabe P. "The SPHINCS+ Signature Framework", Proc. 2019 ACM SIGSAC Conference on Computer and Communications Security, 2129–2146 (2019), DOI 10.1145/3319535.3363229 — doi.org/10.1145/3319535.3363229
19. NIST "Post-Quantum Cryptography" project page, CSRC (checked 16 October 2026) — csrc.nist.gov/projects/post-quantum-cryptography
20. NIST "Selected Algorithms" page of the PQC standardization process (shows HQC (2025) and FALCON (2022) as "FIPS coming soon"; checked 16 October 2026) — csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-stand
21. NIST FIPS 203 "Module-Lattice-Based Key-Encapsulation Mechanism Standard" (published 13 August 2024), DOI 10.6028/NIST.FIPS.203 — csrc.nist.gov/pubs/fips/203/final
22. NIST FIPS 204 "Module-Lattice-Based Digital Signature Standard" (published 13 August 2024), DOI 10.6028/NIST.FIPS.204 — csrc.nist.gov/pubs/fips/204/final
23. NIST FIPS 205 "Stateless Hash-Based Digital Signature Standard" (published 13 August 2024), DOI 10.6028/NIST.FIPS.205 — csrc.nist.gov/pubs/fips/205/final
24. NIST SP 800-208 "Recommendation for Stateful Hash-Based Signature Schemes" (October 2020), DOI 10.6028/NIST.SP.800-208 — csrc.nist.gov/pubs/sp/800/208/final
25. NIST SP 800-227 "Recommendations for Key-Encapsulation Mechanisms" (September 2025), DOI 10.6028/NIST.SP.800-227 — csrc.nist.gov/pubs/sp/800/227/final
26. NIST NIST IR 8545 "Status Report on the Fourth Round of the NIST Post-Quantum Cryptography Standardization Process" (March 2025), DOI 10.6028/NIST.IR.8545 — csrc.nist.gov/pubs/ir/8545/final
27. NIST NIST IR 8547 (Initial Public Draft) "Transition to Post-Quantum Cryptography Standards" (12 November 2024; comment period closed 10 January 2025; no final version found at the checking date) — csrc.nist.gov/pubs/ir/8547/ipd
28. NIST PQC FAQs, CSRC (including the answer on hybrid key establishment in a FIPS 140 approved mode, updated 18 November 2024; checked 16 October 2026) — csrc.nist.gov/projects/post-quantum-cryptography/faqs
29. Castryck W., Decru T. "An Efficient Key Recovery Attack on SIDH", EUROCRYPT 2023, LNCS 14008, 423–447 (2023), DOI 10.1007/978-3-031-30589-4_15 — doi.org/10.1007/978-3-031-30589-4_15
30. Beullens W. "Breaking Rainbow Takes a Weekend on a Laptop", CRYPTO 2022, LNCS 13508, 464–479 (2022), DOI 10.1007/978-3-031-15979-4_16 — doi.org/10.1007/978-3-031-15979-4_16
31. Bernstein D. J. et al. "KyberSlash: Exploiting secret-dependent division timings in Kyber implementations", IACR TCHES 2025 (2), 209–234, DOI 10.46586/tches.v2025.i2.209-234 — tches.iacr.org/index.php/TCHES/article/view/12046
32. ETSI TS 103 744 V1.2.2 (2026-02) "CYBER; Quantum-Safe Cryptography (QSC); Quantum-safe Hybrid Key Establishment" — etsi.org/deliver/etsi_ts/103700_103799/103744/01.02.02_60/ts_103744v010202p.pdf
33. Kwiatkowski K., Kampanakis P., Westerbaan B. E., Stebila D. (IETF) RFC 10024 "Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3" (Standards Track, August 2026) — rfc-editor.org/rfc/rfc10024.html
34. Stebila D., Fluhrer S., Gueron S. (IETF) RFC 9954 "Hybrid Key Exchange in TLS 1.3" (Informational, July 2026) — rfc-editor.org/rfc/rfc9954.html
35. Driscoll F., Parsons M., Hale B. (IETF) RFC 9794 "Terminology for Post-Quantum Traditional Hybrid Schemes" (Informational, June 2025) — rfc-editor.org/rfc/rfc9794.html
36. IETF (LAMPS) RFC 9881 "Internet X.509 Public Key Infrastructure -- Algorithm Identifiers for the Module-Lattice-Based Digital Signature Algorithm (ML-DSA)" (Standards Track, October 2025); see also RFC 9935 (ML-KEM, March 2026) and RFC 9909 (SLH-DSA, December 2025) — rfc-editor.org/rfc/rfc9881.html
37. IETF (OpenPGP) RFC 9980 "Post-Quantum Cryptography in OpenPGP" (Standards Track, June 2026) — rfc-editor.org/rfc/rfc9980.html
38. Josefsson S., Liusvaara I. (IETF) RFC 8032 "Edwards-Curve Digital Signature Algorithm (EdDSA)" (2017); RFC 7748 "Elliptic Curves for Security" (X25519; 2016) — rfc-editor.org/rfc/rfc8032.html

14. Claim-to-source audit

Last updated: 16 October 2026. Sources are limited to primary material (peer-reviewed and conference papers, NIST standards, reports and official pages, IETF RFCs and the datatracker, an ETSI technical specification and a Global Risk Institute report). Numbers, status and dates for NIST, IETF and ETSI are as of the checking date and may change with revisions. The small-number examples are our own calculations, not real keys. We do not state the contents of the Falcon (FN-DSA) and HQC standards, a final version of NIST IR 8547, the number of validations, or "when quantum computers will break cryptography", because these could not be confirmed or cannot be asserted. All figures are explanatory concept diagrams or charts including our calculation; Figure 1 is an ImageGen-generated conceptual illustration. This article is neither legal nor investment advice, and not an explanation of how to break cryptography.