Post-quantum cryptography: what changes and when
Quantum computers threaten RSA and elliptic curves, not AES. NIST's new standards, harvest now decrypt later, hybrid key exchange in browsers, and a plan for platforms.
On this page 8 sections
Post-quantum cryptography (PQC) is public-key cryptography designed to stay secure against large quantum computers, which could one day break RSA, elliptic-curve cryptography and Diffie-Hellman. NIST published the first standards in August 2024, ML-KEM for key exchange and ML-DSA and SLH-DSA for signatures, and current browsers already use a hybrid of X25519 and ML-KEM by default wherever servers support it. Symmetric encryption such as AES is largely unaffected, so for most platforms the job is to upgrade key exchange now and signatures over the coming years.
What a quantum computer threatens
Today's public-key (asymmetric) cryptography rests on two maths problems: factoring huge numbers (RSA) and discrete logarithms (Diffie-Hellman and elliptic curves). Classical computers can't solve them at real key sizes. A large, error-corrected quantum computer running Shor's algorithm could solve both efficiently.
No such machine exists yet, and nobody knows when one will. Estimates of the effort needed keep falling, though. In May 2025, a Google researcher published an estimate that a 2,048-bit RSA key could be factored in under a week by a quantum computer with fewer than a million noisy qubits, against a 2019 estimate of 20 million. That is still far beyond the machines built so far. An Indian government task force, reporting in February 2026, called the timeline uncertain and noted research estimates clustering around 2030 to 2032.
| Algorithm | What it does | Quantum impact | What to do |
|---|---|---|---|
| RSA | Signatures, older key exchange | Broken by Shor's algorithm | Plan to replace |
| ECDH, X25519 | Key exchange in TLS, SSH, messaging | Broken by Shor's algorithm | Move to hybrid ML-KEM now |
| ECDSA, Ed25519 | Signatures, certificates, app signing | Broken by Shor's algorithm | Plan for ML-DSA or SLH-DSA |
| AES-128, AES-256 | Encrypting data | Weakened only modestly | Keep; prefer AES-256 for long-lived data |
| SHA-256, HMAC | Hashing, integrity, webhooks | Weakened only modestly | Keep |
For how RSA and elliptic curves work in the first place, see our guides to RSA and ECC vs RSA.
Why AES survives
The main quantum attack on symmetric ciphers, Grover's algorithm, speeds up brute-force search, but only quadratically, and it doesn't parallelise well. In practice that leaves AES with a comfortable margin. NIST's draft transition report, NIST IR 8547, says approved symmetric algorithms with at least 128 bits of classical security are believed to meet the lowest of its post-quantum security categories, and it keeps AES-128, AES-192 and AES-256 approved. AES-256 simply adds margin. Our article on whether AES-128 is still secure works through the numbers.
So the video files, databases and backups you encrypt with AES are not the problem. The problem is how the AES keys get from one place to another, and how software proves who signed what.
The new NIST standards
| Standard | Algorithm | Job | Notes |
|---|---|---|---|
| FIPS 203 | ML-KEM (from CRYSTALS-Kyber) | Key establishment | Lattice-based; the one browsers use |
| FIPS 204 | ML-DSA (from CRYSTALS-Dilithium) | Digital signatures | Lattice-based general-purpose signatures |
| FIPS 205 | SLH-DSA (from SPHINCS+) | Digital signatures | Hash-based; conservative, with larger signatures |
| Draft FIPS 206 | FN-DSA (from Falcon) | Digital signatures | Compact signatures; still being finalised |
| Planned | HQC | Key establishment | Selected in March 2025 as a backup to ML-KEM, built on different maths |
NIST published FIPS 203, 204 and 205 on 13 August 2024 and urged organisations to start integrating them immediately. The new algorithms are bigger than the ones they replace. An ML-KEM-768 public key is 1,184 bytes against 32 for X25519, and an ML-DSA-44 signature is 2,420 bytes against 64 for Ed25519. That size, not speed, is the main engineering cost.
NIST's draft IR 8547 also proposes a deadline: quantum-vulnerable algorithms at the 112-bit security level would be deprecated after 2030, and all of them disallowed after 2035.
Harvest now, decrypt later
An attacker doesn't need a quantum computer today to benefit from one later. They can record encrypted traffic now and keep it until they can break the key exchange that protected it. Anything that must stay secret for years is already at risk, which is why key exchange is being upgraded first.
Not all data has the same shelf life. A worked triage for an education platform, with illustrative judgements:
| Data | How long must it stay secret? | Harvest-now risk |
|---|---|---|
| Student identity documents, addresses, parents' details | Many years | High: move its traffic and backups to quantum-safe protection first |
| Test results and academic records | Years | Medium to high |
| Payment records | Years, depending on law and policy | Medium |
| Paid course content for a current batch | Months; the content goes out of date | Lower, though still worth protecting |
| Login sessions and one-time passwords | Minutes to days | Low |
Hybrid key exchange in browsers today
The web didn't wait. Browsers now run a classical exchange and a post-quantum one side by side and combine the results, so a connection stays safe as long as either algorithm holds. The standard combination, X25519MLKEM768, was published for TLS 1.3 in RFC 10024 in August 2026, and it is on by default in current versions of Chrome, Edge, Firefox and Safari, in Apple's 2025 operating systems, and in OpenSSL from version 3.5.
Two consequences for developers:
- It needs TLS 1.3. The IETF has said post-quantum cryptography will never be specified for TLS 1.2; our comparison of TLS 1.2 vs 1.3 explains the freeze.
- Handshakes get bigger. The client's key share grows from 32 bytes to 1,216, so an old firewall, proxy or load balancer that mishandles large handshake messages can break connections. Test yours.
Messaging moved early too: Signal added post-quantum protection in 2023, and Apple's iMessage announced its PQ3 protocol in February 2024. Our guide to Diffie-Hellman key exchange explains what ML-KEM replaces.
What an education platform should do now
India now has a national reference point. The Department of Science and Technology published a task-force report, Implementation of Quantum Safe Ecosystem in India, in February 2026. It proposes that ordinary enterprises lay foundations by 2028, migrate high-priority systems by 2030 and complete adoption by 2033, with critical sectors such as power and telecom moving faster. For an institute or ed-tech platform, a sensible order is:
- Turn on hybrid key exchange where your TLS ends. That is usually a CDN, cloud load balancer or nginx. Check that it offers X25519MLKEM768; for nginx, that means building with OpenSSL 3.5 or later.
- Check your apps and partners. Find out which TLS library your Android and iOS apps use, and ask your cloud provider, CDN, payment gateway and SMS provider about their post-quantum plans.
- Make an inventory. List where you use RSA and elliptic curves: TLS certificates, JWT signing keys, app-signing keys, SSH, VPNs, encrypted backups, partner APIs. The DST report calls this a cryptographic bill of materials.
- Build in crypto agility. Keep algorithm choices in configuration and libraries, not hard-coded, so swapping them later is a release, not a rewrite.
- Keep AES, and prefer AES-256 for long-lived data such as archives and backups, with keys held in a proper key service; see our guide to encryption key management.
- Don't rush post-quantum certificates. Signatures matter less for harvest-now attacks, and post-quantum certificates for the public web are still being worked out. Watch your certificate authority and platforms, and plan app-signing and document-signing changes for when support arrives.
- Don't invent your own. Use standard, widely deployed implementations. Home-made post-quantum code is riskier than none.
Key takeaways
- Quantum computers threaten public-key algorithms (RSA, elliptic curves, Diffie-Hellman), not AES.
- NIST's first standards are ML-KEM for key exchange and ML-DSA and SLH-DSA for signatures.
- Harvest now, decrypt later makes key exchange urgent for anything that must stay secret for years.
- Hybrid X25519MLKEM768 is already the default in major browsers and needs TLS 1.3 on your side.
- Start with your TLS edge and an inventory; move signatures as the ecosystem catches up.
Frequently asked questions
Can quantum computers break encryption?
A large, error-corrected quantum computer could break today's public-key encryption and key exchange, such as RSA, Diffie-Hellman and elliptic curves, using Shor's algorithm. It would not meaningfully break symmetric encryption such as AES. No machine capable of this exists yet, but recorded traffic could be decrypted later, which is why browsers and messaging apps are already adding post-quantum key exchange such as ML-KEM.
Can quantum computers break AES 256?
No, not in any practical sense. The best known quantum attack on AES, Grover's algorithm, only speeds up brute-force search quadratically, and it is hard to run at scale. AES-256 keeps a very large margin, and NIST continues to approve AES at every key size. The real quantum risk is to how AES keys are exchanged, which is why key exchange is being upgraded first.
Can quantum computers break RSA?
In principle, yes. Shor's algorithm factors large numbers efficiently on a big enough quantum computer, which would recover RSA private keys. A 2025 estimate suggested a 2,048-bit key could fall in under a week to a machine with under a million noisy qubits, far more than any built so far. NIST's draft plan disallows RSA after 2035, with ML-KEM and ML-DSA as replacements.