Nation-state intelligence agencies do not need quantum computers today to threaten your current encrypted data. They need them eventually — and they are patient. The “harvest now, decrypt later” strategy involves collecting encrypted internet traffic now, storing it, and decrypting it when quantum computing power arrives. If your data is encrypted with RSA-2048 or standard elliptic-curve cryptography today, it may be decrypted in 5–15 years. NIST addressed this by publishing post-quantum standards in August 2024. In April 2026, Claude Mythos demonstrated that AI can already chain cryptographic exploits at scale — the cryptographic threat landscape is not waiting for quantum computers alone.
Direct Answer: What is post-quantum cryptography and do I need it now? Post-quantum cryptography (PQC) refers to cryptographic algorithms designed to resist attacks from both classical and quantum computers. The urgency comes from the “harvest now, decrypt later” strategy: adversaries collect encrypted traffic today to decrypt it once quantum computers are powerful enough. NIST standardised three post-quantum algorithms in August 2024: ML-KEM (FIPS 203) for key encapsulation/encryption, ML-DSA (FIPS 204) for digital signatures, and SLH-DSA (FIPS 205) as a backup. For most individuals, the most practical step is using services that have already implemented these standards: Signal (PQXDH since 2024), Mullvad/ProtonVPN/NordVPN (ML-KEM in VPN tunnels), and ensuring browsers support TLS with post-quantum key exchange (Chrome and Firefox both support experimental PQC). For organisations handling long-lived sensitive data, migrating to PQC is urgent now.
The Threat: Why “Not Yet” Is Not the Right Answer
Most people’s intuition about quantum computing and encryption is: “quantum computers that can break RSA don’t exist yet, so this is a future problem.”
This intuition misses the harvest now, decrypt later strategy.
How HNDL works:
Intelligence agencies — NSA, GCHQ, and their equivalents globally — have the infrastructure to capture significant volumes of internet traffic at backbone level. They collect encrypted traffic now: VPN tunnels, HTTPS sessions, encrypted emails, Signal conversations. They store it. They cannot decrypt it today. They will decrypt it when quantum computing reaches sufficient scale.
The timeline question: How long until a quantum computer can break RSA-2048 or 256-bit ECDH? Current estimates range from 5 to 15+ years. The uncertainty is wide. But the consequence of being wrong is that encrypted data from today becomes readable.
For most personal communications, this is low risk — your 2026 WhatsApp messages are unlikely to be worth storing for a decade. For data that matters long-term — government documents, medical records, legal communications, proprietary research, classified business information — the risk is real now.
Claude Mythos made this more urgent this week: Anthropic’s announcement that Claude Mythos can autonomously chain cryptographic exploits — finding 17-year-old and 27-year-old vulnerabilities in major operating systems — illustrates that the attack surface is expanding through AI-assisted exploitation alongside the quantum computing threat. These are separate threats that converge.
The NIST Standards: What Was Standardised and Why
In August 2024, NIST (National Institute of Standards and Technology) published three final post-quantum cryptography standards after a multi-year process involving the global cryptographic research community.
ML-KEM (FIPS 203) — Key Encapsulation Mechanism
Based on: CRYSTALS-Kyber (lattice-based cryptography) Replaces: RSA and ECDH for key exchange and key encapsulation Status: Primary standard for encryption and key exchange
ML-KEM is what you use when two parties need to establish a shared secret over an insecure channel — the core operation for HTTPS, VPNs, and encrypted messaging. It is based on the hardness of problems in structured lattices, which are believed to be computationally infeasible for both classical and quantum computers.
Where it is deployed today:
- NordVPN (NordLynx protocol): ✅ ML-KEM
- Mullvad VPN (WireGuard): ✅ ML-KEM
- ProtonVPN: ✅ Post-quantum (Kyber-based)
- Signal: ✅ PQXDH (Kyber + X25519 hybrid)
- Chrome: ✅ Experimental (X25519Kyber768)
- Firefox: ✅ Experimental (ML-KEM in TLS)
- Cloudflare: ✅ Post-quantum TLS (ML-KEM hybrid)
- AWS: ✅ Post-quantum hybrid TLS
ML-DSA (FIPS 204) — Digital Signature Algorithm
Based on: CRYSTALS-Dilithium (lattice-based) Replaces: RSA-PSS, ECDSA for digital signatures Status: Primary standard for digital signatures
Digital signatures authenticate documents, code, certificates, and software updates. Replacing ECDSA with ML-DSA in software signing, certificate authorities, and code signing is a longer migration timeline than encryption — it requires coordinated updates across the entire PKI infrastructure.
Timeline concern: TLS certificates (the HTTPS padlock) use ECDSA signatures. A quantum computer that can break ECDSA would allow an adversary to forge certificates, enabling man-in-the-middle attacks on HTTPS traffic. Certificate authorities are beginning to test ML-DSA certificates, but widespread deployment is still underway.
SLH-DSA (FIPS 205) — Backup Signature Scheme
Based on: SPHINCS+ (hash-based) Purpose: Backup standard using fundamentally different mathematics than ML-DSA
SLH-DSA uses hash-based cryptography rather than lattice-based — providing a mathematically independent alternative. If a theoretical flaw is found in ML-KEM/ML-DSA (lattice-based), SLH-DSA remains secure. This diversity is intentional.
What Is Already Compromised
Not all cryptography is equal, and some is more urgent to migrate than others.
Immediately vulnerable (quantum-breakable) if harvested:
- RSA encryption (including RSA-2048 and RSA-4096)
- ECDH key exchange (P-256, P-384, Curve25519 without PQC hybrid)
- ECDSA signatures (P-256, secp256k1)
- Diffie-Hellman (DH) key exchange
Not quantum-vulnerable:
- AES-256 symmetric encryption (requires only twice the key length against quantum Grover’s algorithm — AES-256 provides ~128-bit security against quantum)
- SHA-256/SHA-3 hashing (similar Grover’s algorithm resistance)
- Most zero-knowledge proof systems (do not rely on factoring/discrete log)
The practical implication: Your data encrypted with AES-256 is safe. Your data protected by RSA or ECDH key exchange (which was used to establish the session key that encrypted with AES-256) is the vulnerable layer. The session key negotiation is what needs post-quantum upgrading.
The Hybrid Approach: Why “Just Switch to PQC” Is Not Simple
Pure PQC adoption faces a challenge: the new algorithms are newer and have less cryptanalytic scrutiny than RSA or ECDH, which have been studied for decades. If a theoretical flaw is found in ML-KEM before quantum computers arrive, a migration to pure ML-KEM would leave data unprotected.
The solution is hybrid key exchange: combining a classical algorithm (X25519, the current standard) with a PQC algorithm (ML-KEM) so that the session key is secure as long as either algorithm holds.
Signal’s PQXDH: Signal’s post-quantum extended Diffie-Hellman key agreement combines X25519 (classical) with Kyber-1024 (ML-KEM). The security is as strong as the stronger of the two algorithms. If Kyber has a theoretical flaw, X25519 still provides classical security. If X25519 is broken by quantum computers, Kyber provides post-quantum security.
This hybrid approach is the current recommendation from NIST and is what all major VPN and browser implementations are deploying.
Practical Actions for 2026
For Individuals
Switch to a VPN with PQC: Mullvad, ProtonVPN, and NordVPN all support ML-KEM. If your current VPN does not, consider switching.
Verify Signal is up to date: Signal implemented PQXDH in September 2024. Keep Signal updated — the post-quantum protection is automatic once you have a recent version.
Browser PQC: Chrome (v124+) and Firefox (v128+) support post-quantum key exchange for TLS connections. This is enabled by default. Verify your browser is current.
For high-risk data: Use tools that support PQC for anything sensitive you want to remain private for more than 5 years. Proton Mail’s end-to-end encrypted messages, Signal conversations, and files stored in encrypted volumes with AES-256 keys established via ML-KEM hybrid exchange.
For Organisations
Inventory current cryptography: Map every system that uses RSA or ECDH: TLS certificates, code signing, SSH keys, VPN connections, API authentication, document signatures.
Prioritise by data lifetime: Migrate systems handling long-lived sensitive data first — medical records, legal documents, financial data, intellectual property. VPN and SSH migration (to ML-KEM hybrid) is often the fastest win.
Certificate migration: Begin testing ML-DSA certificates for internal services. Plan for public certificate migration when CAs achieve broader ML-DSA support.
Do not wait for FIPS 203/204 compliance deadlines: The US government has published migration timelines requiring agencies to begin PQC migration immediately. For organisations in or serving the US government, this is regulatory compliance.
The Sovereignty Dimension
Post-quantum cryptography connects directly to the sovereignty question at the core of Vucense’s editorial mission.
Who holds your encrypted data matters more than the encryption strength. If sensitive data is stored by a cloud provider subject to US legal process, quantum-resistant encryption is necessary but not sufficient — legal compulsion does not require breaking cryptography. Self-hosted, locally encrypted data (Nextcloud with E2EE, Obsidian vault on local storage, offline backups) is protected by both the cryptography and the absence of a third party who can be legally compelled.
Open-source PQC implementations are auditable. The NIST standardised algorithms have open-source reference implementations and extensive third-party cryptanalysis. Unlike proprietary cryptographic systems, you can verify that ML-KEM is implemented correctly in tools you use. Signal’s PQXDH implementation is open source and has been independently reviewed.
The Claude Mythos reminder: This week’s announcement that Anthropic’s model can autonomously find and exploit cryptographic vulnerabilities — chaining together flaws to achieve exploits — is a reminder that the cryptographic threat landscape includes AI-assisted classical attacks alongside future quantum attacks. Post-quantum migration is necessary; it is not sufficient without keeping software updated and following the defensive security practices that Project Glasswing is designed to accelerate.
FAQ
Can a quantum computer break my AES-256 encryption? Not in any practical sense. Grover’s algorithm allows a quantum computer to search an AES-256 keyspace in approximately 2^128 operations instead of 2^256 — still computationally infeasible. AES-256 is considered quantum-resistant. The vulnerable layer is the key exchange used to establish the session key, not the symmetric encryption itself.
Is Signal post-quantum encrypted? Yes — Signal implemented PQXDH (Post-Quantum Extended Diffie-Hellman) in September 2024. New Signal conversations on updated clients use hybrid X25519+Kyber-1024 key exchange. Existing conversations are upgraded when both parties update.
When will quantum computers break RSA? Current estimates from leading researchers: between 5 and 20 years for a cryptographically relevant quantum computer (one that can break RSA-2048). IBM has stated that 2026 will mark a milestone in quantum advantage, but this is for specific problems — not RSA cryptanalysis. The uncertainty in timing is why migrating now is prudent.
What is “crypto agility”? The architectural principle of designing systems so that cryptographic algorithms can be updated without rebuilding the entire system. A system with crypto agility can switch from ECDH to ML-KEM when needed by changing a configuration parameter. A system without it requires a full rebuild. Crypto agility is now a design requirement for any system expected to operate for more than 5 years.
Does using HTTPS protect me from harvest now, decrypt later attacks? Standard HTTPS using ECDH key exchange is vulnerable to HNDL. HTTPS using ML-KEM hybrid key exchange (now supported in Chrome and Firefox) is resistant. The lock icon in your browser does not tell you which key exchange was used — you need to inspect the connection details (usually accessible via developer tools) to confirm PQC key exchange.
Related Articles
- Claude Mythos: The AI Too Dangerous to Release — Project Glasswing
- Best VPN 2026: Mullvad vs ProtonVPN vs NordVPN — Sovereignty Ranked
- What Is Zero-Knowledge Encryption? Plain-English Guide 2026
- Signal vs WhatsApp vs Telegram 2026: Which Actually Protects You?
- GrapheneOS Setup Guide 2026: The Most Sovereign Android
Sources & Further Reading
- NIST Cybersecurity Framework — US government cybersecurity best-practice guidelines
- OWASP Foundation — Open-source security community and vulnerability research
- Krebs on Security — Investigative cybersecurity journalism
