Cryptography and digital assets
When does a quantum computer break your keys?
A quantum computer breaks an elliptic curve key by running Shor's algorithm for discrete logarithms, recovering the private key from the public one. We ran that algorithm against real curves on our own engines. It works, we have the keys to show for it, and the size at which it stops working is a measurement rather than an opinion.
The key recoveries here ran on exact.cpu, and the 7-bit key on exact.gpu too. Open the console
What we measured
- We recovered elliptic curve private keys of 3, 4, 5, 6 and 7 bits from their public keys, on curves over F5 through F107, using 9 to 21 qubits. The algorithm does what it says it does
- The 7-bit key was also recovered on the GPU tier,
exact.gpu: 21 qubits, 64 shots, done in 66 seconds, with a public certificate - Each additional bit of key multiplied the two-qubit gate count by roughly five, from 328 gates at 3 bits to 235,470 at 7. Width grew by three qubits a bit; depth is what ran away
- A 3-bit key still came out at 99.0 percent two-qubit fidelity. A 4-bit key needed better than 99.8 percent. One extra bit moved the requirement from any current device to only the best ones
- secp256k1, the curve behind Bitcoin and Ethereum, is 256 bits. The textbook construction needs about 2,304 logical qubits; the 2026 estimates need about 1,200 to 1,500 and put the whole machine at 10,000 to 500,000 physical qubits. No machine that exists is close to it
The short version
- Depth, not width, is the barrier. Two-qubit gate count grows about fivefold per bit of key while width grows three qubits per bit
- One extra bit moved the requirement across every device in service. A 3-bit key survives 99.0 percent fidelity, a 4-bit key breaks between 99.8 and 99.5
- Elliptic curve keys fall before RSA keys. By the textbook construction a 256-bit curve needs about 2,304 logical qubits against RSA-2048's 4,099
- The threshold event is 2029, not 2027. Sol's distance-2 code discards runs rather than correcting them, and postselection cannot carry Shor's depth
Run these estimates yourself. The notebook rebuilds the exact seeded instance behind every figure on this page, in a browser tab, with nothing to install and no account. Read it on GitHub
Then run it on our engines
The notebook proves the numbers on free public packages. This is the step it does not cover: the same circuit on a certified engine, with a public certificate you can cite instead of citing ours.
pip install qsim-sdk import qsim_sdk client = qsim_sdk.Client(token="...") # free account at app.zksf.org client.estimate(circuit, shots=512) # free, before you spend anything job = client.run(circuit, shots=512) # $0.0001 on CPU job.certificate() # a public, verifiable URL
Every finished job can be exported as a public certificate that opens without an account, and the rules these benchmarks follow apply to your run exactly as they do to ours.
What you can and cannot run here
Runnable: the elliptic curve key recoveries on this page, modular-arithmetic and period-finding circuits on exact.cpu, Grover circuits over small search spaces, and error-correction-scale stabilizer circuits at thousands of qubits on clifford, each returning a certificate stating how exact the answer is. Not runnable, here or anywhere: Shor at a key-breaking width. That is the whole finding, and it is checkable rather than asserted.
Why this application has a deadline
Every other application on this site is a question of whether quantum computing becomes useful. This one is a question of when it becomes dangerous, and the difference matters because encrypted data can be captured today and decrypted later. Anything with a confidentiality lifetime measured in decades, medical records, state secrets, long-dated contracts, is already exposed to a machine that does not yet exist.
Digital assets have a sharper version of the same structure. The exposed quantity is the public key, not the address, so the accounts at risk are the ones whose public key has already appeared on-chain through a prior spend. Mining and the hashing that secures it are a separate question and a far less urgent one.
Elliptic curve keys also fall before RSA keys, because a 256-bit curve needs roughly 2,304 logical qubits by the textbook construction, against RSA-2048's 4,099. Any migration plan that treats RSA as the urgent case and elliptic curve as comfortable has the ordering backwards.
What we ran
For each curve we picked a generator P, chose a private key d, published the public key Q = dP, and asked the algorithm to recover d. Two exponent registers are put in superposition, a third register accumulates a curve point, and an inverse quantum Fourier transform on the exponent registers produces measurements satisfying y = d·x in the group order, which gives d directly.
The group law is realised as a permutation over the curve's points, built by real elliptic curve point addition from the public generator and the public key. The secret appears nowhere in the circuit; it is used once, at the end, to check the answer. Curve orders are powers of two so the Fourier transform is exact and the only error left is the device's.
Building that permutation means enumerating the group, so what this measures is the width and depth the algorithm needs at each key size, and the scaling to 256 bits further down uses the standard field-arithmetic construction instead.
Keys recovered
Run on our engines
Shor's discrete logarithm algorithm on real elliptic curves y² = x³ + ax + b over F5 to F107, recovering each private key from its public key at 64 shots. On 25 September the 7-bit recovery ran again on exact.tpu, a Google TPU, recovering the same key from 25 usable shots in 271 seconds. Submitted to each kind of compute we offer, on 10, 24 and 25 September 2026. Every figure below is a real job on the service, priced as any customer would be priced.
| Device | Engine | Kind | Qubits | Result | Cost |
|---|---|---|---|---|---|
 | exact.cpu | CPU | 9 | 3-bit key recovered, d = 7, in 0.14 s * | $0.0001 |
