Four attack families, on their own terms
Not one threat but a family, and the members have wildly different prerequisites. This page works through each before any product is proposed as an answer — because a capability claim only means something once you know exactly what it is claimed against.
Every quantum-relevant attack, and what it actually needs
The fourth column is the one people skip, and it is where most of the confusion lives. Two of these need no quantum computer at all.
| Attack | Class | What it defeats | Adversary prerequisite | Realistic today? |
|---|---|---|---|---|
| Harvest-now-decrypt-later | Strategic | Confidentiality of anything recorded now under RSA/ECDH key exchange | Storage, patience, network access. No quantum computer at harvest time | Underway now |
| Shor — integer factoring | Cryptanalytic | RSA at every key size; no larger modulus helps | Fault-tolerant QC, ~10⁵–10⁶ physical qubits under current estimates | Not yet |
| Shor — discrete log (ECDLP) | Cryptanalytic | ECDH, ECDSA, EdDSA, DH, DSA — and every major blockchain | ~100× fewer Toffoli gates than RSA; minutes, not days, once running | Not yet — but cheaper than RSA |
| Grover — unstructured search | Cryptanalytic | Symmetric keys and hashes — quadratically, not catastrophically | Enormous coherent runtime; parallelises poorly | Manageable — use 256-bit |
| QKD implementation attacks | Physical | Deployed QKD links, via detectors, sources and side channels | Optical access to a real QKD fibre. No quantum computer at all | Demonstrated in labs |
| Downgrade / hybrid stripping | Protocol | A PQC rollout that still negotiates classical-only as fallback | Ordinary active MITM position | Available today |
| Trust-anchor & signature forgery | Cryptanalytic | PKI roots, code signing, firmware — forward in time only | A CRQC at the moment of verification, not of signing | Not yet |
| Crypto-agility failure | Organisational | Your ability to respond at all when any of the above lands | None — this one is self-inflicted | Already the default |
Scroll the table horizontally to see all columns.
Shor breaks. Grover only weakens.
Two algorithms, two entirely different consequences. Treating them as one threat produces the wrong remediation plan — usually an expensive symmetric-key project that was never needed.
| Primitive | Attack | Effect | Fix |
|---|---|---|---|
| RSA (any size) | Shor | Broken | ML-KEM / ML-DSA |
| DH · DSA | Shor | Broken | ML-KEM |
| ECDH · ECDSA · EdDSA | Shor | Broken | ML-KEM / ML-DSA |
| AES-128 | Grover | ~64-bit | Move to AES-256 |
| AES-256 | Grover | Adequate | No change |
| SHA-256 / SHA3-256 | Grover | Adequate | No change |
| ML-KEM · ML-DSA · SLH-DSA | None known | By design | Deploy |
Why key size cannot save RSA
Shor solves factoring and discrete log in polynomial time. RSA, DH and every elliptic-curve scheme rest on exactly one of those problems being hard. There is no modulus large enough — the hardness assumption itself is gone, which is why the answer has to be different mathematics.
Why Grover is survivable
Grover gives a quadratic speedup, so 256-bit symmetric keys retain roughly 128 bits of quantum security. It also parallelises badly, and the coherent runtime required is punishing. Doubling symmetric key length is a genuinely sufficient response.
Harvest now, decrypt later: the anatomy
The only attack here whose first stage requires no quantum technology whatsoever. It is a storage-and-patience problem, which is exactly why it is already happening.
Two ways to write the same inequality
Mosca's inequality is the standard formulation. The exposure window is the same arithmetic rearranged to produce a number a steering committee can act on. Both are planning heuristics — neither predicts a date.
Mosca's inequality — the test
X + Y > Z
- X — years the data must stay secret
- Y — years the migration takes, start to finish
- Z — years until a capable quantum computer exists
If the inequality holds, you are already exposed. It answers yes or no.
Exposure window — the priority
W = Z − Y − X
- W < 0 — CRITICAL, exposure already closed
- 0 ≤ W < 3 — HIGH · 3 ≤ W < 7 — MEDIUM · W ≥ 7 — LOW
Same inputs, but it returns a signed magnitude, so thousands of assets can be ranked against each other rather than each answering yes.
Urgency is set by the data, not the system
The same TLS stack protecting a session token and a genomic record carries completely different exposure. Prioritisation has to start from the confidentiality lifetime of the content.
| Data class | Secrecy lifetime | Urgency |
|---|---|---|
| Health & genomic records | Decades to lifetime | Critical |
| State & diplomatic traffic | Decades | Critical |
| Identity & biometric enrolment | Lifetime — cannot be reissued | Critical |
| Long-lived trade secrets, IP | 10–30 years | High |
| Financial records | 7–10 years | Medium |
| Legal & contractual archives | 7–20 years | Medium |
| Routine session traffic | Minutes to days | Low |
Forward secrecy does not save you
Ephemeral ECDH is the standard answer to key compromise, and against a classical adversary it works. Against a quantum one it does not: the ephemeral public values were transmitted in the clear and recorded along with everything else. The discrete-log problem underneath them is exactly what Shor solves. Perfect forward secrecy protects against a stolen long-term key, not a broken hardness assumption.
Where Indonesian institutions concentrate risk
Population-scale identity, health and civil-registry data have the longest secrecy lifetimes of anything an organisation holds, and biometric enrolment cannot be rotated after a breach. Combined with financial infrastructure under 7–10 year retention obligations, the national exposure sits in the top rows of this table, not the bottom.
The cost of breaking RSA-2048 keeps collapsing
The hardware did not get better this fast. The algorithms and error-correcting codes did. Every reduction below came from compilation, arithmetic and code design — not from a bigger machine.
Hundreds of millions to a billion physical qubits
20 million qubits, ~8 hours
Under one million noisy qubits, under one week
Pinnacle qLDPC architecture — simulation only
What produced the 2025 drop
- Approximate residue arithmetic — far fewer logical qubits
- Yoked surface codes — roughly triple the storage density for idle logical qubits
- Magic state cultivation — high-fidelity resource states at close to ordinary gate cost
- Toffoli count cut by more than 100×, to roughly 6.5×10⁹
Read the trend, not the number
Gidney himself states he sees no further order-of-magnitude reduction without changing the physical assumptions — and Iceberg's answer was to change them, moving from surface codes to qLDPC. Each reduction shifts difficulty onto harder engineering: non-local connectivity, real-time decoding, month-scale fault-tolerant stability. The qubits get fewer; the machine gets nastier.
Elliptic curve falls first, and falls faster
Almost every quantum-threat briefing is written about RSA. The elliptic-curve case is substantially cheaper to attack and arrives with an operational twist RSA does not have.
| Dimension | RSA-2048 | ECDLP-256 |
|---|---|---|
| Toffoli gates | ~6.5 × 10⁹ | ~70–90 × 10⁶ (≈100× fewer) |
| Physical qubits | < 1 M (2025) · < 100 k (2026 arch.) | < 500 k (Mar 2026) |
| Runtime once running | Under a week | Minutes |
| Precomputation | Limited | Primeable — half the work depends only on curve parameters |
| Time after key exposure | n/a | ≈ 9 minutes to recover a private key |
The blockchain corollary
Bitcoin's average block time is ten minutes. Once a public key is revealed in an unconfirmed transaction, a primed attacker needs roughly nine. The published estimate puts the probability of deriving the private key before confirmation at around 41% under idealised conditions. Mitigations are protocol-level: stop reusing addresses, avoid unnecessary key exposure, private mempools, and quantum-resistant signature schemes.
Responsible disclosure, in cryptanalysis
The authors did not publish the attack circuits. They released a zero-knowledge proof letting anyone verify the resource estimates without obtaining the circuits, and engaged government before publication. That an offensive quantum result now warrants disclosure discipline is itself a signal about where this field has moved.
Nobody attacks the mathematics. They attack the optics.
The security proof holds within its assumptions. Real hardware violates those assumptions — and this is the family of attacks that has actually been demonstrated, none of which needs a quantum computer.
| Attack | Target | Mechanism | Countermeasure |
|---|---|---|---|
| Photon-number splitting | Source | Attenuated laser pulses occasionally contain multiple photons; Eve siphons one and keeps it, learning key bits without adding error | Decoy-state protocol; SARG04; true single-photon sources |
| Detector blinding / faked state | Detector | Bright light forces avalanche photodiodes into linear mode; Eve then drives detection events at will and can recover the full key undetected by error checking | Optical power monitoring, detector self-testing, MDI-QKD |
| Trojan horse | Source & receiver | Eve injects light into Alice's or Bob's apparatus and reads the back-reflection to learn the encoding settings | Optical isolators, passive components, watchdog detectors |
| Time-shift | Detector | Exploits efficiency mismatch between the two single-photon detectors across the detection window | Active basis selection, temporal monitoring, MDI-QKD |
| Phase remapping | Source | Imperfect or absent global phase randomisation lets Eve remap the encoded states | Active phase randomisation, characterisation in the proof |
| Dead-time | Detector | Detector recovery periods leak basis information through detection timing | Simultaneous dead-time enforcement, MDI-QKD |
| Electromagnetic side channel | Electronics | RNGs, detectors and high-speed electronics radiate signals correlated with internal state — basis settings, detection events | Shielding, TEMPEST-grade engineering, emissions testing |
| Denial of service | Channel | Cutting or degrading the fibre stops key agreement entirely — the abort behaviour is itself the vulnerability | Path diversity, fallback to authenticated PQC key establishment |
Scroll the table horizontally to see all columns.
What QKD is for, and what it is not for
QKD is a legitimate technology with a narrow, real use case. Most of the harm in this space comes from claims made on its behalf rather than from the technology itself.
Defensible positions
- Key agreement over a dedicated optical link between two trusted, physically controlled endpoints
- Detection of certain eavesdropping classes, under stated assumptions
- A defence-in-depth layer alongside PQC on very high-value, fixed, short-haul links
- A research and training platform where protocol behaviour is the subject
Claims to refuse
- "Unconditionally secure" without qualifying the implementation and proof assumptions
- "QKD implemented in software" offered as a production security control
- A universal ~11% error threshold applied to every protocol and deployment
- Authentication solved by QKD — the classical channel still needs authentication, and that authentication needs PQC
- Photonic-compute compatibility implying QKD hardware compatibility
What real QKD requires
A photon source, single-photon detectors, dedicated fibre or free-space optics, timing and calibration infrastructure, trusted-node design over distance, and an authenticated classical channel. NSA notes it needs special-purpose equipment and dedicated physical-layer communications.
Why it does not replace PQC
It secures a point-to-point link between fixed endpoints. It does not secure code signing, data at rest, stored backups, mobile clients, third-party APIs, or any of the several thousand other places an enterprise uses public-key cryptography today.
Why it still belongs in the lab
Indonesian operators are already discussing quantum-safe networks and data centres. Being able to model a QKD link's behaviour, failure modes and economics — before anyone procures optics — is worth considerably more than the optics.
Four failures that need no quantum computer at all
These are the attacks a PQC programme creates for itself. They are available today, against organisations that have already started migrating — which makes them more urgent than Shor, not less.
Downgrade and hybrid stripping
A rollout that negotiates ML-KEM when both sides support it, and silently falls back to classical-only when they do not, gives an active attacker a switch. The fallback path is the real security level of the deployment, and a harvesting adversary only needs the session to take it once.
Test for it: does a hybrid handshake fail closed, or fall back quietly? A negotiated-evidence scan — not a declared-capability scan — is the only way to know.
Trust anchors and code signing
Signatures are not exposed to harvesting, but roots are long-lived. A national or federal root CA signing with RSA or ECDSA must be re-keyed before deprecation — and re-keying a root means reissuing the entire subordinate hierarchy and redistributing trust anchors.
The long pole: firmware and code signing on devices with 10–20 year field lives that may never be updatable again.
Crypto-agility failure
Most systems cannot change algorithm without changing code. That is survivable once. It is not survivable across FIPS 203/204/205 now, FIPS 206 later, HQC as a code-based backup, and whatever follows a lattice cryptanalysis result.
Design rule: algorithm identity belongs in configuration and in the inventory, never in the source.
Inventory drift
An inventory is a photograph, and dependencies reintroduce classical-only cryptography continuously — a new SDK, a vendored library, a bundled OpenSSL three minor versions behind. Organisations that completed a migration in one system routinely find it undone by the next release.
Design rule: the scan is not a project deliverable, it is a pipeline check with a failure threshold.
The clock is no longer a risk argument. It is a date.
Migration is expensive and the threat is not yet visible, which historically made it easy to defer. Standards bodies removed that option by setting one deadline for everyone at once.
| Authority | Instrument | What it requires | Date |
|---|---|---|---|
| NIST | FIPS 203 · 204 · 205 — ML-KEM, ML-DSA, SLH-DSA | The finalised foundational PQC standards | Finalised 13 Aug 2024 |
| NIST | IR 8547 (initial public draft) | RSA, ECDSA, ECDH, DH deprecated, then disallowed | Deprecated after 2030, disallowed after 2035 |
| NIST | FIPS 206 (FN-DSA) · HQC | Falcon-based signature; code-based backup KEM | FIPS 206 not yet drafted as of mid-2026; HQC selected Mar 2025, expected 2027 |
| NSA | CNSA 2.0 | ML-KEM-1024 and ML-DSA-87 specifically — stricter than the common hybrid group | New national security systems quantum-safe by Jan 2027 |
| EU | Coordinated implementation roadmap | National roadmaps, then high-risk migration, then completion | Roadmaps end-2026 · high-risk 2030 · complete 2035 |
| Canada | ITSM.40.001 | Departmental migration plans and phased completion | Plan Apr 2026 · high-priority 2031 · rest 2035 |
| Indonesia | BSSN National PQC Migration Task Force | Cryptographic inventory, risk analysis, prioritisation, migration roadmap, execution, monitoring — with a draft Presidential Regulation as an output | Kick-off 25 June 2026 |
Scroll the table horizontally to see all columns.