Replacing the IBM Quantum Backend with /dev/urandom

After swapping the IBM Quantum backend in projecteleven.py for /dev/urandom, private key recovery was reproduced while keeping the circuit construction, oracle, extraction pipeline, and d·G == Q verification unchanged.

The modification was about 59 lines: instead of executing the backend and collecting results, it generated uniformly random bit strings matching the circuit's classical register width for the given number of shots, and fed them into the existing downstream processing.

The reproduction results were as follows.

• For 4-bit to 10-bit challenges, the /dev/urandom results recovered byte-for-byte identical d values to the reported hardware results.
• For the 16-bit challenge, recovery succeeded in 4 out of 5 runs, and for the 17-bit challenge, in 2 out of 5 runs.
• In one 17-bit example, the output showed 20000 shots, Unique outcomes: 20000, d = 1441, 1441*G = (477, 58220), and was marked VERIFIED.

The extraction logic computes d_cand = (r − j)·k⁻¹ mod n for each shot, and only accepts it when it passes the classical verifier d_cand · G == Q. The document explains that because of this structure, even uniform noise alone can produce a correct answer with probability P(≥1 verified hit in S shots) = 1 − (1 − 1/n)^S.

The conclusion is that the hardware run in question is closer to classical verification of uniformly random candidates than actual ECDLP recovery by quantum hardware, and that the result is reproducible as-is with /dev/urandom. However, it adds that the implementation itself—the six oracles, heavy-hex mapping, and semiclassical phase estimation—remains nontrivial.