IBM Quantum 백엔드를 /dev/urandom으로 교체

• IBM Quantum 백엔드만 os.urandom으로 바꾼 상태에서도 회로 구성, 오라클, 추출 파이프라인, d·G == Q 검증기를 그대로 유지한 채 개인키 복구가 재현됨
• 수정 범위는 projecteleven.py의 59줄 변경에 그치며, 백엔드 실행과 결과 수집을 제거하고 classical register 폭에 맞춘 균등 난수 비트열을 shots 수만큼 생성해 기존 후속 처리에 넘김
• 4비트부터 10비트까지는 /dev/urandom 실행이 보고된 하드웨어 결과와 바이트 단위로 동일한 d 값을 복구했고, 16비트와 17비트에서도 각각 5회 중 4회, 5회 중 2회 복구에 성공함
• 추출 로직은 각 shot에서 계산한 d_cand = (r − j)·k⁻¹ mod n이 고전적 검증기를 통과할 때만 채택되며, 문서에는 P(≥1 verified hit in S shots) = 1 − (1 − 1/n)^S로 /dev/urandom 성공률이 설명됨
• 여섯 가지 오라클, heavy-hex 매핑, semiclassical phase estimation 같은 비자명한 엔지니어링은 유지되지만, 문서의 비판 범위는 암호해석 주장에 한정되며 하드웨어 실행 결과가 양자 복구가 아니라 고전적 검증으로도 재현됨을 보여줌

diff

• projecteleven.py의 전체 변경은 −29 / +30 lines 규모이며, IBM Quantum 서비스 초기화와 백엔드 실행, 샘플러 호출, 작업 결과 수집 구간을 제거하고 난수 기반 counts 생성으로 대체함
• 추가된 코드는 회로의 classical register 길이를 읽어 동일한 비트 수의 균등 난수 비트열을 shots 개수만큼 만들고, 이를 Counter로 집계해 기존 후속 처리에 그대로 넘김
  • nbits = qc.num_clbits
  • bpb = (nbits + 7) // 8
  • mask = (1 << nbits) - 1
  • 각 shot마다 int.from_bytes(_os.urandom(bpb), "big") & mask로 값을 만든 뒤 지정 폭의 이진 문자열로 변환함
• 전체 59줄 변경 내역은 git diff main에서 확인 가능함

결과: 패치된 상태로 작성자의 CLI 실행

• 동일한 CLI 명령을 그대로 사용해, 하드웨어 대신 /dev/urandom이 공급한 결과만으로 개인키 복구 여부를 점검함
• 문서에 제시된 표는 작성자가 보고한 d 값과 /dev/urandom으로 복구한 d 값을 직접 비교함

• 소형 챌린지, 각 1회 시도, 8,192 shots

  • 실행 명령은 python projecteleven.py --challenge <N> --shots 8192임
  • 전체 출력은 urandom_runs/urandom_challenge_4.txt부터 _10.txt까지 이어짐
  • 4비트에서 10비트까지 모든 항목에서 /dev/urandom이 복구한 d는 작성자가 보고한 하드웨어 결과와 바이트 단위로 동일함
    • 4-bit: 6 → 6, 첫 시도 검증 통과
    • 6-bit: 18 → 18, 첫 시도 검증 통과
    • 8-bit: 103 → 103, 첫 시도 검증 통과
    • 9-bit: 135 → 135, 첫 시도 검증 통과
    • 10-bit: 165 → 165, 첫 시도 검증 통과
  • 문서 기준으로 각 챌린지는 한 번씩 실행됐고, /dev/urandom도 한 번씩 실행됐으며 둘 다 성공함

