How Post-Quantum Cryptography Algorithms Work: A Practitioner Technical Guide

Why RSA and ECC cannot be patched for the quantum era

RSA-2048's security rests on the Integer Factorisation Problem (IFP): the classical computational cost of factoring the product of two large primes is sub-exponential, which places it beyond practical attack on any classical hardware. Shor's algorithm solves IFP in polynomial time, specifically O((log N)³), on a fault-tolerant quantum computer of sufficient scale. ECC and Diffie-Hellman fall for the same reason applied to a different structure: both rely on the Discrete Logarithm Problem (DLP), which Shor also solves in polynomial time. Polynomial time versus sub-exponential time is not a marginal advantage; it is the difference between a problem class that remains computationally secure at any key size and one that does not.

Doubling the RSA key from 2,048 to 4,096 bits does not change the problem class. Shor's algorithm solves both with identical O((log N)³) complexity. That is why the migration is to entirely different mathematical foundations, not to larger parameters on the same ones. The full mechanics of how Shor produces this speedup, and the hardware requirements that still stand between current quantum systems and cryptographic relevance, are in the companion article on quantum algorithms and applications. This article starts from the point where the threat is understood and addresses the technical response. For the broader picture of what the quantum computing transition means for your security programme, see our quantum computing and cybersecurity guide.

Three mathematical approaches to quantum-resistant cryptography

Three post-quantum cryptographic standards were finalised by NIST in August 2024. FIPS 203 defines ML-KEM (Module Lattice-based Key Encapsulation Mechanism) for key exchange. FIPS 204 defines ML-DSA (Module Lattice-based Digital Signature Algorithm). FIPS 205 defines SLH-DSA (Stateless Hash-based Digital Signature Algorithm) as a hash-based alternative. A fourth standard, FIPS 206 covering FN-DSA (Falcon-based signatures), was submitted for NIST approval in August 2025 and remains in draft as of July 2026, with final publication expected no earlier than late 2026 or early 2027. FIPS 206 is not one of the August 2024 trio. For the regulatory framing and what these standards require from covered entities, see our NIST FIPS 203, 204, and 205 implementation guide.

Lattice-based: ML-KEM and ML-DSA. Both algorithms rest on the Module Learning With Errors (MLWE) hardness assumption. The problem: given a public matrix A, a secret vector s, and a noise vector e, compute b = As + e. An adversary who receives A and b must recover s. The noise term e is small, but recovering s exactly is computationally infeasible, and no efficient quantum algorithm for MLWE is known. The "module" structure organises this over polynomial rings, reducing key and ciphertext sizes relative to basic LWE while preserving the hardness guarantee. NIST selected the CRYSTALS family on performance, a sustained period of open cryptanalysis that produced no efficient attack, and broad parameter coverage across security levels one through five. The algorithms are designated ML-KEM and ML-DSA in the FIPS standards, not Kyber and Dilithium, which are the submission names. Implementations built against the Kyber submission specification are not automatically FIPS 203-compliant. For a full account of what changed at standardisation, see our piece on ML-KEM versus Kyber.

Hash-based: SLH-DSA. The security of SLH-DSA (FIPS 205) rests on the one-wayness of hash functions (SHA-256, SHA-512, and SHAKE variants), not on algebraic hardness assumptions. If the SHA-2 and SHA-3 families remain secure, SLH-DSA is secure, regardless of any future advance in lattice cryptanalysis. NIST selected hash-based signatures to ensure the portfolio is not entirely dependent on one mathematical bet. The cost is signature size: 7,856 bytes at the smallest parameter set, up to 49,856 bytes at the largest.

Code-based: Classic McEliece. NIST selected Classic McEliece as an alternative KEM based on the hardness of decoding general linear codes. Public keys run from approximately 261 kilobytes to over one megabyte, which makes it impractical for general enterprise TLS. It is deployed in specialised contexts where those transmission costs are acceptable. For most enterprise and government use cases, ML-KEM is the KEM of record.

Algorithm selection: ML-KEM, ML-DSA, and SLH-DSA in practice

ML-KEM for key exchange and key encapsulation. ML-KEM replaces ECDHE in TLS, RSA key transport in email, and any asymmetric key exchange in the current stack. Deploy ML-KEM-768 as the default: security level 3, approximately AES-192 equivalent, 1,184-byte public key and 1,088-byte ciphertext. Where CNSA 2.0 compliance applies for national security systems, ML-KEM-1024 is required: security level 5, approximately AES-256 equivalent, 1,568-byte public key. An X25519 public key is 32 bytes. The increase matters for TLS handshake sizes on high-volume endpoints; computation time is not the bottleneck.

ML-DSA for digital signatures. Code signing, certificate signing, email signing, and API authentication tokens all map to ML-DSA. ML-DSA-65 (security level 3, 3,309-byte signatures) is the general enterprise default; ML-DSA-87 (security level 5, 4,627-byte signatures) applies where CNSA 2.0 compliance requires it. An ECDSA P-256 signature is approximately 64 bytes. A code signing pipeline that signs thousands of builds per day accumulates this overhead in repository storage, and certificate authorities issuing at volume will see larger TLS handshake sizes as certificate chains grow. Plan for the size increase; it is not a drop-in replacement.

SLH-DSA for long-lived keys and assumption diversity. Root certificate signing, long-term archival signing, and contexts where a future lattice cryptanalysis break would be catastrophic are SLH-DSA's use cases. Do not deploy it in a high-frequency signing pipeline: signature sizes exceed 49 kilobytes at higher security parameters, and signing is substantially slower than ML-DSA. LMS and XMSS (NIST SP 800-208, October 2020) cover the stateful alternatives for tightly bounded signing contexts such as firmware update systems, where a single key signs a controlled number of messages. For all other signature needs, SLH-DSA's stateless operation is the correct choice.