| exact.cpu | CPU | 12 | 4-bit key recovered, d = 11, in 0.57 s * | $0.0001 |
| exact.cpu | CPU | 15 | 5-bit key recovered, d = 19, in 8.40 s * | $0.0002 |
| exact.cpu | CPU | 18 | 6-bit key recovered, d = 35, in 6.70 s * | $0.0002 |
| exact.cpu | CPU | 21 | 7-bit key recovered, d = 67, in 70.5 s * | $0.0020 |
 | exact.gpu | GPU | 21 | 7-bit key recovered, d = 67, in 66 s certificate | $0.1066 |
 | exact.tpu | TPU | 21 | 7-bit key recovered, d = 67, in 271 s certificate | $0.4534 |
| neural.tpu | TPU | — | Shor's algorithm is a circuit, not a Hamiltonian, so it does not reach the neural tier | — |
* Run in-process on the exact.cpu engine rather than submitted as billed jobs. Each cost is the measured runtime priced at the rate the service quotes for CPU work, with its $0.0001 minimum. The steps are in the docs.
The same problem is yours to run: every instance here is seeded, so it rebuilds exactly. Open the console and a cost estimate is free before anything executes.
Run on exact.cpu, 64 shots each. Every private key in the last column was recovered from its public key, not assumed.
| Key size | Curve | Qubits | Two-qubit gates | Runtime | Private key recovered |
|---|---|---|---|---|---|
| 3 bits | y²=x³+4x+1 / F5 | 9 | 328 | 0.14s | d = 7 |
| 4 bits | y²=x³+2x+1 / F11 | 12 | 1,924 | 0.57s | d = 11 |
| 5 bits | y²=x³+1x+10 / F23 | 15 | 10,090 | 8.40s | d = 19 |
| 6 bits | y²=x³+1x+6 / F53 | 18 | 49,758 | 6.70s | d = 35 |
| 7 bits | y²=x³+1x+34 / F107 | 21 | 235,470 | 70.5s | d = 67 |
Read the gate column, not the qubit column. Width grows politely, three qubits per bit of key, which is why 7 bits still fits on a workstation. The two-qubit gate count grows by a factor of about five per bit, from 328 to 235,470 across those four extra bits, and it is the gates a real device has to survive.
The same 7-bit recovery also ran on exact.gpu, the GPU tier: 21 qubits, 64 shots, private key 67 recovered in 66 seconds. The script is examples/crypto on GitHub.
How good does the hardware have to be?
The identical circuits, re-run on noisy.cpu with a depolarizing model at 4,096 shots. Only the two-qubit gate fidelity changes between rows.
| Two-qubit fidelity | 3-bit key (328 gates) | 4-bit key (1,924 gates) |
|---|---|---|
| 99.99% | recovered | recovered |
| 99.95% | recovered | recovered |
| 99.90% | recovered | recovered |
| 99.80% | recovered | recovered |
| 99.50% | recovered | failed |
| 99.00% | recovered | failed |
The 3-bit key survives every fidelity we tested, including the 99.0 percent that represents an ordinary superconducting device. The 4-bit key, six times as many gates, breaks between 99.8 and 99.5 percent.
A single extra bit of key moved the hardware requirement across the entire range of devices in commercial service. That is the mechanism behind every credible timeline disagreement, and it is why gate fidelity rather than qubit count is the number to track.
Scaling this to a 256-bit key
Two steps, both shown so the assumptions are visible rather than asserted.
Logical qubits. An elliptic curve discrete logarithm over a prime field of n bits needs roughly 9n logical qubits under the textbook field-arithmetic construction (Roetteler and colleagues, 2017), which puts secp256k1 at about 2,304. Shor against an n-bit RSA modulus needs about 2n + 3, so RSA-2048 needs about 4,099.
This is why a 256-bit curve is a smaller target than a 2048-bit modulus despite offering comparable classical security.
Physical qubits. Under the surface code the logical error rate falls as roughly 0.1(p/p_th)^(d/2) for physical error rate p, threshold p_th near 1 percent and code distance d, and each logical qubit costs 2d² − 1 physical ones. Requiring a logical error rate of 1e-15, low enough that an algorithm running for hours does not fail, fixes d.
Surface-code overhead assumes a two-dimensional nearest-neighbour layout, which suits superconducting hardware and overstates the cost for architectures that do not have that constraint. IBM's bivariate bicycle qLDPC code encodes 12 logical qubits in 144 data qubits and claims roughly a tenfold overhead reduction against the surface code, and Quantinuum's all-to-all trapped-ion connectivity permits high-rate codes that a planar layout cannot. Treat the surface-code figure as an architecture-specific upper bound rather than a universal one. Apply IBM’s claimed tenfold reduction to the table below and RSA-2048 falls from roughly 6.9 million physical qubits to roughly 690,000. An order of magnitude is not a rounding error, which is exactly why the fidelity measurement above matters more than the qubit arithmetic.
Error rate drives everything
Physical qubits needed per logical qubit, at a target logical error rate of 1e-15.
| Physical error rate | Code distance | Physical per logical | Comment |
|---|---|---|---|
| 1% | n/a | never: at or above threshold | Error correction cannot help here |
| 0.5% | 95 | 18,049 | Marginal, overhead explodes |
| 0.1% | 29 | 1,681 | Typical of good superconducting devices |
| 0.01% | 15 | 449 | Reached today by IonQ and Silicon Quantum Computing |
The top row is the most important one. At or above threshold, error correction does not work at all and no number of qubits fixes it. Below threshold the overhead falls fast: a tenfold improvement in gate fidelity cuts the physical requirement by nearly four.
Every figure in that table is arithmetic, from a textbook suppression formula rather than from a measurement. The quantity it assumes, how much each two steps of code distance divide the logical error rate, is measurable: run the code at several distances at your own physical error rate and fit it. The answer then states which half was measured and which was extrapolated along the measured slope, instead of taking the whole curve on faith. The method, and the same surface-code numbers measured rather than assumed, are in logical qubits vs physical qubits.
The naive surface-code arithmetic
At a 0.1% physical error rate, giving 1,681 physical qubits per logical qubit. This is the conservative column. The best two-qubit fidelity reported today is 99.99 percent, which drops the overhead to 450 and every figure below by a factor of 3.7. At that rate RSA-2048 needs roughly 1.8 million physical qubits rather than 6.9 million.
The comparison column is the largest processor in our own catalogue, 108 physical qubits; machines above a thousand qubits exist elsewhere, and the gap remains four orders of magnitude either way.
| Target | Logical qubits | Physical (naive surface code) | vs 108 today | Where it is used |
|---|---|---|---|---|
| RSA-2048 | 4,099 | 6,894,518 | 63,838x | TLS, code signing, most PKI |
| RSA-4096 | 8,195 | 13,783,990 | 127,630x | Long-lived roots of trust |
| ECC P-256 / secp256k1 | 2,304 | 3,875,328 | 35,883x | TLS, Bitcoin, Ethereum |
| ECC P-384 | 3,456 | 5,812,992 | 53,824x | High-assurance and government |
Treat 6.9 million as an upper bound, not a forecast
The arithmetic above is deliberately naive: generic surface code, no algorithmic optimisation, no co-design between the algorithm and the code. Published analyses that do all three land an order of magnitude below it, and they have been falling fast.
Craig Gidney’s 2019 analysis needed roughly 20 million physical qubits. His 2025 revision put it at 897,864 physical qubits and about five days, using approximate residue arithmetic, yoked surface codes and magic-state cultivation. A February 2026 architecture replacing surface codes with quantum LDPC codes projects fewer than 100,000 physical qubits at a 0.1 percent error rate, assuming non-local connectivity that superconducting hardware does not currently provide and codes not yet demonstrated at scale.
So the trajectory is 20 million in 2019, under a million in 2025, and plausibly under 100,000 in 2026: a factor of 200 in seven years, driven by algorithms and error correction rather than by hardware. Index a migration plan to milestones, not to a date. Our post-quantum primer tracks the published estimates.
Elliptic curve estimates fell the same way in 2026. Google Quantum AI put secp256k1 under 500,000 physical qubits running for minutes on superconducting hardware; Caltech and Oratomic put it at about 10,000 to 26,000 neutral atoms running for months to days; IonQ put it at 19,397 trapped ions running 25.7 days per key. All three sit far below the naive 3.9 million in the table above. The dated comparison, and which coins each kind of machine could reach, is in the Bitcoin article. On real hardware, the largest public elliptic curve key recovery so far is 15 bits, which won Project Eleven’s Q-Day Prize in April 2026.
Keys that small are also inside classical reach, so what matters is how the answer was obtained rather than whether it can be. A 15-bit key is 215 = 32,768 group operations to exhaust, milliseconds on one core. There is also a floor under any quantum attempt at these widths: every shot is checked classically for free, so a run carrying no signal at all still recovers the key with probability 1 - (1 - 1/n)s for a group of order n and s usable shots. A 16-bit group of order 65,173 sampled 20,000 times puts that at 26.4%, roughly one run in four on chance alone, which is why every result we publish carries its own P(success | pure noise) alongside the recovery.
What 16 bits would take, and what 20 would
The table above stops at 7 bits because that is where an exact simulator stops being cheap. The question past it is not whether the arithmetic works, which is settled, but whether a circuit of that size survives a real device. That is answerable today without running anything: transpile the construction against a specific machine’s own connectivity graph and count what comes out.
Compiled against Rigetti Cepheus-1-108Q, whose 386 coupler edges Braket publishes, routing costs a steady 2.2x over the logical gate count at every width tested. Register width is 4m + 5 for an m-bit group order, which reproduces the published 65- and 69-qubit figures exactly at the same orders, and that agreement is the check that the construction is right rather than merely runnable.
| Key bits | Qubits | Logical 2Q gates | Routed 2Q gates | Routed depth |
|---|---|---|---|---|
| 12 | 53 | 24,204 | 51,977 | 131,532 |
| 14 | 61 | 32,606 | 71,497 | 180,163 |
| 16 | 69 | 42,256 | 93,635 | 234,410 |
| 18 | 77 | 53,154 | 116,135 | 293,208 |
| 20 | 85 | 65,300 | 146,404 | 365,355 |
| 22 | 93 | 78,694 | 177,884 | 443,066 |
| 25 | 105 | 101,122 | 229,217 | 570,816 |
Width is not the obstacle. A 20-bit key needs 85 qubits and a 25-bit key 105, both inside a 108-qubit device. The obstacle is the 146,404 routed two-qubit gates a 20-bit attempt has to survive, at a depth of 365,355. Cost is not the obstacle either: pricing is flat in key size and linear in shots only, so a 20,000-shot run is $8.80 and the 50,000-shot ceiling is $21.55.
None of this has been run on hardware, and the distinction is the whole point. These are compiled circuits measured against a real device’s connectivity, not recovered keys. A circuit result and a hardware result are different claims, and this field routinely publishes them in the same sentence. The keys in the table above were recovered; the rows here are what the next widths would cost to attempt.
The milestones worth watching are published. Quantinuum Sol in 2027 targets around 100 logical qubits through the iceberg code, which is distance 2 and therefore detects errors and discards the run rather than correcting them; postselection cannot carry an algorithm of Shor’s depth, so Sol is not the threshold event for cryptography.
IBM Starling and Quantinuum Apollo, both targeting 2029, are: hundreds of logical qubits with genuine correction and circuits of 100 million gates. Even then, the 2026 estimates for secp256k1 need about 1,200 to 1,500 logical qubits, so hundreds is still short.
Run it yourself
The whole point of publishing a resource estimate is that someone can check it. Build the curve, build the circuit, and run it on the same engines we did. The 3-bit and 4-bit cases finish in under a second and cost a hundredth of a cent; the 6-bit case is 18 qubits and still simulates exactly.
pip install qsim-sdk
import qsim_sdk
client = qsim_sdk.Client(token="YOUR_TOKEN")
# Free, before you spend anything: what will this cost and fit on?
client.estimate(ecdlp_circuit, shots=64)
# Exact, so a failure is the algorithm's and not the device's
client.run(ecdlp_circuit, engine="exact.cpu", shots=64)
# Then ask what a real device would do to it
client.run(ecdlp_circuit, engine="noisy.cpu",
noise="superconducting", shots=4096)Change one thing and the answer changes with it: raise the key size and watch the gate count multiply, or hold the key size and lower the fidelity until the key stops coming out. That second experiment is the one worth running against your own vendor's published gate fidelity. Every job returns a documented accuracy statement, and the rules these benchmarks follow are in the methodology, including that results are published whichever side wins.
For context: where the hardware actually is
Gaps on this page are quoted against the processors ZKSF can run. That is not the frontier. Quantinuum, IBM, Atom Computing and QuEra’s newest systems are not available through us, and those machines are considerably further along. As of September 2026:
Physical qubits built
| Infleqtion Sqale | 1,600 | Neutral atom |
| Atom Computing | 1,180 | Neutral atom, 1,225 sites |
| IBM Condor | 1,121 | Superconducting, 2023 |
| IBM Heron R2 | 156 | Superconducting, ~99.5% two-qubit fidelity |
| Rigetti Cepheus | 108 | The largest available through ZKSF |
Two-qubit gate fidelity
The number that actually governs what a circuit can do.
| IonQ | 99.99% | Trapped ion, first past four nines |
| Silicon Quantum Computing | 99.99% | Silicon spin |
| Quantinuum | 99.97% | Trapped ion, all-to-all |
| IQM | 99.91% | Superconducting, available through ZKSF |
Logical qubits demonstrated
Published results, not roadmap targets.
| QuEra | 96 logical / 448 physical | Neutral atom |
| Quantinuum | 48 logical / 98 physical | Trapped ion, iceberg code |
| Atom Computing | 24 logical | On the 1,180-qubit system |
| 1 logical / 105 physical | Surface code, below threshold |
Announced roadmap
Targets. Roadmaps slip, and these are not results.
| Quantinuum Sol, 2027 | 192 physical, ~100 logical | Iceberg code, distance 2. Error detection with postselection, not correction |
| IBM Starling, 2029 | ~200 logical | Bivariate bicycle qLDPC, 100 million gates |
| Quantinuum Apollo, 2029 | hundreds of logical | Thousands of physical, logical error 1e-6 or better |