IBM Quantum backend’ini /dev/urandom ile değiştirmek

 (github.com/yuvadm)
2 puan yazan GN⁺ 4 일 전 | 1 yorum | WhatsApp'ta paylaş
  • Yalnızca IBM Quantum backend’i os.urandom ile değiştirilmiş durumda bile, devre yapısı, oracle, çıkarım hattı ve d·G == Q doğrulayıcısı aynen korunarak özel anahtar kurtarmanın yeniden üretilebildiği gösteriliyor
  • Değişiklik kapsamı projecteleven.py içinde yalnızca 59 satırlık değişiklik ile sınırlı; backend çalıştırma ve sonuç toplama kaldırılıyor, bunun yerine classical register genişliğine uyan eş dağılımlı rastgele bit dizileri shots sayısı kadar üretilip mevcut ardıl işleme veriliyor
  • 4 bitten 10 bite kadar /dev/urandom çalıştırması, raporlanan donanım sonuçlarıyla bayt düzeyinde aynı d değerlerini kurtardı; 16 bit ve 17 bitte de sırasıyla 5 denemenin 4’ünde ve 5 denemenin 2’sinde kurtarma başarılı oldu
  • Çıkarma mantığı, her shot’ta hesaplanan d_cand = (r − j)·k⁻¹ mod n değerini yalnızca klasik doğrulayıcıyı geçtiğinde kabul ediyor; belgede /dev/urandom başarı oranı P(≥1 verified hit in S shots) = 1 − (1 − 1/n)^S ile açıklanıyor
  • Altı farklı oracle, heavy-hex eşlemesi, semiclassical phase estimation gibi önemsiz olmayan mühendislik korunuyor; ancak belgedeki eleştirinin kapsamı kriptoanaliz iddiasıyla sınırlı ve donanım çalıştırma sonuçlarının kuantum kurtarma değil, klasik doğrulama ile de yeniden üretilebildiğini gösteriyor

diff

  • projecteleven.py için toplam değişiklik −29 / +30 satır ölçeğinde; IBM Quantum servis başlatma, backend çalıştırma, sampler çağrısı ve iş sonucu toplama bölümleri kaldırılıp yerlerine rastgelelik tabanlı counts üretimi ekleniyor
  • Eklenen kod, devrenin classical register uzunluğunu okuyup aynı bit sayısında eş dağılımlı rastgele bit dizilerini shots kadar üretiyor, bunları Counter ile sayıp mevcut ardıl işleme aynen aktarıyor
    • nbits = qc.num_clbits
    • bpb = (nbits + 7) // 8
    • mask = (1 << nbits) - 1
    • Her shot için değer int.from_bytes(_os.urandom(bpb), "big") & mask ile oluşturulup belirtilen genişlikte ikili dizgeye dönüştürülüyor
  • Tüm 59 satırlık değişiklik listesi git diff main üzerinden görülebilir

Sonuçlar: Yamanmış durumda yazarın CLI çalıştırmaları

  • Donanım yerine yalnızca /dev/urandom tarafından sağlanan sonuçlarla, aynı CLI komutları değiştirilmeden kullanılarak özel anahtar kurtarmanın olup olmadığı kontrol edildi
  • Belgede verilen tablo, yazarın raporladığı d değerleri ile /dev/urandom ile kurtarılan d değerlerini doğrudan karşılaştırıyor

  • Küçük challenge’lar, her biri 1 deneme, 8.192 shots

    • Çalıştırma komutu python projecteleven.py --challenge <N> --shots 8192
    • Tam çıktı urandom_runs/urandom_challenge_4.txt dosyasından _10.txt dosyasına kadar uzanıyor
    • 4 bitten 10 bite kadar tüm girdilerde /dev/urandom ile kurtarılan d, yazarın raporladığı donanım sonucu ile bayt düzeyinde aynı
      • 4-bit: 6 → 6, ilk denemede doğrulama geçti
      • 6-bit: 18 → 18, ilk denemede doğrulama geçti
      • 8-bit: 103 → 103, ilk denemede doğrulama geçti
      • 9-bit: 135 → 135, ilk denemede doğrulama geçti
      • 10-bit: 165 → 165, ilk denemede doğrulama geçti
    • Belgeye göre her challenge bir kez, /dev/urandom da bir kez çalıştırıldı ve iki taraf da başarılı oldu

  • Amiral gemisi challenge’lar, her biri 5 deneme, 20.000 shots, ripple-carry oracle

    • Çalıştırma komutu python projecteleven.py --challenge <N> --oracle ripple --shots 20000
    • Tüm çıktı urandom_runs/urandom_challenge_16_17_flagship.txt içinde derlenmiş durumda
    • 16 bit challenge’da yazarın raporladığı d = 20,248 değeri /dev/urandom tarafından 5 denemenin 4’ünde kurtarıldı
    • 17 bit challenge’da yazarın raporladığı d = 1,441 değeri /dev/urandom tarafından 5 denemenin 2’sinde kurtarıldı
    • Belgede 17 bit sonucu 1 BTC alınan girdi olarak geçiyor ve /dev/urandom’un bunu bir dizüstü bilgisayarda çalıştırmaların yaklaşık %40’ında kurtardığı yazıyor
    • Belgede ayrıca yazarın bu girdiyi IBM ibm_fez üzerinde bir kez çalıştırıp sonucu kuantum çıktısı olarak sunduğu belirtiliyor
    • 17 bit çalıştırmasına ait terminal çıktısı örneği de aynen veriliyor
      • Eğri: y^2 = x^3 + 0x + 7 (mod 65647)
      • Grup mertebesi: n = 65173
      • Üreteç: G = (12976, 52834)
      • Hedef nokta: Q = (477, 58220)
      • Strateji: ripple-carry modular addition (CDKM)
      • Backend: /dev/urandom
      • classical register genişliği: 49 bits
      • 20000 shots içinde Unique outcomes: 20000
      • Sonuç: d = 1441
      • Doğrulama: 1441*G = (477, 58220)
      • [OK] VERIFIED, [OK] SUCCESS: Recovered correct secret key