• 대표 챌린지, 각 5회 시도, 20,000 shots, ripple-carry 오라클

  • 실행 명령은 python projecteleven.py --challenge <N> --oracle ripple --shots 20000임
  • 전체 출력은 urandom_runs/urandom_challenge_16_17_flagship.txt에 정리돼 있음
  • 16비트 챌린지에서는 작성자가 보고한 d = 20,248을 /dev/urandom이 5회 중 4회 복구함
  • 17비트 챌린지에서는 작성자가 보고한 d = 1,441을 /dev/urandom이 5회 중 2회 복구함
  • 문서에는 17비트 결과가 1 BTC를 받은 항목으로 적혀 있고, /dev/urandom이 노트북에서 약 40% 실행에서 이를 복구했다고 적혀 있음
  • 문서에는 작성자가 IBM ibm_fez에서 이 항목을 한 번 실행하고 양자 결과라고 주장했다고 적혀 있음
  • 17비트 실행 예시의 터미널 출력도 그대로 포함됨
    • 곡선: y^2 = x^3 + 0x + 7 (mod 65647)
    • 군 차수: n = 65173
    • 생성원: G = (12976, 52834)
    • 목표점: Q = (477, 58220)
    • 전략: ripple-carry modular addition (CDKM)
    • 백엔드: /dev/urandom
    • classical register 폭: 49 bits
    • 20000 shots에서 Unique outcomes: 20000
    • 결과: d = 1441
    • 검증: 1441*G = (477, 58220)
    • [OK] VERIFIED, [OK] SUCCESS: Recovered correct secret key

왜 이런 결과가 나오는가

• 추출 로직은 ripple_carry_shor.py:197-240와 projecteleven.py:264 기준으로 각 shot의 (j, k, r)를 받아 d_cand = (r − j)·k⁻¹ mod n을 계산한 뒤, 고전적 검증기 d_cand · G == Q를 통과할 때만 받아들임
• 문서는 균등 잡음 아래에서 d_cand가 [0, n) 구간의 균등 분포를 따른다고 두고, S shots에서 검증 성공이 한 번 이상 나올 확률을 다음 식으로 적음
  • P(≥1 verified hit in S shots) = 1 − (1 − 1/n)^S
• 이 식에 문서의 (n, S) 값을 대입한 이론적 /dev/urandom 성공률은 다음과 같음
  • 4-bit: n = 7, shots = 8,192, 100.00%
  • 6-bit: n = 31, shots = 8,192, 100.00%
  • 8-bit: n = 139, shots = 8,192, 100.00%
  • 9-bit: n = 313, shots = 8,192, 100.00%
  • 10-bit: n = 547, shots = 1,024, 84.65%
  • 16-bit: n = 32,497, shots = 20,000, 45.96%
  • 17-bit: n = 65,173, shots = 20,000, 26.43%
• 문서는 위에서 측정한 /dev/urandom의 경험적 성공률이 이 이론값과 맞아떨어진다고 적음
• 같은 저장소의 README.md:210에는 다음 문장이 이미 들어 있다고 적혀 있음
  • "When shots >> n, random noise alone can recover d with high probability."
• 4비트부터 10비트까지 모든 실행에서 shots / n 비율은 1.9×에서 1,170× 사이이며, 문서는 이 전 구간이 작성자 스스로도 고전적 구간으로 식별한 조건에 들어간다고 적혀 있음

재현 방법

• 아래 절차로 같은 브랜치와 환경에서 결과를 재현할 수 있음
  • git checkout urandom-reproduces-qpu
  • uv venv .venv && . .venv/bin/activate
  • uv pip install qiskit qiskit-ibm-runtime
• 실행 예시는 다음과 같음
  • python projecteleven.py --challenge 4 --shots 8192
  • python projecteleven.py --challenge 10 --shots 8192
  • python projecteleven.py --challenge 17 --oracle ripple --shots 20000 # may need 2-3 tries
• 문서에는 IBM 계정, 토큰, 양자 하드웨어, 네트워크가 모두 필요 없다고 적혀 있음

단서와 범위

• 저장소의 구현 자체는 진짜이고 비자명한 엔지니어링으로 평가됨
  • 여섯 가지 오라클 변형이 들어 있음
  • CDKM ripple-carry 가산기를 heavy-hex 토폴로지에 매핑함
  • mid-circuit measurement를 포함한 semiclassical phase estimation을 사용함
• 비판의 범위는 암호해석 주장으로 한정됨
• 문서의 결론은, 이 하드웨어 실행이 양자 컴퓨터에 의한 ECDLP 키 복구가 아니라 균등 난수 후보에 대한 고전적 검증이며, 이 브랜치가 보여주듯 양자 하드웨어 없이도 그대로 재현된다는 데 맞춰져 있음