The short version
Public-key cryptography that protects most of the internet today — RSA, finite-field Diffie–Hellman and elliptic-curve schemes — falls to Shor’s algorithm on a sufficiently large, fault-tolerant quantum computer. Such a machine does not exist yet. But an adversary does not need one today: they only need to record encrypted traffic now and wait. That is the “harvest now, decrypt later” threat, and it turns a hardware question into a planning question.
The one inequality that matters
Michele Mosca framed the planning problem simply. Let X be the number of years your data must remain confidential, Y the number of years your organisation will take to migrate, and Z the number of years until a cryptographically relevant quantum computer exists.
If X + Y > Z, data you encrypt today is already at risk.
Nobody knows Z. But X is often long — student records, medical records and institutional archives routinely carry retention horizons of decades — and Y is rarely short, because cryptography is embedded in protocols, devices, certificates and vendor products. Uncertainty about Z argues for starting the migration, not for waiting.
What changes, and what does not
- Public-key exchange and signatures are the exposed part. Shor’s algorithm breaks RSA, Diffie–Hellman and elliptic-curve cryptography outright; larger keys do not rescue them.
- Symmetric cryptography needs a margin, not a replacement. Grover’s algorithm gives a quadratic speed-up in exhaustive key search, roughly halving effective key strength. AES-256 and SHA-384 or stronger are the conservative choices.
What has been standardised
In August 2024, NIST published the first three post-quantum standards:
- FIPS 203 — ML-KEM (from CRYSTALS-Kyber), a lattice-based key-encapsulation mechanism for establishing shared secrets.
- FIPS 204 — ML-DSA (from CRYSTALS-Dilithium), a lattice-based digital signature scheme.
- FIPS 205 — SLH-DSA (from SPHINCS+), a stateless hash-based signature scheme with conservative security assumptions.
Further algorithms, including the Falcon-based FN-DSA, are in the standardisation pipeline. NIST’s draft transition guidance (IR 8547) proposes deprecating quantum-vulnerable public-key algorithms by 2030 and disallowing them by 2035; as a draft, its status should be checked against the current publication before you commit a plan to it.
The cost is real but manageable
Post-quantum keys and signatures are larger than the ones they replace, and that has engineering consequences.
- An X25519 public key is 32 bytes; an ML-KEM-768 public key is 1,184 bytes and its ciphertext 1,088 bytes.
- An ECDSA P-256 signature is about 64 bytes; an ML-DSA-65 signature is 3,309 bytes and its public key 1,952 bytes.
Larger handshakes, certificate chains and tokens can hit protocol size limits, middlebox assumptions, constrained devices and HSM support. These are testable problems, which is exactly why they should be found in a pilot rather than in production.
Two priorities that follow
Protect key establishment first. Harvest-now-decrypt-later attacks target confidentiality, which is decided at key exchange. Signatures only need to resist forgery at the time they are checked, so authentication and PKI migration can follow. Deploy in hybrid mode. Combining a classical exchange with ML-KEM — as in the X25519MLKEM768 groups already enabled by default in major browsers and CDNs — means the session stays secure if either component holds. It is the pragmatic hedge while confidence in the new algorithms accumulates.
A staged plan for an institution
- Inventory. Build a cryptographic bill of materials: every protocol, library, certificate, key store and vendor dependency that uses public-key cryptography, and where.
- Classify by data lifetime. For each system, estimate X honestly, then rank by exposure: long-retention records over a network or in backup come first.
- Make it agile. Remove hard-coded algorithms; route cryptographic choices through configuration and a small number of well-tested libraries, so the next change is not another migration project.
- Pilot hybrid key exchange on the highest-risk paths — external TLS, VPNs, and storage and backup channels — and measure latency, size and compatibility on your real workloads.
- Plan the signature and PKI transition separately, with vendor roadmaps and your certificate lifecycles in view.
- Verify and monitor. Test against published known-answer vectors, check interoperability, and track the standards and your vendors’ support as they evolve.
Where Five Angstrom fits
We are a research group, so we approach this as an engineering and measurement problem: assess where long-lived data is exposed, design the migration path, build reference implementations for the highest-risk channels, and measure the result. Our Quantum Security page describes the engagement in more detail.