Bu sonuçlar neden çıkıyor

  • Çıkarma mantığı, ripple_carry_shor.py:197-240 ve projecteleven.py:264 temelinde her shot’ın (j, k, r) değerlerini alıp d_cand = (r − j)·k⁻¹ mod n hesaplıyor, ardından bunu yalnızca klasik doğrulayıcı d_cand · G == Q koşulunu geçerse kabul ediyor
  • Belgede, eş dağılımlı gürültü altında d_cand değerinin [0, n) aralığında eş dağılımlı olduğu varsayılıyor ve S shots içinde en az bir doğrulanmış başarının gelme olasılığı şu formülle veriliyor
    • P(≥1 verified hit in S shots) = 1 − (1 − 1/n)^S
  • Bu formüle belgede verilen (n, S) değerleri yerleştirildiğinde, teorik /dev/urandom başarı oranları şöyle oluyor
    • 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%
  • Belgede, yukarıda ölçülen /dev/urandom ampirik başarı oranlarının bu teorik değerlerle uyuştuğu belirtiliyor
  • Aynı depodaki README.md:210 içinde şu cümlenin zaten yer aldığı da aktarılıyor
    • "When shots >> n, random noise alone can recover d with high probability."
  • 4 bitten 10 bite kadar tüm çalıştırmalarda shots / n oranı 1,9× ile 1.170× arasında; belgeye göre bu aralığın tamamı, yazarın da klasik bölge olarak tanımladığı koşullara giriyor

Nasıl yeniden üretilir

  • Sonuçlar aynı branch ve ortamda aşağıdaki adımlarla yeniden üretilebilir
    • git checkout urandom-reproduces-qpu
    • uv venv .venv && . .venv/bin/activate
    • uv pip install qiskit qiskit-ibm-runtime
  • Çalıştırma örnekleri şöyle
    • 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
  • Belgede IBM hesabı, token, kuantum donanımı ve ağ bağlantısı gerekmediği belirtiliyor

İpuçları ve kapsam

  • Depodaki uygulamanın kendisi gerçek ve önemsiz olmayan bir mühendislik olarak değerlendiriliyor
    • Altı farklı oracle varyantı içeriyor
    • CDKM ripple-carry toplayıcısını heavy-hex topolojisine eşliyor
    • mid-circuit measurement içeren semiclassical phase estimation kullanıyor
  • Eleştirinin kapsamı kriptoanaliz iddiası ile sınırlı
  • Belgenin vardığı sonuç, bu donanım çalıştırmasının kuantum bilgisayar aracılığıyla ECDLP anahtar kurtarma değil, eş dağılımlı rastgele adaylar üzerinde klasik doğrulama olduğu; bu branch’in de gösterdiği gibi kuantum donanımı olmadan da birebir yeniden üretilebildiği yönünde

İlgili okumalar

