TIME UNTIL NIST DEPRECATION OF RSA, ECC, DH-FFC / TARGET 2030-01-01 UTC
Your auditor will ask for a Shor circuit and a T-count. What do you file?
DORA Article 28-30 requires you to file what your third-party ICT register holds. For your public-key assets, that means a signed manifest with the Shor-family attack circuit, the T-count and logical-qubit budget, the per-vendor hardware-year crossover, and the post-quantum migration plan. Per asset. Today.
If X + Y is greater than Z, your secret is already exposed.
Click an asset. The bar updates Y, M, and Z. If Y + M crosses Z, the bar pulses red.
Your assets, today's status
CLICK A LANE TO OPEN THE MIGRATION PLANThe signed manifest
One canonical-JSON manifest per asset. Replayable byte for byte on the deterministic artefacts. Filed as DORA Article 28-30 evidence by the customer; replayed by the auditor.
manifest: { tool_name: "tool-1-cryptanalysis", tool_version: "0.1.0", framework_sha: "dfa7c077...8db80bc7", asset_id: "<customer-supplied>", signed_at: "<ISO 8601 UTC>", } circuits: [ rsa-shor-beauregard.qasm, rsa-shor-gidney.qasm, rsa-shor-regev.qasm, mlkem768-ntt-structural.qasm, mlkem768-intt-structural.qasm ], resource_estimation: { t_count, logical_qubit_count, magic_state_count, code_distance, physical_qubit_count_estimate, physical_error_rate_assumed }, hardware_run_evidence: { vendor, backend_name, job_id, vendor_log_url_or_api_query, shots, calibration_timestamp, seed_transpiler, seed_sampler }, pqc_config: { nist_fips_version: "FIPS 203", kat_hash_expected, kat_hash_observed, passed, hybrid_recommendation }, claims_disambiguation: { did_demonstrate, did_not_demonstrate, marketing_alignment_signed_by }, release_gate: { state: "NDA_only", customer_asset_ownership_attestation_hash, nda_reference }
SHA-256 of the development framework version that produced the manifest. Pins the rules under which the artefact was emitted.
A vendor-API-verifiable identifier and a read-only URL or query the auditor can call. The vendor side holds the tamper-evident record.
Byte-equality verification of FIPS 203 reference encap and decap against the NIST CSRC KAT file. Replayable by the auditor.
The verbatim paragraph that names what the run did and did not demonstrate. Every customer-facing surface echoes it word for word. Anything outside this paragraph cannot be claimed.
The Shor-family attack circuit, three decompositions
Three independent decompositions for the supplied modulus, curve, or group. Different qubit and T-count tradeoffs against the same target. Different rows on the per-vendor crossover.
Shallow modular-exponentiation. 2n+3 qubits.
// Beauregard shallow mod-exp for RSA-N OPENQASM 3; qreg work[n]; qreg phase[2n+1]; qreg ancilla[2]; // Quantum Fourier transform phase register h phase; // Controlled modular exponentiation a^(2^k) mod N for k in [0:2n]: controlled-U_modexp(a^(2^k) mod N) phase[k], work; // Inverse QFT inverse_qft phase; measure phase -> classical_phase;
Windowed arithmetic. Smaller T-count via lookup tables.
// Gidney windowed arithmetic OPENQASM 3; qreg work[n]; qreg window[w]; qreg phase[2n+1]; // Build window tables for a^(2^k) mod N classically // Apply via QROM lookup against precomputed table for stage in [0:n/w]: qrom_lookup window, table[stage], work; windowed_modular_multiplication work, window; // Same QPE backbone h phase; controlled-windowed-U phase, work; inverse_qft phase; measure phase -> classical_phase;
d-dimensional space-time tradeoff. n^1.5 qubits, n^0.5 runs.
// Regev d-dimensional space-time tradeoff OPENQASM 3; qreg work[n^1.5]; // Build d-dimensional lattice // d = O(sqrt(log n)) for run in [0:sqrt(n)]: build_lattice_basis work, d; classical_postprocess_LLL(measure work); // Repeats sqrt(n) times, lattice-reducing post-processing // recovers the factorisation from the run set
QASM excerpts are schematic. Production manifest emits the full source for the supplied asset, with T-count and logical-qubit count computed under a stated physical-error-rate assumption.
Per-vendor hardware-year crossover
Public vendor roadmaps. Each row cites a public source by URL, date fetched, and a verbatim quote supporting the row. Crossover years are the earliest year in the registry where a vendor's published trajectory crosses the logical-qubit budget for the named asset.
| VENDOR | RSA-2048 BUDGET CROSSED | ECC-256 BUDGET CROSSED | CONFIDENCE | PUBLIC SOURCE |
|---|---|---|---|---|
| IBM | 2029 | 2029 | roadmap targets, not measured | IBM 2024 large-scale FTQC roadmap, 200 logical qubits at Starling 2029 |
| Quantinuum | 2029 | 2029 | roadmap targets, not measured | Quantinuum public roadmap, Apollo 2029, hundreds of logical qubits |
| Atom Computing | 2028 | 2028 | roadmap targets, not measured | Microsoft + Atom Computing joint announcement Nov 2024, 1200 logical qubits |
| IonQ | 2030 | 2030 | announced targets | IonQ Vector 2027, 256 algorithmic qubits, photonic interconnect networked traps |
| Pasqal | not in window | not in window | no logical-qubit roadmap row in window | Pasqal Orion beta 2025, 100 physical qubits, no published 2026 to 2030 logical roadmap |
Source registry: deployquantum/data/registries/HW-ROADMAP-REGISTRY.json. Roadmap numbers are vendor-published targets, not measured results. Where a vendor has not published a logical-qubit roadmap within window, the row records the gap.
Hybrid-cipher migration
Anchored to FIPS 203 (ML-KEM-768), FIPS 204 (ML-DSA-65), and FIPS 205 (SLH-DSA). Hybrid by default. Defense in depth at the algorithm-family level, no single-family single point of failure.
KAT-verified pack
ML-KEM-768 NTT and inverse-NTT structural circuits in OpenQASM 3. A verifier that confirms byte equality of FIPS 203 reference encap and decap against the NIST CSRC KAT file. Runs inside your HSM under PKCS11 or on a public quantum cloud.
Questions
1 Does the pair break RSA-2048 on a real quantum processor today?
No. The compiled circuits at cryptographically relevant moduli are emitted as artefacts for resource estimation, not execution. The hardware run on a real QPU is a structural test of the compiler output on a register with at least 25 qubits in the modular-exponentiation register. The manifest disambiguation field states this verbatim. Every customer-facing surface echoes the disambiguation paragraph word for word.
2 How is this different from a post-quantum readiness scan that scores assets?
A scan reads metadata and assigns a score. The pair compiles a quantum object for your specific asset, computes the T-count and logical-qubit budget, reads the per-vendor crossover from a registry of published roadmaps, and emits a KAT-verified test-vector circuit pack the HSM can run. The output is a signed manifest, not a colour-coded chart.
3 Can the manifest be filed as DORA Article 28-30 evidence?
Yes. The manifest carries the framework SHA, the skill SHA, the classical pre and post script hashes, the per-vendor crossover citations, the KAT hash expected versus observed, and the signed disambiguation paragraph. A DORA auditor replays the deterministic artefacts byte for byte and the stochastic ones to within statistical-equivalence bounds.
4 What do you need from us to start?
A signed customer-asset-ownership attestation, the asset itself (RSA modulus DER-encoded, ECC curve identifier, or DH-FFC group parameters), your shelf life, your migration time or the sector default, and the HSM environment for the test-vector packaging. Compilation does not start until the attestation hash is written into the manifest release-gate field.
5 Where do the per-vendor crossover years come from?
A registry of public vendor roadmaps. Each row cites a public source by URL, date fetched, and a verbatim quote supporting the row. The auditor opens the cited source and confirms the row content matches. Where a vendor has not published a logical-qubit roadmap within window, the row records null and names the gap.
Your asset register holds RSA-2048 and ECC-256. The auditor will read this in two years. File a signed manifest today.
FRAMEWORK SHA dfa7c0 / ARTEFACT SHIPS UNDER NDA, SIGNED ATTESTATION REQUIRED