The comparison below positions these algorithms against the key practitioner dimensions: NIST standard, security level, public key size, and signature or ciphertext size. The size column in particular makes the operational trade-offs legible in a way that prose cannot compress further.

QSECDEF's NIST PQC algorithm selector maps these algorithm choices to use cases and security requirements, including CNSA 2.0 classification and HNDL exposure tier, for practitioners working through the selection matrix for their specific systems.

Session 4 of the QSECDEF Summer Bootcamp covers PQC algorithm selection, hybrid deployment, and migration sequencing with practitioner input. Register to attend live or access the recording →

Hybrid deployment: running classical and post-quantum algorithms together

Hybrid deployment runs classical and post-quantum algorithms simultaneously during the transition period. In TLS 1.3, this means negotiating both an ECDHE key exchange and an ML-KEM encapsulation, then deriving the session key from both outputs via a key derivation function. An attacker must break both algorithms to compromise the session. Deploying PQC alone eliminates the 40-year body of adversarial scrutiny behind RSA and ECC; deploying classical alone leaves data exposed to harvest-now-decrypt-later collection. Hybrid is the responsible intermediate state, not a permanent one.

The IETF has defined three hybrid key exchange constructions for TLS 1.3 in draft-ietf-tls-ecdhe-mlkem (in the RFC Editor queue as of July 2026, not yet published as RFC): X25519MLKEM768 (ML-KEM-768 with X25519, recommended, IANA Y-status); SecP256r1MLKEM768 (ML-KEM-768 with P-256); and SecP384r1MLKEM1024 (ML-KEM-1024 with P-384, the high-security pairing for CNSA 2.0 contexts). The high-security partner for ML-KEM-1024 is P-384, not X448. Older informal references describe X448 as the natural counterpart; it is not defined in the current IETF specification.

X-Wing (draft-connolly-cfrg-xwing-kem, version 10, March 2026) uses ML-KEM-768 and X25519 as a standalone general-purpose KEM submitted to the CFRG independent submission stream, not as a TLS-specific construction. No RFC number has been assigned. X-Wing and X25519MLKEM768 share the same component algorithms but use different constructions and serve different specifications; they are not interchangeable.

SIKE's failure makes the structural argument. Supersingular Isogeny Key Encapsulation survived multiple rounds of NIST evaluation until Castryck and Decru's 2022 attack broke it with a classical algorithm running in hours on a single laptop. The attack came from a direction the cryptanalytic community had not anticipated before the evaluation closed. Had hybrid mode been deployed alongside SIKE, classical security would have held regardless. The case for hybrid is not that MLWE is expected to break; it is that the gap between "withstood multi-year peer review" and "40 years of adversarial scrutiny" is real, and hybrid covers it at modest cost.

ML-KEM-768 key generation runs in approximately 15 microseconds and encapsulation in approximately 19 microseconds on current server-class hardware. The handshake overhead is in transmission of larger key material, not computation. Hybrid does require two key pairs, two key exchanges per TLS negotiation, and certificate chains that carry both key types. These are infrastructure management costs that belong in the initial project scope.

The migration sequence: why it takes longer than any vendor estimate

Cryptographic inventory is the first step in every migration programme and the one most consistently underestimated. Automated tooling (CBOM scanners, software composition analysis tools, network protocol analysers) maps code-level dependencies. It does not find vendor SDKs calling cloud key management APIs that use RSA internally, HSM firmware configurations, legacy IAM systems with embedded certificate chains, or SaaS platforms where the organisation does not control the encryption layer. In every PQC migration project I have worked on, the first automated scan identifies roughly half the cryptographic attack surface. The remainder surfaces through vendor questionnaires, architectural reviews, and penetration testing, and the full inventory takes six to twelve months at enterprise scale before a single algorithm changes.

The migration sequence follows six steps: cryptographic inventory; prioritisation by data sensitivity and HNDL exposure (long-lived data first); vendor assessment for PQC roadmap alignment; hybrid deployment for highest-risk systems; validation and testing for performance, interoperability, and certificate chain compatibility; and full PQC cutover per system with rollback capability. A large enterprise programme typically spans three to five years from inventory start to completion.

Two regulatory frameworks set hard outer boundaries. NSA CNSA 2.0 (September 2022) specifies transition deadlines by system class: software and firmware signing exclusive CNSA 2.0 use by 2030, network equipment by 2030, operating systems and cloud services by 2033. Executive Order 14412, signed by President Trump on 22 June 2026, adds binding federal deadlines: all US federal High Value Assets and High Impact Systems must complete PQC transition for key establishment by 31 December 2030, and for digital signatures by 31 December 2031. These are completion dates, not start dates. Any organisation that has not begun its cryptographic inventory is already compressing a programme that reliably takes longer than planned.

Tooling, gap categories, and what automated scanners miss at each inventory step are in the cryptographic inventory guide. The PQC risk assessment tool supports Step 2 prioritisation.

Session 4 of the QSECDEF Summer Bootcamp covers this curriculum in depth. Not as a standards review, but as a practitioner's guide to what these algorithms mean for deployment decisions and your migration sequence. QSECDEF members receive the CQBP (Certified Quantum Business Professional) credential on completing all ten sessions. Register for the Summer Bootcamp →