1 yorum

 
GN⁺ 4 일 전
Hacker News yorumları
  • Bu, benim 2025 sigbovik 1 Nisan şaka makalesinde tam olarak ortaya koyduğum varsayımla aynı. Küçük sayılarda Shor algoritmasına rastgele örnekler verseniz bile kısa sürede başarıya ulaşıyor; devre çok uzayıp kuantum bilgisayarın hata oranı sınırını aşınca da fiilen bir rastgele sayı üreteci gibi davranıyor.
    Bu yüzden dışarıdan bakınca “doğru sonuç” üretiyor gibi görünse bile nedeni tamamen yanlış olabilir. Tam da bu nedenle küçük tamsayı çarpanlara ayırma ya da küçük ECDLP örnekleri, kuantum bilişimdeki ilerlemeyi ölçmek için uygun benchmark’lar değil.
    Bunun olacağı konusunda project11 tarafını uyarmıştım. Sonunda, kuantum bilgisayarın katkıda bulunmadığı gerçeğini en iyi gizleyen kişiye bitcoin verileceğini düşünüyordum; gönderimi yapan kişinin de muhtemelen kendisini kandırmış olabileceğini sanıyordum. Galiba bunu ciddiye almadılar.
    [1]: https://sigbovik.org/2025/proceedings.pdf#page=146
  • Project Eleven az önce bunu ECC’ye yönelik şimdiye kadarki en büyük kuantum saldırı diyerek 1 BTC ile ödüllendirdi; IBM Quantum donanımıyla 17 bitlik eliptik eğri anahtarının kurtarıldığı söyleniyordu. Ama Yuval Adam kuantum bilgisayarı /dev/urandom ile değiştirince de anahtar aynı şekilde kurtarılıyor
    • Yine de kuantum donanımının bunu daha hızlı yapıp yapmadığına bakmak gerekmez mi
  • Challenge’ı kazanan kişinin paylaştığı kod oldukça yanıltıcı bir kod gibi görünüyor, üstelik kişinin kuantum bilişim geçmişi de hiç yokmuş gibi duruyor
    Özgeçmişinde enterprise software, full-stack architecture, cloud native, solution architecture ve sales engineering var; commit geçmişine bakınca da bu iş neredeyse tam bir vibe coded vakası gibi görünüyor: https://github.com/GiancarloLelli/quantum
    • Evet. Okur okumaz vibe coding’e özgü izler fazlasıyla gözüme çarptı; benim de aklıma ilk gelen buydu
  • Bu, kuantum bilişimin kendisini hedef alan bir eleştiri değil; project11’i ve belki de gönderimi yapan tarafı eleştiriyor. Gönderimi düzgün doğrulamamışlar ve kod zaten çözümün klasik bir yöntem olduğunu gösteriyor
    17 bitlik ECC anahtarını kurtarmak bugün klasik bilgisayarlarda brute force ile hiç zor değil
    • Çözüm rastgele denemeden daha hızlıysa, yine de kuantum bilgisayar üzerinde gerçek bir çözüm olma ihtimali kalır
  • Bu haberin küçük görselindeki kırpma gerçekten talihsiz olacak kadar kusursuz: https://image.non.io/b3f69546-aeb3-48c3-a76d-723f29b28f48.webp

    • contains the code and submission

      Mükemmel

    • Ben mi başka bir şeye bakıyorum bilmiyorum ama bu bayağı quan(tumslop) içindeki t gibi duruyor

    • Bu gerçekten sanat

    • Biraz iğrenç

  • dequantization, kuantum bilgi alanında gerçekten var olan ve son derece meşru bir araştırma konusu. Bir şeyin gerçekten kuantum mu yoksa göz boyama mı olduğunu ayırt etmede faydalı ve kuantum ile klasik arasındaki sınırın nerede olduğunu anlamaya yardımcı oluyor
    Yakın zamanda çıkan başka dequantized sonuçlar da var: https://arxiv.org/abs/2604.21908
  • 17 bitlik anahtar, yalnızca 131072 olasılık içerdiği için brute force ile fazlasıyla kolay kırılır. Bunu kuantum bilgisayarla kırmak en fazla bir fizik gösterimine benzer; faydalı bir hesaplama işi yapma girişiminden oldukça uzaktır
    • Buradaki asıl nokta, özgün çözümdeki kuantum bilgisayar kısmının hiçbir şey yapmıyor olması. Yani tüm algoritma gerçekte bir kuantum algoritması değil, klasik olasılıksal bir algoritma
      Kuantum bilgisayar kritik olsaydı, RNG ile değiştirildiğinde doğru cevap çıkmamalıydı ya da en azından yakınsama hızı düşmeliydi. Ama sonuç tamamen aynı olduğuna göre, gerçek mantığın tamamı klasik taraftaymış ve QC yalnızca gürültü eklemiş
    • Yanılıyor olabilirim ama asıl amaç brute force’tan daha hızlı olmak değil mi
      Sonuç istatistiksel olarak tahminden ayırt edilemiyorsa, sonunda sadece karmaşık bir Rube Goldberg düzeneği kurulmuş gibi görünüyor
    • Eğer QC’nin katkısı bir rastgele sayı üretecinden ayırt edilemiyorsa, ortada tam olarak neyin gösterildiğini anlamıyorum
  • quantum grifting kripto tarafına da sert şekilde girmiş durumda
    Dolandırıcılar ya çökmüş eski coin’leri yeniden ortaya çıkarıyor ya da yeni coin’ler yaratıyor; sonra bunları toplayıp ya da ihraç edip üstüne ML-DSA ekleyerek kuantuma dayanıklı diye pazarlıyor, böylece shitcoin’i pump edip sonra boşaltabiliyorlar
    Günün birinde bilgi seviyesi düşük bireysel yatırımcılar da bunu fark edecektir ama açıkçası şu anda bunun tam olarak kimde karşılık bulduğunu ben de bilmiyorum
    • Asıl hedef kitlenin anadili İngilizce olmayan insanlar olması daha da üzücü
  • İki uygulamada QM çağrı sayısının birbiriyle uyuşup uyuşmadığı da kontrol edilmeli
  • Bence kuantum bilişim 30 yıllık bir dolandırıcılık
    Google bile kendi kuantum bilgisayarlarının düzgün çalıştığını kanıtlayamadı; algoritmalar da aşırı derecede zayıflatılıp elde 17 bit gibi şeylerle kalındı