मैंने 90 के दशक की एक Certificate Authority की RSA कुंजियों का factor निकाल लिया

मूल लेख ↗ Hacker News चर्चा ↗

1990s की एक Certificate Authority से 512-bit RSA कुंजी का आधुनिक consumer hardware पर factor निकलना यह दिखाता है कि legacy “export-grade” cryptography कितनी कमज़ोर हो चुकी है और ऐतिहासिक encrypted traffic की दीर्घकालिक गोपनीयता पर सवाल उठाता है। टिप्पणीकार 512-, 1024-, और 2048-bit RSA कुंजियों को तोड़ने की लागत की तुलना करते हैं, समझाते हैं कि factoring algorithms और GPUs में प्रगति से 1024-bit RSA अच्छी तरह संसाधनयुक्त actors के लिए संभव हो सकता है, और नोट करते हैं कि सममित algorithms कहीं अधिक प्रतिरोधी बने रहते हैं। यह चर्चा government-mandated weak crypto के इतिहास, मज़बूत और post-quantum TLS की ओर बदलाव, और सुरक्षा-संवेदनशील काम में AI-generated code तथा custom TLS implementations पर निर्भरता की चिंताओं को भी छूती है।

RSA कुंजी की मज़बूती और factor निकालने की व्यवहार्यता

  • कई टिप्पणियाँ इस बात पर चर्चा करती हैं कि factor निकालने की लागत कैसे बढ़ती है:
    • सममित कुंजियाँ प्रभावी रूप से हर अतिरिक्त बिट पर काम को दोगुना कर देती हैं; RSA प्रति बिट कमज़ोर है क्योंकि factoring sub-exponential है (जैसे, General Number Field Sieve)।
    • उद्धृत अनुमान: 1024-bit RSA का factor निकालने के लिए ~2000 GPU-वर्ष; 2048-bit RSA को वर्तमान तकनीकों के साथ सैकड़ों हज़ार से लाखों वर्षों का माना गया है।
    • 2048-bit RSA को अक्सर ~112 बिट सममित सुरक्षा के बराबर माना जाता है; 3072-bit RSA को ~128 बिट के बराबर।
  • लगभग 2 दिनों में consumer hardware पर 512-bit कुंजी का factor निकालना ऐतिहासिक अनुमानों के अनुरूप माना जाता है।
  • कुछ लोग यह भी बताते हैं कि सिर्फ़ raw compute नहीं, बल्कि memory और matrix steps भी बड़ी बाधाएँ हैं।

Quantum computing और भविष्य का जोखिम

  • Shor’s algorithm को RSA के लिए सैद्धांतिक अंत माना गया है, लेकिन पर्याप्त stable qubits वाले व्यावहारिक quantum hardware को अभी भी बहुत दूर माना जाता है।
  • कुछ लोग “stable qubit” trends की RSA cost के साथ तुलना करने का सुझाव देते हैं; उनका intersection स्पष्ट नहीं है।

TLS, पुराने browsers, और custom crypto

  • आधुनिक TLS libraries ने SSLv3, SSLv2 client hellos, और export ciphers को हटा दिया है; लेख के author ने Netscape 4.x से बात करने के लिए एक minimal SSLv3 stack (RC4, DES/3DES, MD5, SHA‑1) लागू किया।
  • अन्य लोग “retro internet” services को support करने के लिए इसी तरह के प्रयास बताते हैं, जिनके लिए अक्सर custom OpenSSL builds की ज़रूरत पड़ती है।

Export-grade crypto और ऐतिहासिक नीति

  • Export-grade 512-bit RSA और 40-bit symmetric ciphers जानबूझकर कमज़ोर थे ताकि agencies उन्हें decrypt कर सकें।
  • 1990s browsers में root certificate slots को monetized किया गया था, और incumbents की तरफ़ से competition सीमित करने का दबाव था।
  • कुछ लोग राष्ट्रीय नियमों (जैसे forced key escrow, bit-length caps) को याद करते हैं।

AI tools (“slop machine”) workflow में

  • LLMs के उपयोग पर बहस:
    • आलोचकों को “interesting” हिस्सों को outsource करना पसंद नहीं है और वे unverifiable, plausible output के बारे में चेतावनी देते हैं।
    • समर्थकों का तर्क है कि AI intermediate, non-security-critical steps के लिए ठीक है, बशर्ते अंतिम परिणाम की independently जाँच की जाए।
    • AI के प्रति बहुत नकारात्मक और बहुत सकारात्मक दोनों तरह के रुख दिखाई देते हैं।

RNGs, अपना crypto खुद बनाना, और system design

  • पारंपरिक समझ: अपना crypto खुद मत बनाइए; kernel RNGs (getrandom, /dev/urandom) का उपयोग कीजिए।
  • प्रतिवाद: एक लंबे समय से चल रहे project में hand-rolled RNG में कोई vulnerabilities नहीं पाई गईं, जबकि व्यापक रूप से उपयोग की जाने वाली libraries में कई रही हैं; इससे context और careful design के महत्व का तर्क दिया जाता है।
  • चर्चा POSIX constraints, chroot environments, और RNG design में performance बनाम security पर भी जाती है।

PKI, DNS, और विकल्प

  • कुछ लोग public keys को DNS में प्रकाशित करने (ACME/DNS-01 style) की वकालत करते हैं और पारंपरिक CAs की आवश्यकता पर सवाल उठाते हैं।
  • अन्य लोग कहते हैं कि इससे trust DNS और DNSSEC पर स्थानांतरित हो जाता है, और DNS layer पर MITM अब भी चिंता का विषय है।

Surveillance, forward secrecy, और संग्रहीत traffic

  • यह चिंता व्यक्त की जाती है कि सरकारों ने ऐतिहासिक encrypted traffic रिकॉर्ड किया हो सकता है ताकि factoring या quantum के बेहतर होने पर बाद में उसे decrypt किया जा सके।
  • forward secrecy और सममित crypto की मज़बूती पर ज़ोर दिया जाता है; post-quantum TLS deployment stats को उत्साहजनक बताया गया है।
  • एक अतिरिक्त सुरक्षा उपाय प्रस्तावित है: एक “clean” connection पर PSK negotiate करें और उसे भविष्य के sessions को harden करने के लिए उपयोग करें, यह मानते हुए कि adversary हर चीज़ की निगरानी नहीं कर सकता।