IBM Quantum backend को /dev/urandom से बदलना

• केवल IBM Quantum backend को os.urandom से बदलने पर भी circuit construction, oracle, extraction pipeline, और d·G == Q verifier को जस का तस रखते हुए private key recovery दोबारा reproduce की गई
• बदलाव की सीमा projecteleven.py में केवल 59 lines changed तक सीमित है; backend execution और result collection हटाकर classical register width के अनुरूप uniform random bitstrings को shots की संख्या जितनी बार बनाकर मौजूदा downstream processing को दिया गया
• 4-bit से 10-bit तक /dev/urandom रन ने रिपोर्ट किए गए hardware results के साथ byte-for-byte identical d values recover किए, और 16-bit व 17-bit में भी क्रमशः 5 में 4 बार और 5 में 2 बार recovery सफल रही
• extraction logic हर shot में निकाले गए d_cand = (r − j)·k⁻¹ mod n को तभी स्वीकार करता है जब वह classical verifier को पार कर जाए; दस्तावेज़ में /dev/urandom की success rate को P(≥1 verified hit in S shots) = 1 − (1 − 1/n)^S से समझाया गया है
• six oracles, heavy-hex mapping, और semiclassical phase estimation जैसी गैर-तुच्छ engineering बनी रहती है, लेकिन दस्तावेज़ की आलोचना केवल cryptanalysis claim तक सीमित है, और यह दिखाती है कि hardware execution के नतीजे quantum recovery नहीं बल्कि classical verification से भी reproduce हो सकते हैं

---

diff

• projecteleven.py में कुल बदलाव −29 / +30 lines के पैमाने पर हैं; IBM Quantum service initialization, backend execution, sampler call, और job result collection वाले हिस्से हटाकर random-based counts generation से बदले गए हैं
• जोड़ा गया code circuit की classical register length पढ़ता है, उसी bit-width की uniform random bitstrings को shots बार बनाता है, और उन्हें Counter में aggregate करके पहले की downstream processing को वैसा ही देता है
  • nbits = qc.num_clbits
  • bpb = (nbits + 7) // 8
  • mask = (1 << nbits) - 1
  • हर shot पर int.from_bytes(_os.urandom(bpb), "big") & mask से value बनाई जाती है और फिर उसे निर्धारित width की binary string में बदला जाता है
• पूरे 59-line बदलाव को git diff main में देखा जा सकता है

परिणाम: patch किए गए state में लेखक का CLI run

• वही CLI command ज्यों का त्यों इस्तेमाल करके, hardware की जगह केवल /dev/urandom से मिले results के आधार पर private key recovery की जाँच की गई
• दस्तावेज़ में दी गई तालिका लेखक द्वारा रिपोर्ट किए गए d values और /dev/urandom से recover हुए d values की सीधी तुलना करती है

• छोटे challenge, प्रत्येक में 1 प्रयास, 8,192 shots

  • run command है python projecteleven.py --challenge <N> --shots 8192
  • पूरा output urandom_runs/urandom_challenge_4.txt से _10.txt तक जारी है
  • 4-bit से 10-bit तक हर entry में /dev/urandom से recover हुआ d, लेखक द्वारा रिपोर्ट किए गए hardware result के byte-for-byte identical है
    • 4-bit: 6 → 6, पहला प्रयास verification pass
    • 6-bit: 18 → 18, पहला प्रयास verification pass
    • 8-bit: 103 → 103, पहला प्रयास verification pass
    • 9-bit: 135 → 135, पहला प्रयास verification pass
    • 10-bit: 165 → 165, पहला प्रयास verification pass
  • दस्तावेज़ के अनुसार हर challenge एक-एक बार चलाया गया, /dev/urandom भी एक-एक बार चलाया गया, और दोनों सफल रहे

• प्रमुख challenge, प्रत्येक में 5 प्रयास, 20,000 shots, ripple-carry oracle

  • run command है python projecteleven.py --challenge <N> --oracle ripple --shots 20000
  • पूरा output urandom_runs/urandom_challenge_16_17_flagship.txt में संकलित है
  • 16-bit challenge में लेखक द्वारा रिपोर्ट किया गया d = 20,248, /dev/urandom ने 5 में 4 बार recover किया
  • 17-bit challenge में लेखक द्वारा रिपोर्ट किया गया d = 1,441, /dev/urandom ने 5 में 2 बार recover किया
  • दस्तावेज़ में 17-bit result को 1 BTC पाने वाली entry बताया गया है, और लिखा है कि /dev/urandom ने laptop पर लगभग 40% runs में इसे recover किया
  • दस्तावेज़ में लिखा है कि लेखक ने इस entry को IBM ibm_fez पर एक बार चलाया और इसे quantum result बताया
  • 17-bit run का terminal output example भी ज्यों का त्यों शामिल है
    • curve: y^2 = x^3 + 0x + 7 (mod 65647)
    • group order: n = 65173
    • generator: G = (12976, 52834)
    • target point: Q = (477, 58220)
    • strategy: ripple-carry modular addition (CDKM)
    • backend: /dev/urandom
    • classical register width: 49 bits
    • 20000 shots में Unique outcomes: 20000
    • result: d = 1441
    • verification: 1441*G = (477, 58220)
    • [OK] VERIFIED, [OK] SUCCESS: Recovered correct secret key

