IBM Quantumバックエンドを/dev/urandomに置き換え
(github.com/yuvadm)- 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の成功率を説明している - 6種類のオラクル、heavy-hexマッピング、semiclassical phase estimationのような非自明なエンジニアリングは維持されているが、文書の批判範囲は暗号解析の主張に限定され、ハードウェア実行結果が量子的復元ではなく古典的検証でも再現できることを示している
diff
projecteleven.pyの変更全体は**−29 / +30 lines**規模で、IBM Quantumサービス初期化、バックエンド実行、サンプラー呼び出し、ジョブ結果収集の区間を削除し、乱数ベースのcounts生成に置き換えている- 追加コードは回路のclassical register長を読み取り、同じビット数の一様乱数ビット列を
shots個生成し、これをCounterで集計して既存の後続処理へそのまま渡すnbits = qc.num_clbitsbpb = (nbits + 7) // 8mask = (1 << nbits) - 1- 各shotごとに
int.from_bytes(_os.urandom(bpb), "big") & maskで値を作り、指定幅の2進文字列へ変換する
- 全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、初回試行で検証通過
- 文書ベースでは各チャレンジは1回ずつ実行され、
/dev/urandomも1回ずつ実行され、どちらも成功している
- 実行コマンドは
-
代表チャレンジ、各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がノートPC上で約40%の実行でこれを復元したと書かれている - 文書では作成者がIBM
ibm_fezでこの項目を1回実行し、量子結果だと主張したと記されている - 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)区間の一様分布に従うとし、Sshotsで検証成功が1回以上起こる確率を次式で示している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%
- 4-bit:
- 文書では、上で測定した
/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-qpuuv venv .venv && . .venv/bin/activateuv pip install qiskit qiskit-ibm-runtime
- 実行例は次の通り
python projecteleven.py --challenge 4 --shots 8192python projecteleven.py --challenge 10 --shots 8192python projecteleven.py --challenge 17 --oracle ripple --shots 20000 # may need 2-3 tries
- 文書ではIBMアカウント、トークン、量子ハードウェア、ネットワークはいずれも不要だと書かれている
手がかりと範囲
- リポジトリ実装そのものは本物で非自明なエンジニアリングとして評価されている
- 6種類のオラクル変種が含まれている
- CDKM ripple-carry加算器をheavy-hexトポロジにマッピングしている
- mid-circuit measurementを含むsemiclassical phase estimationを使用している
- 批判の範囲は暗号解析の主張に限定される
- 文書の結論は、このハードウェア実行は量子コンピュータによるECDLP鍵復元ではなく、一様乱数候補に対する古典的検証であり、このブランチが示す通り量子ハードウェアなしでもそのまま再現できる、という点にある
1件のコメント
Hacker News のコメント
だから見かけ上は「正しい結果」を出していても、その理由はまったく間違っている可能性がある。こういう理由から、小さな整数因数分解や小さな ECDLP の例は、量子コンピューティングの進展を測るベンチマークとして不適切。
私はこういうことが起きると project11 側に警告していた。結局は、量子コンピュータが寄与していなかったという事実をいちばんうまく隠した人にビットコインが渡ることになるだろうと思っていたし、投稿者本人も自分で自分をだましていた可能性が高いと思っていた。たぶん真剣には受け取られなかったのだろう。
[1]: https://sigbovik.org/2025/proceedings.pdf#page=146
/dev/urandomに置き換えても、同じように鍵が復元できることを示した自己紹介もエンタープライズソフトウェア、フルスタックアーキテクチャ、クラウドネイティブ、ソリューションアーキテクチャ、セールスエンジニアリング方面で、コミット履歴を見るとこれはほぼvibe codedに見える: https://github.com/GiancarloLelli/quantum
17ビット ECC 鍵の復元は、今なら古典コンピュータでも総当たりでまったく難しくない
完璧
私が別のものを見ているのかもしれないが、あれは明らかにquan(tumslop) の
tに見えるこれは本当に芸術
ちょっと気持ち悪い
最近出た別の dequantized な結果もある: https://arxiv.org/abs/2604.21908
量子コンピュータが本質的だったなら、RNG に置き換えたときに正解が出ないか、少なくとも収束速度は遅くなるはずだった。ところが結果が完全に同じなので、実際のロジックはすべて古典側にあり、QC はノイズを足しただけだったことになる
結果が統計的に推測と見分けがつかないなら、結局は複雑なRube Goldberg 装置を作っただけに見える
詐欺師たちは死んだ古いコインを引っ張り出すか新しいコインを作り、買い集めたり発行したりしたうえでML-DSAを付け足し、量子安全だと宣伝してクソコインを吊り上げ、その後で売り抜けることができる
いつかは情報の少ない個人投資家も気づくだろうが、正直なところ今これが誰に効いているのかもよく分からない
Google でさえ自社の量子コンピュータがきちんと動いていることを証明できておらず、アルゴリズムも極端に弱めて17ビットのようなものを持ち出してくるレベル
https://blog.google/innovation-and-ai/technology/research/quantum-echoes-willow-verifiable-quantum-advantage/
あちこちで正体不明の100億ドルの乱数生成器に法外な金が注ぎ込まれることになりそうだ