CRQC Readiness Index Proposal
Table of Contents
A simple, vendor‑neutral way to track real progress toward Q‑Day
Why we need a cryptography‑focused benchmark
Security teams and policymakers keep asking a deceptively simple question: how close are we to a cryptographically relevant quantum computer (CRQC) – one that can run Shor’s algorithm at scales that break RSA‑2048 or comparable public‑key schemes?
Counting physical qubits won’t cut it. Capability depends just as much on error rates, coherence, error correction overhead, and sustained speed as it does on raw qubit count. And headline milestones like “quantum supremacy” via random circuit sampling (RCS), a 2019 tour‑de‑force experiment, don’t translate to cryptanalysis; that benchmark was designed to be hard for classical machines, not to run Shor.
This proposal outlines a composite, vendor‑neutral “CRQC Readiness” indicator. It intentionally avoids one‑number vanity metrics (like only counting qubits) and instead triangulates from three ingredients that actually matter for breaking today’s crypto: usable (logical) qubits, error‑tolerant algorithm depth, and sustained error‑corrected operations per second.
What existing metrics tell us – and what they don’t
Quantum Volume (QV). Introduced by IBM researchers in 2018/2019, QV compresses “how big and how deep a random circuit you can run” into a single number; it’s sensitive to both qubit count and fidelity. It’s useful for tracking general system improvements, and vendors reported steady QV gains. Still, QV is measured on randomized circuits – not on Shor’s modular exponentiation – and thus isn’t a direct proxy for crypto‑breaking readiness.
Random Circuit Sampling & “quantum supremacy.” Google’s 2019 RCS experiment showed a quantum device outperforming classical simulation on a highly contrived sampling task. A foundational scientific milestone? Absolutely. Evidence that RSA falls soon? No. Supremacy demonstrations speak to one benchmark class; cryptanalysis requires long, structured circuits with tight error budgets and heavy error correction.
Gate fidelities and coherence. Single‑ and two‑qubit error rates on leading platforms hover near or below the ~1% surface‑code threshold, with many experiments substantially better for specific gates (e.g., ion‑trap two‑qubit gates at ~99.9%). These are necessary but not sufficient: a CRQC needs system‑wide fault tolerance across thousands of logical qubits for billions of logical operations.
Randomized Benchmarking (RB). Since 2011, RB has provided a robust way to estimate average gate error rates at scale, becoming the de facto lens for hardware progress. Again, RB reports component quality – not whether the entire Shor workload fits within the machine’s error‑corrected depth and time budget.
Bottom line: QV, RCS, RB, and coherence/fidelity headlines are necessary context but insufficient on their own to estimate Q‑Day. We need a cryptanalysis‑aware composite.
What it takes to break RSA at scale
Two widely referenced resource estimates bracket the conversation and illustrate how multi‑factor the challenge is:
- Fowler–Mariantoni–Martinis–Cleland (2012) analyzed a surface‑code, fault‑tolerant implementation of Shor and found that factoring a ~2000‑bit RSA modulus could require on the order of thousands of logical qubits, ~3×10¹¹ sequential Toffoli gates, and tens to hundreds of millions of physical qubits depending on error rates and code distances – showing just how punishing error‑correction overhead can be.
- Gidney & Ekerå (2019) combined algorithmic and architectural optimizations and, under plausible surface‑code assumptions for superconducting qubits (physical gate error ~10⁻³, ~1 µs cycle), estimated that RSA‑2048 could be factored in ~8 hours using ~20 million physical qubits, with parallelization and distillation factories doing most of the heavy lifting. This is still far beyond 2020 hardware, but it dropped prior estimates by orders of magnitude – showing that algorithmic advances move the goalposts.
Implications for a benchmark: a CRQC isn’t “X qubits.” It’s (enough logical qubits) × (low enough logical error rates) × (fast and parallel enough to finish before the heat death of the data center) – all jointly.
The CRQC Readiness indicator
I propose a simple composite that tracks three cryptanalysis‑relevant dimensions. Each is normalized against a target profile implied by resource estimates for, say, RSA‑2048 (e.g., Gidney–Ekerå’s ~20 M physical qubits and hour‑scale runtime under surface‑code assumptions), while acknowledging uncertainty with ranges rather than single points.
- Logical Qubit Capacity (LQC). What fraction of the required logical qubits can the system field? LQC grows with physical qubit count and quality, and shrinks with error‑correction overhead. Demonstrated logical qubit counts relevant for deep arithmetic were effectively zero, so LQC sits near 0% across platforms. (Surface‑code analyses routinely map thousands of logical qubits to tens of millions of physical qubits at 10⁻³–10⁻⁴ error rates.)
- Error‑Corrected Depth (ECD). How many logical operations can be executed reliably in sequence before failure? Think of ECD as the budget of fault‑tolerant steps available to an algorithm like Shor. Fowler et al. estimate hundreds of billions of sequential logical operations for ~2000‑bit factoring in some constructions; Gidney–Ekerå shrink the total via optimized circuits but still require formidable depth alongside massive parallel distillation. Today, ECD for deep arithmetic is again effectively ~0%.
- Sustained Error‑Corrected Throughput (SECT). How many logical operations per second can the system sustain at scale? This rolls up clock rate, parallelism, and control overhead after accounting for error correction. The point isn’t a vendor‑specific speed metric; it’s whether you can execute the required ECD fast enough to finish within days/weeks, as suggested by resource‑estimate targets. As of today, sustained logical‑ops/sec on fault‑tolerant devices are nil; SECT ≈ 0%. (Conceptually akin to FLOPS in HPC, but “logical‑ops/sec.”)
Composite score. Combine LQC, ECD, and SECT with a bottleneck‑aware rule (e.g., a weighted geometric mean or “minimum‑dominates” heuristic) so a lagging factor caps the overall score. That prevents misleading spikes when, for instance, qubit counts rise but error‑corrected depth remains near zero.
Why these three?
They align with the state of the art and with fault‑tolerance economics: how many reliable qubits you can marshal (LQC), how deep a logical computation you can stomach (ECD), and how quickly you can chew through it (SECT). Everything we can measure (QV, RB fidelities, coherence, small‑scale EC demos) is evidence feeding into one of these three, but none alone answers the cryptanalysis question.
How to score inputs
- System quality & scale: use Quantum Volume trends as a coarse proxy for “qubits × fidelity,” while keeping it in its lane (random circuits). Use randomized benchmarking (RB) and process tomography for gate errors; track two‑qubit error trending toward/below the ~1% surface‑code threshold (with many experiments beating that for particular gates). These flow into assumed physical‑to‑logical qubit overheads and thus LQC.
- Error‑correction posture: track demonstrations of surface‑code primitives, syndrome extraction stability, cycle times (e.g., ~1 µs cycles in resource estimates), and distillation throughput assumptions. These feed ECD and SECT.
- Algorithmic milestones: incorporate latest resource‑reduction results (e.g., Gidney–Ekerå’s 2019 factoring cost cuts) to regularly re‑normalize targets; if an algorithmic breakthrough halves the logical‑depth requirement, ECD’s denominator shrinks and the composite can move even if hardware doesn’t.
Reading the tea leaves with this index
The composite score right now is essentially near 0%. NISQ‑era devices (Preskill’s term) are invaluable for science and for learning how to build fault‑tolerant systems, but they cannot yet run the error‑corrected, days‑long versions of Shor implied by resource estimates. The point of the index is not to ring alarm bells today, but to show which bottleneck breaks first and when the curve starts rising from zero.
Why track it anyway? Because progress is nonlinear. QV doubling, RB gains, and algorithmic reductions can combine in surprising ways. When the index climbs from ~0% to even low single digits, it would indicate multiple prerequisites are finally advancing in concert – i.e., usable logical qubits, meaningful error‑corrected depth, and throughput on the same platform. That’s your cue to accelerate crypto‑migration timelines.
Policy context: migrate early, migrate smart
NIST’s post‑quantum cryptography project formally entered its third (“selection”) round in July 2020 – clear institutional signaling that we must plan for a world where large‑scale quantum cryptanalysis is possible. The CRQC Readiness indicator complements that effort by offering a threat‑progress bar while standards mature, procurement starts, and inventories are mapped. Don’t wait for the index to hit double digits to begin crypto‑agility and harvest‑now‑decrypt‑later risk mitigation.
What this index deliberately excludes
- No supremacy‑to‑Shor extrapolations. RCS results don’t shortcut fault‑tolerant arithmetic.
- No vendor scorecards. The method is platform‑agnostic; superconducting, trapped‑ion, photonic, neutral‑atom systems can all be mapped into LQC/ECD/SECT using public data and well‑known EC models.
Practical next steps
- Publish an annual CRQC Readiness snapshot. For each major platform, estimate LQC, ECD, and SECT using only public, pre‑2021‑compatible inputs (QV trends, RB error rates, EC demos, published cycle times), plus algorithmic baselines from pre‑2021 literature.
- Show sensitivity to assumptions. E.g., how does the score change if physical gate error improves from 10⁻³ to 10⁻⁴, or if the cycle time halves? (Surface‑code analyses make these trade‑offs explicit.)
- Tie to migration triggers. Map score bands to policy guidance (e.g., “<1%: prepare; 1–5%: accelerate pilots; >5%: mandatory PQC for long‑lived data”). Align with NIST timelines and sectoral risk appetites.