ऐसे परिणाम क्यों आते हैं

• extraction logic ripple_carry_shor.py:197-240 और projecteleven.py:264 के अनुसार हर shot के (j, k, r) को लेकर d_cand = (r − j)·k⁻¹ mod n निकालती है, और classical verifier d_cand · G == Q को pass करने पर ही उसे स्वीकार करती है
• दस्तावेज़ मानता है कि uniform noise के तहत d_cand, [0, n) interval पर uniform distribution का पालन करता है, और S shots में कम-से-कम एक verification success आने की probability को इस formula से लिखता है
  • P(≥1 verified hit in S shots) = 1 − (1 − 1/n)^S
• इस formula में दस्तावेज़ के (n, S) values रखने पर /dev/urandom की सैद्धांतिक success rate इस प्रकार बनती है
  • 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 की empirical success rate इस theoretical value से मेल खाती है
• उसी repository की README.md:210 में यह पंक्ति पहले से मौजूद बताई गई है
  • "When shots >> n, random noise alone can recover d with high probability."
• 4-bit से 10-bit तक हर run में shots / n ratio 1.9× से 1,170× के बीच है, और दस्तावेज़ कहता है कि यह पूरा range उन conditions में आता है जिन्हें लेखक ने स्वयं classical regime के रूप में पहचाना था

पुनरुत्पादन का तरीका

• नीचे की प्रक्रिया से उसी branch और environment में परिणाम reproduce किए जा सकते हैं
  • git checkout urandom-reproduces-qpu
  • uv venv .venv && . .venv/bin/activate
  • uv pip install qiskit qiskit-ibm-runtime
• run examples इस प्रकार हैं
  • 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 account, token, quantum hardware, और network — इनमें से किसी की भी ज़रूरत नहीं है

संकेत और दायरा

• repository की implementation स्वयं वास्तविक और गैर-तुच्छ engineering मानी गई है
  • इसमें six oracle variants शामिल हैं
  • यह CDKM ripple-carry adder को heavy-hex topology पर map करती है
  • यह mid-circuit measurement सहित semiclassical phase estimation का उपयोग करती है
• आलोचना का दायरा केवल cryptanalysis claim तक सीमित है
• दस्तावेज़ का निष्कर्ष यह है कि यह hardware execution quantum computer द्वारा ECDLP key recovery नहीं, बल्कि uniform random candidates पर classical verification है, और यह branch दिखाती है कि वही चीज़ quantum hardware के बिना भी वैसी ही reproduce की जा सकती है

[GN⁺]

Hacker News की राय

• यह ठीक वही मान्यता है जिसे मैंने 2025 sigbovik April Fools paper में स्पष्ट रूप से रखा था। छोटे संख्याओं पर Shor algorithm में random sample डालने पर भी जल्दी सफलता मिल जाती है, और जब circuit इतना लंबा हो जाता है कि quantum computer की error rate सीमा पार कर दे, तो वह असल में random number generator की तरह काम करता है।
  इसलिए ऊपर-ऊपर से "सही परिणाम" मिलने पर भी वजह पूरी तरह गलत हो सकती है। इसी कारण छोटे integer factorization या छोटे ECDLP उदाहरण quantum computing की प्रगति मापने के लिए उपयुक्त benchmark नहीं हैं।
  मैंने project11 को पहले ही चेतावनी दी थी कि ऐसा होगा। मुझे लगा था कि आखिर में Bitcoin उस व्यक्ति को मिलेगा जो यह तथ्य सबसे अच्छी तरह छिपा दे कि quantum computer ने कोई योगदान ही नहीं दिया, और मुझे यह भी लगा कि submitter खुद भी शायद अपने ही भ्रम में आ गया हो। शायद इसे गंभीरता से नहीं लिया गया।
  [1]: https://sigbovik.org/2025/proceedings.pdf#page=146
• Project Eleven ने अभी ECC पर अब तक का सबसे बड़ा quantum attack बताकर 1 BTC दिया, दावा यह था कि IBM Quantum hardware से 17-bit elliptic curve key recover की गई। लेकिन Yuval Adam ने quantum computer को /dev/urandom से बदल दिया और key फिर भी recover हो गई
  • फिर भी क्या यह नहीं देखना चाहिए कि quantum hardware इसे ज़्यादा तेज़ी से करता है या नहीं
• इस challenge को जीतने वाले व्यक्ति का डाला हुआ code काफ़ी भ्रम पैदा करने वाला code लगता है, और खुद उस व्यक्ति का quantum computing background लगभग न के बराबर दिखता है
  परिचय भी enterprise software, full-stack architecture, cloud native, solution architecture और sales engineering का है, और commit history देखें तो यह लगभग vibe coded जैसा लगता है: https://github.com/GiancarloLelli/quantum
  • हाँ। पढ़ते ही vibe coding के बहुत सारे पहचानने लायक निशान दिख गए, और मेरे दिमाग में भी सबसे पहले यही बात आई
• यह quantum computing पर हमला नहीं है, बल्कि project11 और शायद submitter पर हमला है। उन्होंने submission verification ठीक से नहीं की, और code पहले से ही दिखाता है कि समाधान classical method है
  17-bit ECC key recovery आज के classical computer पर brute force से बिल्कुल भी मुश्किल नहीं है
  • अगर समाधान random से तेज़ है, तो फिर भी यह quantum computer पर चलने वाला वास्तविक समाधान हो सकता है
• इस लेख का thumbnail crop कमाल की हद तक बदकिस्मत है: https://image.non.io/b3f69546-aeb3-48c3-a76d-723f29b28f48.webp

  • contains the code and submission

    परफ़ेक्ट

  • हो सकता है मैं कुछ और देख रहा हूँ, लेकिन यह साफ़ तौर पर quan(tumslop) का t लगता है

  • यह सचमुच कला है

  • थोड़ा घिनौना है

• dequantization वास्तव में quantum information research का एक बिल्कुल वैध विषय है। यह पता लगाने में उपयोगी है कि कोई चीज़ सचमुच quantum है या सिर्फ़ धुआँ-पर्दा, और quantum तथा classical की सीमा कहाँ है इसे समझने में मदद करता है
  हाल की एक और dequantized result भी है: https://arxiv.org/abs/2604.21908
• 17-bit key में कुल सिर्फ़ 131072 संभावनाएँ होती हैं, इसलिए brute force से इसे तोड़ना बहुत आसान है। इसे quantum computer से तोड़ना ज़्यादा से ज़्यादा एक physical demonstration जैसा है, उपयोगी computation करने की कोशिश से इसका दूर-दूर तक संबंध नहीं है
  • यहाँ असली बात यह है कि मूल समाधान का quantum computer वाला हिस्सा कुछ भी नहीं कर रहा। यानी पूरा algorithm वास्तव में quantum algorithm नहीं बल्कि classical probabilistic algorithm है
    अगर quantum computer अहम होता, तो RNG से बदलने पर या तो सही जवाब नहीं आता या कम से कम convergence धीमी होती। लेकिन नतीजे बिल्कुल वही रहे, तो असली logic पूरी तरह classical side पर थी और QC ने सिर्फ़ noise जोड़ा
  • हो सकता है मुझे पूरी बात न पता हो, लेकिन मूल उद्देश्य क्या brute force से तेज़ होना नहीं था
    अगर नतीजे सांख्यिकीय रूप से guess से अलग नहीं हैं, तो आखिर में यह बस एक जटिल Rube Goldberg machine ही लगती है
  • अगर QC का योगदान random number generator से अलग ही नहीं किया जा सकता, तो फिर समझ नहीं आता कि आखिर दिखाया क्या गया
• quantum grifting अब crypto दुनिया में भी ज़ोर से घुस आया है
  ठग लोग किसी मरे हुए पुराने coin को खींच लाते हैं या नया coin बना लेते हैं, फिर उसे खरीदकर या mint करके उसमें ML-DSA जोड़ देते हैं और quantum-safe कहकर प्रचार करते हैं, फिर shitcoin को pump करके dump कर देते हैं
  कभी न कभी कम जानकारी वाले retail investor भी समझ जाएँगे, लेकिन सच कहूँ तो अभी यह किस पर चल रहा है, यह भी समझ नहीं आता
  • यह और भी दुखद है क्योंकि लगता है कि मुख्य target non-native English speakers हैं
• यह भी जाँचना चाहिए कि दोनों implementations में QM call count एक-दूसरे से मेल खाती है या नहीं
• मेरे हिसाब से quantum computing 30 साल पुराना scam है
  Google तक यह साबित नहीं कर पाया कि उसका quantum computer ठीक से काम करता है, और algorithms को भी इतना कमज़ोर करना पड़ रहा है कि बात 17-bit जैसी चीज़ों तक आ गई है
  • क्या Google ने हाल ही में verifiable quantum advantage report नहीं किया था
    https://blog.google/innovation-and-ai/technology/research/quantum-echoes-willow-verifiable-quantum-advantage/
  • संभावना तो है, लेकिन AI bubble फूटने के बाद यह अगला stock market slop बन सकता है
    जगह-जगह किसी अजीब से $10 billion random number generator पर बेहिसाब पैसा झोंकते लोग दिख सकते हैं