Certbot: डिफ़ॉल्ट आरएसए कुंजी बिटलम्बाई 3072 . होनी चाहिए

मैं 4096 का भी सुझाव दूंगा (मैं इसे अपने लगभग सभी सिस्टम पर करता हूं)।

धन्यवाद,
मार्टिन

मैं 4096 का भी सुझाव दूंगा।

लेकिन कुछ महीने पहले, वे डिफ़ॉल्ट रूप से 4096 से असहमत थे: https://github.com/letsencrypt/letsencrypt/issues/489

मैं डिफ़ॉल्ट रूप से बिना किसी सुरक्षा की तुलना में एक समझौता (= 3072 बिट-मॉड्यूलस के साथ आरएसए) पसंद करता हूं।

4096 भी सुझाइए।
सुरक्षा डिज़ाइन और डिफ़ॉल्ट रूप से अच्छी होनी चाहिए: कोई भी मानक उपयोगकर्ता डिफ़ॉल्ट कॉन्फ़िगरेशन को नहीं बदलता है।

और 2048/3072 बनाम 4096 बिट्स (केवल एक बहुत ही छोटी गति ओवरहेड) के लिए कोई स्वीकार्य तर्क नहीं है।
3072 बिट्स संगतता समस्या का कारण बन सकते हैं यदि उपयोगकर्ता एजेंट कुछ प्रमुख आकारों को हार्डकोड करता है (2048 और 4096 बिट्स 3072 से बेहतर समर्थित होंगे)।

सबसे खराब, 2048 बिट्स कुंजी उपयोग को सही ठहराने के लिए 90 दिनों की कुंजी पुनर्जनन का तर्क अच्छा नहीं है:

• कुंजी पुनर्जनन कई अन्य TLS स्टैक सुरक्षा को तोड़ता है, जैसे DANE/TLSA या HPKP, कठोर कॉन्फ़िगरेशन को बड़ी परेशानी से बचने के लिए इसे अक्षम करना चाहिए।
• मुख्य उत्थान "अतीत का विनाश" नहीं कहता है। यदि वेब सर्वर केवल पीएफएस सिफर सूट के साथ सही ढंग से कॉन्फ़िगर नहीं किया गया है, तो एनएसए जैसी एजेंसियां ​​​​2048 बिट्स कुंजी के साथ संरक्षित नेटवर्क संचार को रोक सकती हैं और स्टोर कर सकती हैं, और उन्हें 20 या 30 वर्षों में डिक्रिप्ट कर सकती हैं, भले ही संबंधित कुंजी नष्ट हो गई हों। 4096 बिट कुंजियाँ लंबे समय तक गैर पीएफएस संचार की रक्षा करती हैं।
• यहां तक ​​​​कि केवल पीएफएस सिफर के साथ, वेब सर्वर आम तौर पर निजी कुंजी आकार पर नेगोशिएटेड डीएच पैरामीटर को आधार बनाते हैं। यदि आप केवल 2048 बिट्स निजी कुंजी का उपयोग करते हैं, तो आपका डीएच पैरामीटर केवल 2048 बिट्स है, और इसलिए लॉगजैम के लिए कमजोर संभव है।

4096 के लिए एक और +1, यही मैं इन दिनों हमेशा उपयोग करता हूं।

इस मुद्दे के बारे में अधिक चर्चा के लिए #489 देखें।

LE की डिफ़ॉल्ट सेटिंग्स के साथ, RSA 2048 बिट्स, 90 दिन, इसे क्रैक करने का प्रयास करें? मैं इस मुद्दे को बंद करने का सुझाव देता हूं।

प्रश्न यह नहीं है कि "आप इसे क्रैक कर सकते हैं" (या 1024 बिट्स पर बने रहें, अब से कोई इसे क्रैक नहीं करेगा) लेकिन "सभी अनुशंसाएं / अत्याधुनिक कम से कम 3072 बिट्स पूछें" (एनएसए, एनआईएसटी, एएनएसआई, एफआईपीएस, क्वालिस और अधिक)।
डिफ़ॉल्ट रूप से 4096 बिट्स में अपग्रेड करने के लिए कोई वैध कमियां नहीं हैं।

(और मैं दोहराता हूं, यहां तक ​​कि 90 दिनों के कुंजी नवीनीकरण के साथ, यदि कोई पीएफएस उपयोग नहीं किया जाता है, तो आपके पास काफी दशकों की व्यावहारिक कुंजी वैधता है, भले ही तकनीकी वैधता केवल 90 दिनों की हो, और 90 दिनों की कुंजी नवीनीकरण कई अन्य टीएलएस स्टैक (टीएलएसए) को तोड़ देती है। HPKP, सर्ट पिनिंग), इसलिए समझदार sys admin को इसे अक्षम करना होगा और कम से कम 120 दिनों और अभ्यास में 1 वर्ष के लिए एक कुंजी का पुन: उपयोग करना होगा)

हालांकि, एलेक्सा की शीर्ष 1,000,000 वेबसाइटों में, 89% से अधिक एसएसएल/टीएलएस सक्षम वेबसाइटें कई ऑनलाइन बैंकिंग वेबसाइटों सहित आरएसए 2048 बिट्स का उपयोग करती हैं।

हां, यदि आप चाहते हैं तो बैंक के पास SSLv3 और MD5 भी हैं https://imirhil.fr/tls/#Banques %20en%20ligne
और गूगल/यूट्यूब भी https://imirhil.fr/tls/alexa.html
और अश्लील साइट कोई टीएलएस नहीं https://imirhil.fr/tls/porn.html
यहां तक ​​कि सीए के पास एसएसएलवी3, एमडी5, आरसी4 या एसएसएलवी2 (हां, आपने सही पढ़ा...) और 40 बिट एक्सपोर्ट सुइट्स हैं https://imirhil.fr/tls/ca.html

टीएलएस विन्यास जंगली में बहुत खराब हैं, यह बकवास जारी रखने की दलील नहीं है।

@ devnsec-com तो वे सुरक्षित नहीं हैं। भले ही IPv6 और DNSSEC अच्छी प्रौद्योगिकियां हैं, फिर भी उन्हें अभी तक व्यापक रूप से तैनात नहीं किया गया है। आरएसए 4096 बिट्स के लिए भी ऐसा ही होता है। हमें पानी पर चलने के बजाय आगे बढ़ना है।

RSA 3072 या 4096 (या उससे भी अधिक) का उपयोग करने का एकमात्र कारण भविष्य का प्रमाण है, लेकिन केवल 90 दिनों के प्रमाण पत्र के साथ, क्या सभी उपयोगकर्ताओं को वास्तव में डिफ़ॉल्ट रूप से 2048 से अधिक लंबे समय तक आरएसए की आवश्यकता होती है? यदि आप वास्तव में पागल हैं, तो लंबी चाबियों के लिए जाएं, एक पैरामीटर है और आप इसे बदल सकते हैं।

सभी उपयोगकर्ता को डिफ़ॉल्ट रूप से 3072+ कुंजी की आवश्यकता होती है।

लोग वास्तव में जानते हैं कि वे क्या करते हैं, अंततः आकार को कम कर सकते हैं, लेकिन डिफ़ॉल्ट रूप से , Let's एन्क्रिप्ट को अत्याधुनिक अनुरूप कॉन्फ़िगरेशन प्रदान करना चाहिए।
मानक उपयोगकर्ता (वास्तव में 99%) कॉन्फ़िगरेशन में भी नहीं देखते हैं या जेनरेट की गई कुंजी के आकार की परवाह नहीं करते हैं या यहां तक ​​​​कि यह भी जानते हैं कि टीएलएस वास्तव में क्या है ...

याद रखें, हम एक एसएसएल/टीएलएस प्रमाणपत्र के बारे में बात कर रहे हैं, आपके पास अपने सर्वर पर पीएफएस समर्थन हो सकता है, और यदि आवश्यक हो तो इसे रद्द किया जा सकता है। हम एक OpenGPG कुंजी या SSH कुंजी के बारे में बात नहीं कर रहे हैं जिसे आप 20 साल या उससे भी अधिक समय तक उपयोग कर सकते हैं।

और कई वर्षों बाद, जब RSA 2048 वास्तव में सुरक्षित नहीं साबित हो रहा है, हम LE डिफ़ॉल्ट को RSA 4096 में बदल सकते हैं, लगभग सभी उपयोगकर्ता 90 दिनों के भीतर RSA 4096 में बदल जाएंगे।

चूंकि मैंने ओपनजीपीजी का उल्लेख किया है, मैं कहूंगा कि ओपनजीपीजी भी आरएसए 2048 के लिए डिफ़ॉल्ट है।
इसे पढ़ें: https://gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096

आप कर सकते हैं । आपके पास पीएफएस भी नहीं हो सकता है। और अगर 2048 बिट कुंजी है, तो आप सुरक्षित नहीं हैं। 90d नवीनीकरण के साथ भी। और यदि कोई पीएफएस नहीं है, तो कुंजी विनाश बेकार है, आपका डेटा पहले से ही प्रकृति में है और कुछ दशकों में डिक्रिप्ट किया जाना चाहिए।

और केवल प्रमाणपत्र निरस्त किया जा सकता है, कुंजी नहीं।
चाबियाँ बिल्कुल जीपीजी/एसएसएच कुंजी की तरह हैं: पीढ़ी के बाद, आपको उन्हें पीएफएस की स्थिति में पृथ्वी की सतह के भौतिक विनाश तक और पीएफएस नहीं होने पर अनंत काल तक संभालना होगा।

चूंकि मैंने ओपनजीपीजी का उल्लेख किया है, मैं कहूंगा कि ओपनजीपीजी भी आरएसए 2048 के लिए डिफ़ॉल्ट है।

जीपीजी में 4096 कुंजियों का उपयोग करने की वास्तविक खामी है (केवल कुछ स्मार्टकार्ड 2048 से अधिक का समर्थन करते हैं, मोबाइल डिवाइस…)। टीएलएस पर, कोई नहीं है।

और GPG पर, हर कोई वर्तमान में 4096 बिट कुंजियाँ उत्पन्न करता है, सभी ट्यूटोरियल और अनुशंसाएँ इसके लिए पूछती हैं।

आपने अभी-अभी एक बिंदु रखा है, RSA 2048 या उससे अधिक के लिए डिफ़ॉल्ट तर्क देने के बजाय, हमें PFS को सक्षम करने के लिए डिफ़ॉल्ट के बारे में बात करनी चाहिए। क्योंकि कुंजी कितनी भी लंबी क्यों न हो, इसे जल्द या बाद में डिक्रिप्ट किया जाएगा, RSA 2048 होगा, RSA 4096 भी।

हां, लेकिन आपके पास लेट्स एनक्रिप्ट के साथ पीएफएस सुनिश्चित करने का कोई तरीका नहीं है (और केवल पीएफएस सिफर से भी बदतर, आप पीएफएस सिफर सूट को निगोशिएट कर सकते हैं लेकिन सर्वर नो-पीएफएस या एक्सपोर्ट… का समर्थन कर सकता है)।

और वर्तमान में, केवल पीएफएस सिफर सूट (ब्राउज़र संगतता, देखें https://tls.imirhil.fr/suite/EECDH+AES:EDH+AES+aRSA) का उपयोग करने में बड़ी कमी है।

सभी मामलों में, यह सीए का काम नहीं है।

हम यहां सीए की बात नहीं कर रहे हैं, बल्कि क्लाइंट सॉफ्टवेयर की बात कर रहे हैं, है ना?

नहीं, टीएलएस बहुत जटिल है, ढेर सारे ढेर के साथ।
कोई भी सॉफ्टवेयर इसे पूरी तरह से हैंडल नहीं कर सकता है।

आपके पास यह अनुमान लगाने का कोई तरीका नहीं है कि आपके उपयोगकर्ता के पास DNSSec या TLSA है, IE संगतता सुनिश्चित करनी चाहिए या मानक उपयोगकर्ता-एजेंट नहीं, OpenSSL के किस संस्करण का उपयोग किया जाता है, आदि।
केवल एक चीज जो LE कर सकता है, वह है कुंजी का आकार बढ़ाना…

नहीं, जब LE डिफ़ॉल्ट रूप से RSA 3072 या 4096 का उपयोग करता है, तो कोई कहेगा कि वह सभी उपयोगकर्ताओं के लिए डिफ़ॉल्ट रूप से RSA 8192 चाहता है, यह हथियारों की एक अंतहीन दौड़ है।

@ devnsec-com No. NSA, NIST, ANSSI, FIPS, Qualys RSA 8192 लेकिन कम से कम RSA 3072 की अनुशंसा नहीं करते हैं।

नहीं, अगर कोई 8192 मांगता है, तो आप कह सकते हैं कि 4096 वर्तमान में सुरक्षित है और हर जगह अनुशंसित है।
वर्तमान में, यह 2048 का मामला नहीं है।

मैं यह भी कह सकता हूं कि जिस समय हम बात कर रहे हैं उस समय यूबिको , सिस्को और कई कंपनियां आरएसए 2048 की सिफारिश कर रही हैं।

कुंजी जितनी लंबी होगी, वे उतनी ही सुरक्षित होंगी, लेकिन व्यावसायिक कंपनियां इस विषय पर अधिक व्यावहारिक हैं। फिर से, आरएसए 2048 डिफ़ॉल्ट के रूप में वर्तमान चरण में पर्याप्त है, जब तक हम जरूरत पड़ने पर लंबी कुंजी का समर्थन करते हैं।

इस बातचीत के लिए अच्छा संसाधन - keylength.com

@ devnsec-com युबिको और सिस्को स्थिति मान्य हैं, क्योंकि उनके पास हार्डवेयर समस्या है (HSM, PKI और स्मार्टकार्ड 4096 बिट्स का बहुत अच्छी तरह से समर्थन नहीं करते हैं)।

Yubico से : « यह Yubico की ओर से कोई बाधा नहीं है, बल्कि YubiKeys के भीतर उपयोग किए जाने वाले NXP A700x चिप की एक हार्डवेयर सीमा है »
सिस्को से: सिस्को आईओएस एक्सई रिलीज 2.4 (और हार्डवेयर को अपग्रेड करना मुश्किल है) से केवल 4096 बिट्स उपलब्ध हैं, और दिया गया पृष्ठ बहुत पुराना है (2.4 रिलीज (200 9) के बाद से अपडेट नहीं किया गया है), कम से कम 2.X रिलीज के बाद से वही डिफ़ॉल्ट मान ...).

और ऐसा इसलिए नहीं है क्योंकि अन्य सभी भेड़ें चट्टान की ओर दौड़ रही हैं कि हमें उनका अनुसरण करना चाहिए ...

@ devnsec-com मैं यह भी जोड़ता हूं कि सिस्को दस्तावेज पीकेआई और सीए प्रबंधन के बारे में है, और इस क्षेत्र में (सीए प्रमाण, अंतिम उपयोगकर्ता प्रमाण नहीं), सीए/बी-फोरम कम से कम 2048 बिट्स की सिफारिश करता है।

और 2014 के बाद से 4096 समावेशन के बारे में आंतरिक बहस भी चल रही है।

क्या हम कुंजी आकार पर अनुशंसा शामिल करेंगे? कुछ लोग जानबूझकर 4096 बिट कुंजी का उपयोग करना चाहते हैं। क्या वे सलाह लेंगे? दस्तावेज़ सुरक्षा, अनुकूलता और अन्य कारकों के बीच व्यापार-बंद की व्याख्या कर सकता है

लेकिन ऐसा लगता है कि हार्डवेयर राउटर 2048 से अधिक जड़ों का समर्थन नहीं करते हैं (सिस्को)

इनिगो ने कहा कि सिस्को के नवीनतम उत्पाद SHA-1 और 4096-बिट रूट का समर्थन नहीं करते हैं। केल्विन ने कहा कि वह इसे बदलने के लिए सिस्को के साथ काम करने की कोशिश कर सकते हैं।

@ devnsec-com सीए/बी-फोरम पर एक और आंतरिक टिप्पणी ।

बेहतर सुरक्षा/प्रदर्शन (RSA-4096/ECC/SHA-512/आदि) के लिए परिवर्तनों के अगले सेट के लिए लक्ष्य तिथियां निर्धारित करना

हैलो दोस्तों, इस सूत्र को जारी रखना और एलई स्टाफ से वापस सुनना बहुत अच्छा होगा।
जहाँ तक मैं पढ़ सकता हूँ, @aeris तर्क मान्य प्रतीत होते हैं और विरोधाभासी नहीं। सिवाय अगर हम कुछ चूक गए हैं, तो मैं यह भी उम्मीद करता हूं कि LE जल्द ही डिफ़ॉल्ट RSA कुंजी को 4096 बिट पर स्विच कर देगा।

डिफ़ॉल्ट रूप से RSA 3072bit के लिए +1।

जैसा कि उल्लेख किया गया है, RSA 2048bit केवल 112bit सममित कुंजी सुरक्षा के बराबर है। यह आज उपयोग किए जाने वाले व्यापक रूप से आयोजित न्यूनतम 128 बिट से नीचे आता है। RSA 3072bit केवल 128bit के बराबर है, इसलिए अभी के लिए पर्याप्त है (और जनवरी, 2016 तक NSA द्वारा अनुशंसित न्यूनतम)।

ध्यान दें कि प्रमुख आकारों के लिए दीर्घायु के सभी पिछले अनुमानों को स्वस्थ संदेह के साथ लिया जाना चाहिए, क्योंकि वे आम तौर पर कुंजी-ब्रेकिंग में एक रैखिक सुधार मानते हैं, लेकिन नए हमले सुरक्षा को और अधिक तेज़ी से कम कर सकते हैं।

>2048 बिट वाली RSA कुंजियाँ वर्तमान में Amazon वेब सेवाओं के साथ असंगत हैं। Amazon CloudFront डेवलपर गाइड से:

SSL/TLS प्रमाणपत्र में सार्वजनिक कुंजी का अधिकतम आकार 2048 बिट है

बस मैंने सोचा कि मैं इस अतिरिक्त बिंदु को बातचीत में जोड़ दूंगा।

कोई भी व्यक्ति जो 2048 बिट्स से अधिक आरएसए रखना चाहता है, वह इन प्रमुख आकारों का अनुरोध करने के लिए केवल --rsa-key-size 3072 या --rsa-key-size 4096 दर्ज कर सकता है।
कृपया ध्यान दें कि बड़ी RSA कुंजियाँ उत्पन्न होने में तेज़ी से अधिक समय लेती हैं, और 4096 से बड़ी कोई भी चीज़ पुराने Apple ब्राउज़र को क्रैश कर सकती है।

जब #2632 को लागू किया गया है, तो बहुमत के लिए प्रदर्शन दोष का लगभग कोई प्रभाव नहीं पड़ेगा।
इसलिए हम दोनों के लिए समान शक्ति प्रदान करने के लिए ईसी 256 को 3072 आरएसए (या जिसे हम डिफ़ॉल्ट के रूप में पसंद करते हैं) के साथ जोड़ सकते हैं।

वैसे, ईसी कुंजी का समर्थन करने के सुझाव के रूप में, ईसी कुंजी उत्पन्न करने और प्रमाणपत्र का अनुरोध करने के लिए --ec-key-type जैसा आदेश है।
मैं वर्तमान में एक शेल स्क्रिप्ट का उपयोग करके सर्टिफिकेट और मेरी ईसी कुंजियों का उपयोग करके अपनी आरएसए कुंजी उत्पन्न करता हूं और हस्ताक्षरित करता हूं।

@WilliamFeely वह #2625 . है

धन्यवाद।
आरएसए कुंजी आकार के लिए, मैं अनुमान लगा रहा हूं कि आरएसए 2048 अभी भी उद्योग मानक है, और अभी भी पीसीआई-डीएसएस अनुपालन के लिए अधिकृत है, और इस प्रकार यह अभी भी डिफ़ॉल्ट क्यों है?

यहाँ नवीनतम PCI-DSS दस्तावेज़ीकरण ( v3.2, अप्रैल 2016 ) कहता है:

मजबूत क्रिप्टोग्राफी और सुरक्षित प्रोटोकॉल (जैसे एनआईएसटी एसपी 800-52 और एसपी 800-57, ओडब्ल्यूएएसपी, आदि) पर जानकारी के लिए उद्योग मानकों और सर्वोत्तम प्रथाओं का संदर्भ लें।

सौभाग्य से, शब्दावली मजबूत क्रिप्टोग्राफी को निम्नानुसार परिभाषित करती है:

उद्योग-परीक्षण और स्वीकृत एल्गोरिदम पर आधारित क्रिप्टोग्राफी, प्रमुख लंबाई के साथ जो न्यूनतम 112-बिट प्रभावी कुंजी शक्ति और उचित कुंजी-प्रबंधन प्रथाओं को प्रदान करती है। क्रिप्टोग्राफी डेटा की सुरक्षा के लिए एक विधि है और इसमें एन्क्रिप्शन (जो प्रतिवर्ती है) और हैशिंग (जो "एक तरह से" है; अर्थात, प्रतिवर्ती नहीं है) दोनों शामिल हैं। हैशिंग देखें।

प्रकाशन के समय, उद्योग-परीक्षण और स्वीकृत मानकों और एल्गोरिदम के उदाहरणों में एईएस (128 बिट्स और उच्चतर), टीडीईएस/टीडीईए (ट्रिपल-लेंथ कीज़), आरएसए (2048 बिट्स और उच्चतर), ईसीसी (224 बिट्स और उच्चतर) शामिल हैं। , और डीएसए/डीएच (2048/224 बिट्स और उच्चतर)। क्रिप्टोग्राफिक प्रमुख शक्तियों और एल्गोरिदम पर अधिक मार्गदर्शन के लिए एनआईएसटी स्पेशल पब्लिकेशन 800-57 भाग 1 (http://csrc.nist.gov/publications/) का वर्तमान संस्करण देखें।

_ नोट : उपरोक्त उदाहरण कार्डधारक डेटा के निरंतर भंडारण के लिए उपयुक्त हैं। लेनदेन-आधारित संचालन के लिए न्यूनतम क्रिप्टोग्राफी आवश्यकताएं, जैसा कि पीसीआई पिन और पीटीएस में परिभाषित किया गया है, अधिक लचीली हैं क्योंकि एक्सपोजर के स्तर को कम करने के लिए अतिरिक्त नियंत्रण हैं।
यह अनुशंसा की जाती है कि सभी नए कार्यान्वयन कम से कम 128-बिट प्रभावी कुंजी शक्ति का उपयोग करें।_

वेब सर्वर के साथ उपयोग की जाने वाली RSA कुंजी के लिए 3072 पर डिफ़ॉल्ट होने की कोई आवश्यकता नहीं है।

सबसे पहले, आपको केवल FS प्रदान करने वाले सिफर का उपयोग करना चाहिए। इस तरह पिछले सत्र जो लॉग किए गए हैं वे अभी भी सुरक्षित हैं, भले ही आपकी निजी कुंजी बाद में खोजी गई हो।

GnuPG जैसी किसी चीज़ के साथ आप बड़े (मैं 4096 का उपयोग करता हूं) का उपयोग करना चाह सकते हैं क्योंकि FS एक विकल्प नहीं है, क्लाइंट और सर्वर कनेक्शन स्थापित होने पर अपनी कुंजी पर बातचीत नहीं करते हैं। जीएनयूपीजी के साथ भी आपको वास्तव में> 2048 की आवश्यकता नहीं है और यदि आप करते हैं, तो ईसी हिरन के लिए अधिक धमाका करता है, लेकिन चूंकि यह अभी तक ग्राहकों द्वारा अच्छी तरह से समर्थित नहीं है और एक जीएनयूपीजी एन्क्रिप्टेड संदेश दशकों तक संवेदनशील हो सकता है, 4096 कम से कम है न्यायोचित,

यदि FS का उपयोग किया जाता है तो यह HTTPS के साथ न्यायोचित नहीं है। जब FS का उपयोग किया जाता है, तो जब संभव हो तो आपको ECDHE सिफर का उपयोग करना चाहिए ताकि क्लाइंट और सर्वर के बीच उपयोग की जाने वाली कुंजी अधिक मजबूत हो। यदि आपका सर्वर अभी भी डीएचई कुंजी का समर्थन करता है तो यह डीएच समूह है जहां आपको चिंता करनी चाहिए कि कितने बिट्स हैं, और वहां, अधिकांश लोग पूर्व-निर्धारित 2048 डीएच समूह का उपयोग करते हैं जो आरएफसी में प्रकाशित होता है। अपना खुद का 2048 बिट डीएचई समूह बनाना उचित है।

सर्वर निजी कुंजी के लिए, 2048 बिट को आसानी से क्रैक नहीं किया जा सकता है और इसलिए यह पर्याप्त है। 3072 या 4096 के डिफ़ॉल्ट का सुझाव देना 15 पाउंड के बजाय 20 पाउंड पेपरवेट का सुझाव देने जैसा है। हाँ 20 पाउंड भारी है लेकिन नहीं, कोई वास्तविक लाभ नहीं है और आपकी 2048 बिट आरएसए कुंजी लंबे समय तक बदल दी जाएगी, इससे पहले कि यह सुरक्षित न रहे।

हमेशा आगे की गोपनीयता का उपयोग करें और जब भी संभव हो ईसीडीएचई सिफर का उपयोग करें। निजी कुंजी, RSA 2048 काफी अच्छी है और यदि आप वास्तव में बेहतर चाहते हैं, तो कुंजी के लिए ECDSA नहीं RSA का उपयोग करें।

मुझे लगता है कि मैं जो कहने की कोशिश कर रहा हूं, और अगर मैं गलत हूं तो मुझे सही करें, यह है कि जब आपके टीएलएस को ऐसे सिफर की आवश्यकता होती है जो फॉरवर्ड सेक्रेसी का उपयोग करते हैं तो सर्वर का एकमात्र वास्तविक उद्देश्य दीर्घकालिक निजी कुंजी पहचान है।

क्लाइंट और सर्वर के बीच वास्तविक एन्क्रिप्शन जो जगह लेता है वह क्लाइंट और सर्वर के बीच बातचीत की गई एक अस्थायी कुंजी का उपयोग करता है जो x.509 प्रमाणपत्र के साथ उपयोग की जाने वाली कुंजी से असंबंधित है।

यही कारण है कि आपको चिंता करने की ज़रूरत है, कभी भी डीएच पैरामीटर <2048 का उपयोग न करें और अधिमानतः ईसीडीएचई का उपयोग करें। सर्वर के लिए निजी कुंजी केवल सर्वर की पहचान स्थापित करने में प्रासंगिकता रखती है, और 2048 बिट आरएसए निश्चित रूप से इसके लिए पर्याप्त है, खासकर यदि आप वर्ष में कम से कम एक बार ताजा कुंजी उत्पन्न करने के लिए सर्वोत्तम प्रथाओं का पालन करते हैं।

इस प्रकार इस मुद्दे को बंद किया जाना चाहिए, और सुरक्षा पर जोर उचित सिफर सूट चयन पर रखा जाना चाहिए।

दिलचस्प है, लेकिन जब Applebaum और स्नोडेन दोनों मुझे RSA कुंजी आकार 4096 बिट का उपयोग करने की सलाह देते हैं, ठीक है, हम्म, मुझे नहीं पता, मुझे लगता है कि मैं उस सलाह का पालन कर सकता हूं। क्या पहचान ठीक नहीं है जिसे हम यहां छिपाने/संरक्षित करने का प्रयास कर रहे हैं?

@jult बस 4096-बिट के साथ रहें, खासकर यदि आप GnuPG का उपयोग कर रहे हैं। जब तक सभी 2.1 में अपग्रेड नहीं हो जाते, तब तक हमारे पास ed25519 OpenPGP कुंजियों तक पहुंच नहीं होगी। और वे इतने मजबूत नहीं हैं। (मुझे अपनी ed25519 SSH + GPG कुंजियाँ पसंद हैं, इसलिए सभी को RSA से दूर जाने के लिए प्रोत्साहित करें!)

2048-बिट आरएसए कुंजियाँ एक हमलावर द्वारा अगले कुछ वर्षों में बड़ी मात्रा में कम्प्यूटेशनल संसाधनों के साथ टूटने योग्य होने की उम्मीद है। 768-1024 बिट पहले ही नियमित रूप से टूट चुके हैं।

मुझे नहीं लगता कि 3072 एक उचित डिफ़ॉल्ट है, यह सामान्य से अलग है।

2048-बिट की अनुशंसा 2030 के बाद नहीं की जाएगी, मैं आपको गारंटी देता हूं, और सूर्यास्त धीरे-धीरे होगा जैसा कि SHA-1 के लिए था। मैंने उन सरकारी मानकों के बहुत सारे दस्तावेज़ पढ़े हैं और ऐसे...

कुछ समय के लिए लोग 8192-बिट की और उससे ऊपर की कुंजियाँ बनाने के अभ्यास में थे... यह स्रोत के लिए केवल दो या तीन-पंक्ति परिवर्तन का मज़ा है, मुझे यकीन नहीं है कि वे दूसरों के साथ कितनी अच्छी तरह से संचालित हैं।

. @WikiLeaks सबमिशन के लिए असामान्य रूप से मजबूत 8192-बिट RSA PGP एन्क्रिप्शन कुंजी प्रकाशित करता है https://t.co/xGnu72HTUN pic.twitter.com/8TZyql1NN6

- केएम गैलाघर (@ageis) 27 मई, 2015

@ageis इसके अलावा, 16384 पर काफी कठिन सीमा है। इसे बड़ा करने के लिए *बहुत* अधिक हैकिंग की आवश्यकता होगी; मैंने कोशिश की।

- आइसिस अगोरा लवक्रूफ्ट (@isislovecruft) सितंबर 8, 2014

@jult मैं एपेलबाम और स्नोडेन चीज़ को संबोधित नहीं करूंगा। मैं उनसे बहुत कम परिचित हूं, लेकिन मैं इसे आपके द्वारा बनाए जा रहे अधिकार के लिए रॉक-स्टार की अपील के रूप में देखता हूं। सभी स्रोतों को देखें, मैं विशेष रूप से कुछ की सिफारिश कर सकता हूं:

• http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf
• https://pages.nist.gov/800-63-3/sp800-63b.html
• http://www.secg.org/sec2-v2.pdf
• http://www.ecc-brainpool.org/download/Domain-parameters.pdf
• http://csrc.nist.gov/groups/ST/toolkit/documents/dss/NISTReCur.pdf
• https://safecurves.cr.yp.to/

व्यक्तिगत रूप से, मैं सभी को GnuPG 2.1 में तेज़ kbx प्रारूप के साथ अद्यतन करने और नई ed25519 कुंजियाँ (विचार @dkg या @floodyberry?) उत्पन्न करने के लिए उत्सुक हूँ, और यह मेरी आशा है कि अगली Yubico श्रृंखला उनका समर्थन करेगी। वास्तव में मैं जाँच करने के लिए पहुँच सकता हूँ; जैसा कि मैंने YubiKey 4 के लिए कुछ बीटा परीक्षण किया था। हालांकि, मुझे यह पसंद नहीं है कि निर्यात के लिए कुंजियों को कैसे सुरक्षित/पासवर्ड किया जाना चाहिए, क्योंकि यह स्मार्टकार्ड में आयात को एक चुनौती बना देता है।

जबकि मैं इस मुद्दे के आसपास हूं, मैं एनआईएसटी स्पेशल पब्लिकेशन 800-57 से एक महान चार्ट छोड़ दूंगा। कई और कहां से आए हैं। शनिवार की रात को शुरू करने के लिए बिल्कुल सही चीज़, हुह?

फिर से, क्लाइंट-हैंडशेक के दौरान आकार पर अतिरिक्त भार छोटे कुंजी आकार के साथ अतिरिक्त जोखिम के लायक नहीं है। 4096 बिट्स आरएसए का उपयोग करने के खिलाफ सिफारिश करने वाले वैध तर्कों के साथ नहीं आने में विफल होते हैं। इस तथ्य का उल्लेख नहीं करने के लिए कि हम चाबियों की उचित पीढ़ी पर भरोसा कर रहे हैं, और यदि कभी भी यह त्रुटिपूर्ण हो जाता है, तो हम 4096 बिट कुंजियों के साथ बेहतर तरीके से बंद हो जाते हैं।
इसे देखो; https://github.com/certbot/certbot/issues/489#issuecomment-114083162
आप यह सुनिश्चित करना चाहते हैं कि आप> = 4096 बिट्स की डिफी हेलमैन कुंजियाँ भी उत्पन्न करें, इस तरह की चीज़ें
openssl dhparam -dsaparam -out /etc/ssl/dh4096.pem 4096
यदि आप चाहते हैं कि जब आप अपने साइबर सूट में डीएच (ई) को सक्षम करें तो इसका कोई मतलब हो।

मैंने अभी-अभी RSA हस्ताक्षरों के लिए एक सिंथेटिक बेंचमार्क चलाया और इसे देखा:

(1024, 0.0008035948276519776)
(2048, 0.0025235090255737304)
(3072, 0.006322009086608887)
(4096, 0.013043954849243164)

पहली संख्या मापांक का आकार है और दूसरी प्रति हस्ताक्षर संचालन के लिए आवश्यक सेकंड की औसत संख्या है।

मुझे आगे की गोपनीयता के बारे में @AliceWonderMiscreations की टिप्पणियां कुछ प्रेरक लगीं; क्या किसी के पास टीएलएस कनेक्शन के अंशों के बारे में कुछ मौजूदा आंकड़े हैं जो आज विभिन्न सिफरसुइट्स के साथ बातचीत कर रहे हैं? यदि बहुत कम लोग अब गैर-पीएफएस सिफर का उपयोग कर रहे हैं, तो आरएसए कुंजी लंबाई पैरामीटर के न्यूनतम दीर्घकालिक सुरक्षा परिणाम होंगे।

एफएस और गैर-एफएस एक अलग मुद्दा है। हां, हमें FS सिफरसुइट्स को प्रोत्साहित करना चाहिए, और क्लाइंट और सर्वर दोनों को गैर-FS सिफरसुइट्स को अक्षम करना चाहिए, जहां वे जानते हैं कि ऐसा करना संभव है। (TLS 1.3 में कोई गैर-FS सिफरसुइट नहीं बचा है, हाँ!) इसका मतलब यह नहीं है कि हमें एक मजबूत क्रिप्टोग्राफ़िक पहचान कुंजी के महत्व को नज़रअंदाज़ करना चाहिए, या हमें एक दूसरे के खिलाफ खेलना चाहिए। याद रखें कि जाली पहचान कुंजी MiTM को FS कनेक्शन भी संभव बनाती है।

RSA 3072 सबसे प्यारा स्थान प्रतीत होता है जहाँ अनुशंसाएँ (जैसे ENISA और NIST) अगले दशक में उपयोग की जाने वाली चाबियों के लिए एक मजबूत सुरक्षा मार्जिन पर नीचे आती हैं।

हाय @ डीकेजी ,

एफएस और गैर-एफएस एक अलग मुद्दा है। हां, हमें FS सिफरसुइट्स को प्रोत्साहित करना चाहिए, और क्लाइंट और सर्वर दोनों को गैर-FS सिफरसुइट्स को अक्षम करना चाहिए, जहां वे जानते हैं कि ऐसा करना संभव है। (TLS 1.3 में कोई गैर-FS सिफरसुइट नहीं बचा है, हाँ!) इसका मतलब यह नहीं है कि हमें एक मजबूत क्रिप्टोग्राफ़िक पहचान कुंजी के महत्व को नज़रअंदाज़ करना चाहिए, या हमें एक दूसरे के खिलाफ खेलना चाहिए। याद रखें कि जाली पहचान कुंजी MiTM को FS कनेक्शन भी संभव बनाती है।

डिफ़ॉल्ट मामले में, हम वर्तमान में केवल 60 दिनों के लिए एक व्यक्तिगत आरएसए विषय कुंजी का उपयोग करते हैं (प्रमाण पत्र के 90-दिन के जीवनकाल के लिए सक्रिय एमआईटीएम जोखिम के साथ), और फिर एक अलग पर स्विच करते हैं। ऐसा लगता है कि "एक हमलावर जो 90 दिनों में 2048-बिट कुंजी को तोड़ सकता है, एक सक्रिय हमला कर सकता है" और "एक हमलावर जो किसी भी समय 2048-बिट कुंजी को तोड़ सकता है, पुराने सत्रों के सादे पाठ को पुनर्प्राप्त कर सकता है" के बीच काफी अंतर है। इसमें शामिल था"। पहला सच है और दूसरा FS सिफरसुइट्स के मामले में सही नहीं है।

कीलेंथ के बारे में सिफारिशें आमतौर पर एक खतरे के मॉडल को मानती हैं जिसमें हमलावर उस कुंजी का उपयोग करने के कुछ समय बाद एक कुंजी को तोड़ देता है - उदाहरण के लिए नीचे दी गई सिफारिशें एक खतरे के मॉडल पर आधारित होती हैं जिसमें एक हमलावर को टूटने में वर्षों लगते हैं एक व्यक्तिगत कुंजी। FS सिफरसुइट्स के साथ, वह खतरा मॉडल पहचान कुंजी की लंबाई तय करने के लिए प्रासंगिक नहीं होना चाहिए क्योंकि दी गई पहचान कुंजी का उपयोग लंबे समय से बंद है।

RSA 3072 सबसे प्यारा स्थान प्रतीत होता है जहाँ अनुशंसाएँ (जैसे ENISA और NIST) अगले दशक में उपयोग की जाने वाली चाबियों के लिए एक मजबूत सुरक्षा मार्जिन पर नीचे आती हैं।

@AliceWonderMiscreations के तर्क में मैं जिस बात की सराहना करता हूं, वह यह है कि 2048-बिट कुंजियाँ जो हम उत्पन्न करते हैं, वे व्यक्तिगत रूप से एक दशक की अवधि में उपयोग के लिए अभिप्रेत नहीं हैं, बल्कि कई महीनों की अवधि में उपयोग के लिए हैं, जब वे डिफी-हेलमैन वार्ता को प्रमाणित करने के लिए उपयोग किया जाता है। इसलिए, ये सिफारिशें ज्यादातर मामलों में एक अलग सुरक्षा संदर्भ पर विचार कर सकती हैं। निश्चित रूप से, हमें अधिकांश खतरे वाले मॉडल में डीएच मॉड्यूलस के बारे में अधिक चिंतित होना चाहिए क्योंकि यह सीमित पैरामीटर है जो सीधे दीर्घकालिक सुरक्षा स्तर को प्रभावित करता है।

मैं FS सिफरसुइट्स के उपयोग की आवृत्ति और सर्वर प्रदर्शन पर 2048 बनाम 3072-बिट कुंजियों के प्रभाव के बारे में कुछ व्यावहारिक डेटा प्राप्त करने का प्रयास करूँगा।

एक अद्यतन के रूप में, मैंने कुछ अलग स्रोतों से मोटे अनुमानों को सुना कि "लगभग 10%", "10% से कम", और "लगभग 1%" HTTPS कनेक्शन अब गैर-एफएस सिफरसुइट का उपयोग करते हैं। यह परिभाषित करना एक बहुत ही कठिन लक्ष्य है क्योंकि यह इस बात पर निर्भर करता है कि यह ब्राउज़र के दृष्टिकोण से है, सर्वर के दृष्टिकोण से, किसी विशेष देश में, किसी विशेष वेब साइट पर, किसी विशेष प्रकार की वेब साइट के लिए, आदि, और उन प्रकार के अंतर 1% -10% विसंगति के लिए जिम्मेदार प्रतीत होता है।

व्यक्तिगत रूप से, मैं इस संबंध में इस तथ्य से अधिक चिंतित हूं कि हम डिस्क पर पुरानी निजी कुंजी रखते हैं (जिसके बारे में मैंने एक अलग मुद्दा दायर किया है, https://github.com/certbot/certbot/issues/4635)। मुझे लगता है कि यह एक उच्च प्राथमिकता होनी चाहिए क्योंकि मुझे लगता है कि पुराने ट्रैफ़िक को पढ़ने के लिए सर्वर से समझौता करने वाले हमलावर आमतौर पर ऐसा करने के लिए 2048-बिट आरएसए को तोड़ने वाले हमलावरों की तुलना में अधिक संभावना रखते हैं।

मैं निम्नलिखित का सुझाव देता हूं:

• मुझे पता है कि @dkg सामान्य रूप से TLS में DH प्रमुख एक्सचेंजों की सुरक्षा पर बहुत काम कर रहा है। क्या आप कुछ उपकरण बना सकते हैं या ढूंढ सकते हैं जो डीएच एक्सचेंज की ताकत का अनुमान लगाने के लिए साइटों को स्कैन करने में मदद करते हैं, जो तब हो सकता है जब कोई ग्राहक प्रत्येक साइट से जुड़ता है¹? (मुझे पता है कि आप जिन कुछ क्षेत्रों के बारे में चिंतित हैं, हम वास्तव में क्लाइंट की ओर से यह नहीं बता सकते हैं कि एक्सचेंज कितना सुरक्षित है, लेकिन मैं सिर्फ डीएच एक्सचेंज की ताकत को इस हद तक मैप करने की कोशिश करने के बारे में सोच रहा हूं। कि हम इसे देख और निर्धारित कर सकें।) हम बहुत से अकादमिक शोधकर्ताओं को भी जानते हैं जिनकी इस तरह के विषय में रुचि रही है...

• मैं अभी भी https://github.com/certbot/certbot/issues/4635 को ठीक करने का प्रयास करूंगा ताकि वेब सर्वर पर पुरानी, ​​​​अब तक उपयोग की जाने वाली निजी कुंजियाँ मौजूद न हों।

• हो सकता है कि हम उपयोगकर्ताओं को अपने वेब ब्राउज़र को अपग्रेड करने के लिए प्रोत्साहित करने के लिए चल रहे कदमों के बारे में सोच सकते हैं, ताकि टीएलएस में इस्तेमाल होने वाले डीएच की मात्रा को बढ़ाया जा सके।

इसे ध्यान में रखते हुए, मैं दोहराता हूं कि 2048-बिट कुंजियाँ जो हम डिफ़ॉल्ट रूप से उत्पन्न करते हैं, आमतौर पर सीधे सत्र कुंजियों की गोपनीयता की रक्षा के लिए उपयोग नहीं की जाती हैं, बल्कि डीएच कुंजी एक्सचेंजों को प्रमाणित करने के लिए उपयोग की जाती हैं, जहां एक हमले को ऑनलाइन करना होगा। , प्रमाणपत्र की 90-दिन की वैधता के भीतर इंटरैक्टिव, सक्रिय हमला। अन्यथा, हमलावर को इसके बजाय हमले का कोई अन्य तरीका चुनना होगा। मेरे लिए यह देखना मुश्किल है कि मुख्य लंबाई सलाह के किसी भी स्रोत का तर्क है कि 2048-बिट कुंजियां 90-दिन की विंडो के दौरान प्रमाणीकरण के लिए उपयुक्त नहीं हैं। वे 1% -10% कनेक्शन की दीर्घकालिक गोपनीयता के लिए अधिक सीधे प्रासंगिक हैं, लेकिन शायद हम उस प्रतिशत को कम करने के लिए कुछ और प्रयास कर सकते हैं।

उदाहरण के लिए, एल्गोरिथम के संबंध में और सार्वजनिक पैरामीटर आकार और पुन: उपयोग के संबंध में

मैं आरएसए कुंजियों के बारे में संबंधित सुझाव पर कुछ और शोध कर रहा हूं, लेकिन मैं इस मुद्दे को जल्द ही बंद करने की योजना बना रहा हूं, जब तक कि मेरे सबसे हालिया उत्तर में मेरे तीन सुझावों पर किसी के पास कोई प्रतिक्रिया न हो।

#3349 के बाद इसे बंद करने के बारे में क्या?

#3349 के बाद इसे बंद करने के बारे में क्या?

मैं कहूंगा कि #6492 अधिक प्रासंगिक है और #6492 हो जाने के बाद (और #4635) हमें इसे बंद कर देना चाहिए।

दोस्तों, 4096 बिट क्रिप्टो फ्री नहीं है। यह लो-पावर सीपीयू में बड़े पैमाने पर धीमा है। यहां तक ​​​​कि आधुनिक फोन भी इसका इस्तेमाल करते समय पीड़ित होते हैं। क्या आप सुनिश्चित हैं कि अटूट क्रिप्टो से और भी अधिक अप्राप्य क्रिप्टो में जाना हर किसी के प्रदर्शन और बैटरी जीवन को बर्बाद करने के लायक है?

IoT में 4096bit कीलेंथ एक बहुत बड़ी समस्या है क्योंकि इस डिवाइस में अक्सर बहुत सीमित CPU शक्ति होती है।

हमारे पुराने एम्बेडेड डिवाइस में से एक पर 2048 से 4096 तक जाने के लिए निजी आरएसए टैंक की गति 3.6 से 0.6 तक।

जैसा कि पहले उल्लेख किया गया है, IoT और हार्डवेयर त्वरण के बिना अन्य उपकरण ECDSA (#6492) का उपयोग कर सकते हैं।

जैसा कि पहले उल्लेख किया गया है, IoT और हार्डवेयर त्वरण के बिना अन्य उपकरण ECDSA (#6492) का उपयोग कर सकते हैं।

क्या कई उपकरणों में आरएसए का हार्डवेयर त्वरण है या यह अभी भी आमतौर पर सॉफ्टवेयर के माध्यम से नियंत्रित किया जाता है?

कुछ एमसीयू पर हार्डवेयर त्वरण उपलब्ध है, लेकिन उनमें से अधिकांश नहीं (यह अधिक महंगा है)। साथ ही यह अक्सर 3072 तक सीमित होता है, क्योंकि यह अनुशंसा है (https://www.keylength.com/)
ध्यान दें कि आरएसए सत्यापन काफी तेज है। केवल पीढ़ी और हस्ताक्षर बहुत धीमे हैं।

OPENSSL_TLS_SECURITY_LEVEL=3 के लिए कम से कम 3072 बिट्स की आवश्यकता होती है।

यह मुद्दा अभी तक खुला क्यों है? यह स्पष्ट है कि जो उपयोगकर्ता इसका अनुरोध कर रहे हैं, वे टीएलएस में प्रासंगिकता को गलत समझते हैं, खासकर 2020 में।

टीएल; डीआर

• सर्वर की पहचान साबित करने के लिए केवल RSA प्रमाणपत्रों पर भरोसा किया जा सकता है , और उन्हें हर 90 दिनों में बदला जा रहा है। उस समय के भीतर केवल आपको प्रतिरूपित करने के लिए 2048-बिट की कुंजी लंबाई के कारण इससे समझौता नहीं किया जाएगा।
• यह माना जा रहा है कि चूंकि आप सुरक्षा की इतनी परवाह करते हैं, आप केवल एफएस (डीएचई/ईसीएचडीई) की पेशकश करने वाले सिफर सूट की अनुमति दे रहे हैं, और डीएचई वास्तव में आपके लिए चिंता का विषय नहीं है क्योंकि वेबसाइटों के लिए, कोई भी आधुनिक वेब ब्राउज़र डीएचई का समर्थन नहीं कर रहा है।
• 1024-बिट आरएसए बनाम 2048-बिट आरएसए पर हमला करना ~ 4 अरब गुना अधिक कठिन है । 768-बिट आरएसए 2010 में टूट गया था (एक मशीन के 2000 वर्षों के बराबर समानांतर कंप्यूटिंग के साथ 2 साल लग गए), 2020 में हम केवल 829-बिट तक पहुंचने में कामयाब रहे हैं, 512-बिट बनाम 1024-बिट ~ 1 बिलियन है कठिनाई में समय, जबकि 2048-बिट बनाम 3072-बिट केवल ~ 65k गुना अधिक कठिन है ...
• आपकी प्रमाणपत्र पहचान को CA प्रमाणपत्रों के विरुद्ध विश्वास की एक श्रृंखला में सत्यापित किया गया है, जिसकी वैधता अवधि लंबी है लेकिन फिर भी 2048-बिट RSA है, उस पर आपका कोई नियंत्रण नहीं है । एक हमलावर लक्षित करेगा कि यदि वे आपका प्रतिरूपण करना चाहते हैं, तो आपकी कुंजी लंबाई को उससे आगे बढ़ाना कोई अतिरिक्त लाभ प्रदान नहीं कर रहा है जब प्रमाणपत्र का उपयोग किसी अन्य चीज़ के लिए नहीं किया जाता है।

अधिकांश तैनाती के लिए, आपको केवल पीएफएस सिफर सूट सुनिश्चित करना चाहिए, आपके आरएसए प्रमाणपत्र का 2048-बिट से अधिक यहां कोई लाभ नहीं है, आप अतिरिक्त ओवरहेड के कारण सर्वर द्वारा समवर्ती रूप से समर्थन कर सकने वाले हैंडशेक की मात्रा को कम कर रहे हैं। सलाह के संदर्भ को ध्यान में रखा जाना चाहिए, न कि केवल आँख बंद करके।

केवल कुंजी विनिमय के लिए डीएचई / ईसीडीएचई का उपयोग करें, वेब सर्वर के साथ आप पाएंगे कि 2015 के बाद से ब्राउज़र धीरे-धीरे डीएचई के लिए भी समर्थन हटा रहे हैं। सफारी ने 2015 में लोगजाम की प्रतिक्रिया के रूप में ऐसा किया, क्रोम ने 2016 में डीएचई समर्थन छोड़ दिया ( क्रोम 53 (अगस्त 2016) ) क्योंकि कितने सर्वर अभी भी 1024-बिट डीएच समूहों के साथ बातचीत कर रहे हैं, और फ़ायरफ़ॉक्स अंततः इस वर्ष में शामिल हो गया ( फ़ायरफ़ॉक्स 78 (फ़ायरफ़ॉक्स 78) जून 2020 )। तो मूल रूप से वेब के लिए, आप केवल ईसीडीएचई के साथ काम कर रहे हैं, जब तक कि आप वास्तव में उन ग्राहकों से अवगत नहीं हैं जो किसी कारण से इसका समर्थन नहीं कर सकते हैं, वेब ब्राउज़र ने लंबे समय तक ईसीसी का समर्थन किया है ।

अब आपके पास चिंता करने के लिए कौन-सी संभावित चिंता बची है? आपके प्रमाणपत्रों को 3 महीने के भीतर नवीनीकृत/प्रतिस्थापित किया जा रहा है, RSA प्रमाणपत्रों के साथ एकमात्र सुरक्षा चिंता पहचान है, कि कुछ हमलावर आपका प्रतिरूपण कर सकते हैं, लेकिन ऐसा होने के लिए, हमलावर को उस <90 दिन की विंडो के भीतर सफल होने की आवश्यकता है।

2020 में, अब तक का रिकॉर्ड 829-बिट आरएसए को तोड़ रहा है (10 साल जब से हम 768-बिट के टूटने योग्य होने के बारे में जानते थे), 795-बिट आरएसए के पिछले रिकॉर्ड में बेहतर एल्गोरिदम और हार्डवेयर उपलब्ध थे, जो लगभग आधे में अपने परिणाम प्राप्त करने के लिए उपलब्ध थे। गणना समय। बस 900-2000 गणना वर्षों को देखें, ये उपलब्धियां उनकी समानांतर कंप्यूटिंग शक्ति के बराबर थीं (जो कि 768-बिट के लिए घटाकर 2 वर्ष कर दी गई थी)।

512-बिट आरएसए सुरक्षा में लगभग 50 बिट्स की सममित कुंजी शक्ति है। 1024-बिट आरएसए को 80-बिट्स के रूप में जाना जाता है, और 2048-बिट आरएसए, 112-बिट्स के रूप में जाना जाता है, जबकि 3072-बिट जैसा कि इस मुद्दे में उल्लेख किया गया है, 128-बिट्स है। ठीक है, शानदार तो 768-बिट आरएसए (जो कहीं 50-80 बिट के सममित सुरक्षा के बीच है) 2010 में 2 साल और एक टन पैसे की अवधि में तोड़ा जा सकता है, एक दशक बाद हम कुछ सममित करने में कामयाब रहे हैं बराबर बिट्स अधिक। किसी के लिए भी जहां यह जिबरिश की तरह लग रहा है, सममित कुंजी शक्ति में प्रत्येक अतिरिक्त बिट गणना करने के लिए काम की मात्रा को दोगुना कर रहा है यदि आप सभी संभावनाओं को बल देना चाहते हैं (औसतन आपको उस सभी प्रसंस्करण के माध्यम से लगभग आधे रास्ते में सफलता मिलेगी) .

अब 512-बिट आरएसए की तुलना 1024-बिट से करें, सममित सुरक्षा में लगभग 30-बिट्स का अंतर है, 2 ^ 30 लगभग 1 बिलियन है, यानी 50-बिट्स (1,125,899,906,842,624 संभावित कुंजियाँ) को 1 बिलियन (1,125,899,906,842,624,000,000) से गुणा किया जाता है, या सीधे शब्दों में कहें तो , 1 अरब गुना अधिक प्रयास/तोड़ने का समय। RSA 1024-बिट बनाम 2048-बिट के साथ, आपके पास 32 बिट अंतर है, 2^32 4 बिलियन से थोड़ा अधिक है। तो हमारे पास (4,503,599,627,370,496,000,000,000,000,000,000) हैं। अब, 3072-बिट तक उछलना 16-बिट्स अतिरिक्त सुरक्षा का अधिक मामूली है, 2^16 == 65,536... लेकिन हमारे पास पहले से ही 2048-बिट आरएसए के साथ कठिनाई में उल्लेखनीय वृद्धि हुई है।

अब इसे भीगने दें और सोचें। 2010 में 768-बिट आरएसए ने एक मशीन से 2000 वर्षों के बराबर समानांतर प्रसंस्करण के 2 साल लिए, और एक दशक बाद हम उन सभी प्रगति के साथ थोड़ा बेहतर कर सकते हैं। अभी भी 1024-बिट आरएसए से एक लंबा रास्ता तय करना है जब तक कि एक टन पैसा और समय बर्बाद करने वाला कोई व्यक्ति आपके आरएसए प्रमाणपत्र को तोड़ना नहीं चाहता है, यह साझा डीएच समूहों की तरह नहीं है, मूल्य वापसी से काफी छोटा है, जब तक कि आप के कब्जे में न हों कुछ डेटा जो हास्यास्पद रूप से मूल्यवान है और शारीरिक यातना/ब्लैकमेल जैसे सस्ते माध्यमों से प्राप्त नहीं किया जा सकता है।

यहां तक ​​​​कि अगर किसी के पास आपके आरएसए प्रमाणपत्र को तोड़ने पर बर्बाद करने के लिए ऐसे संसाधन थे, तो यह 1024-बिट्स नहीं है, 2048-बिट की कठिनाई 4 अरब गुना है, यह कुछ बड़ी सफलता के बिना नहीं होने वाला है, संभवतः एक कमजोरी जहां कुंजी लंबाई है चिंता का विषय नहीं है (बस टीएलएस में अन्य सभी कमजोरियों को देखें जिन्होंने इस तरह के आसपास काम किया है)। यदि आप 3072-बिट आरएसए से आगे चले गए और इसका उपयोग आपके एन्क्रिप्शन के लिए किया गया था जो 128-बिट कुंजियों का उपयोग करने के लिए हुआ था, तो आपका आरएसए प्रमाणपत्र कोई मायने नहीं रखता है, और एईएस के लिए 128-बिट एन्क्रिप्शन कुंजी को इसके बजाय सिर्फ हमला किया जा सकता है।

इसके अलावा, जैसा कि कहा गया है कि हम केवल आरएसए के बारे में बात कर रहे हैं, यदि आप केवल पीएफएस सिफर सूट का उपयोग कर रहे हैं, तो आपके पास जो भी संसाधन हैं, 2048 को तोड़ने की लागत की तुलना में आपके सर्वर या उपयोगकर्ताओं से समझौता करने के बेहतर तरीके हैं। -बिट आरएसए प्रमाणपत्र 90 दिनों से कम समय में...

OPENSSL_TLS_SECURITY_LEVEL=3 के लिए कम से कम 3072 बिट्स की आवश्यकता होती है।

और इसकी प्रासंगिकता है क्यों? वहाँ एक स्तर 5 है जो 15360 बिट्स की न्यूनतम आरएसए कुंजी लंबाई को अनिवार्य करता है, उस तर्क के साथ 3072 बिट्स पर क्यों रुकें?

जैसा कि लिंक किए गए दस्तावेज़ में कहा गया है, डिफ़ॉल्ट 1 है जब तक कि अन्यथा कॉन्फ़िगर न किया गया हो। क्या आप किसी मुख्यधारा के सॉफ्टवेयर के बारे में जानते हैं जो ओपनएसएसएल को स्तर 3 के साथ संकलित कर रहा है? अधिकांश समय जब ओपनएसएसएल का उपयोग किया जाता है, तो यह सिस्टम कॉपी से जुड़ा होता है, क्योंकि आप प्रत्येक एप्लिकेशन पर निर्भर किए बिना सुरक्षा अपडेट प्राप्त करना चाहते हैं, अपनी बंडल प्रतियों को अपडेट करते हैं (यह मानते हुए कि सॉफ़्टवेयर को नियमित रूप से बनाए रखा जाता है/पहले स्थान पर अपडेट किया जाता है, जो इस परिदृश्य में हमेशा नहीं होता है)।

डीएच एक्सचेंज की ताकत का अनुमान लगाने के लिए साइटों को स्कैन करें जो तब हो सकता है जब क्लाइंट प्रत्येक साइट से जुड़ता है

2016 में @schoen Chrome ने DHE सपोर्ट को गिरा दिया , उन्होंने ध्यान दिया कि DHE कनेक्शन का 95% 1024-बिट DH params के साथ था। ऐसा नहीं है कि यह अब बहुत मायने रखता है क्योंकि आधुनिक ब्राउज़र अब डीएचई सिफर सूट का समर्थन नहीं करते हैं।

मेल जैसे अन्य सर्वरों के लिए, यह अभी भी उपयोगी हो सकता है (हालांकि ईसीडीएचई समर्थन कुछ समय के लिए बहुत अच्छा रहा है, कुछ लिनक्स डिस्ट्रो जैसे आरएचईएल के पास 2014 के आसपास 6.5 तक समर्थन नहीं है)। DHE को RFC 7919 के आधिकारिक FFDHE समूहों का उपयोग करना चाहिए, जिनमें न्यूनतम 2048-बिट्स हैं। 1024-बिट सीमा वाले पुराने ग्राहकों में से कोई भी महत्वपूर्ण नहीं होना चाहिए, विशिष्ट परिस्थितियों के लिए जहां sysadmin इसे संबोधित करने के लिए भुगतान की स्थिति में होगा, लेकिन कई सुरक्षा समस्याएं हैं जिन्हें संभावित श्रृंखला सहित उस बिंदु पर चलाया जा सकता है एक सिस्टम पर रूट सर्टिफिकेट की समय सीमा समाप्त होने के कारण विश्वास की समस्या।

हो सकता है कि हम उपयोगकर्ताओं को अपने वेब ब्राउज़र को अपग्रेड करने के लिए प्रोत्साहित करने के लिए चल रहे कदमों के बारे में सोच सकते हैं, ताकि टीएलएस में इस्तेमाल होने वाले डीएच की मात्रा को बढ़ाया जा सके।

जब आपने यह सुझाव दिया था, तब Safari और Chrome ने DHE afaik की पेशकश नहीं की थी। इसका विपरीत परिणाम होगा, डीएचई को कम करना, यह मानते हुए कि उपयोगकर्ता पुराने सॉफ़्टवेयर चलाने वाले उपकरणों पर ब्राउज़र/क्लाइंट को अपग्रेड करने में सक्षम हैं। कुछ पुराने OS या सॉफ़्टवेयर पुराने TLS कार्यान्वयन (जैसे macOS / iOS सिक्योर ट्रांसपोर्ट) के लिए बंद हैं, जो TLS संस्करण समर्थन, समर्थित सिफर सुइट्स (macOS में 2015 के अंत तक IIRC की रिलीज़ तक AES-GCM की कमी) को प्रभावित करता है।

ओसीएसपी और सीटी लॉग जैसे अन्य सुरक्षा उपायों की अनदेखी करते हुए, जो यह सोचता है कि 2048-बिट आरएसए 90 दिनों के लिए पहचान सुरक्षा के लिए अपर्याप्त है, क्या आप विश्वास की श्रृंखला से अवगत हैं? आपका प्रमाणपत्र LetsEncrypt रूट और इंटरमीडिएट प्रमाणपत्रों के विरुद्ध सत्यापित है, यदि कोई किसी प्रमाणपत्र पर हमला करना चाहता है, तो किसी विशिष्ट साइट को जारी किए गए प्रमाणपत्र से समझौता करना अधिक मूल्यवान है।

यदि प्रमाण का उपयोग केवल प्रामाणिकता के लिए किया जा रहा है और किसी भी रिकॉर्ड किए गए ट्रैफ़िक को डिक्रिप्ट करने के लिए समझौता नहीं किया जा रहा है, तो आप अपनी वेबसाइटों की मुख्य लंबाई को अपनी पसंद के अनुसार बढ़ा सकते हैं, लेकिन इस सैद्धांतिक हमले से आप क्या हासिल कर रहे हैं जहां आप पहले की तुलना में सुरक्षित हैं विश्वास की श्रृंखला में समझौता किया जा रहा है? (जो 2048-बिट RSA का उपयोग करते हैं, ~ LE रूट सहित ~ ( संपादित करें: मेरा बुरा, LE RSA रूट 4096-बिट है ), जिसकी वैधता अवधि अधिक है, मध्यवर्ती के लिए 5 वर्ष और LE रूट के लिए 2035 तक)

यह मुद्दा अभी तक खुला क्यों है? यह स्पष्ट है कि जो उपयोगकर्ता इसका अनुरोध कर रहे हैं, वे टीएलएस में प्रासंगिकता को गलत समझते हैं, खासकर 2020 में।

टीएल; डीआर

* RSA certs only matter for **proving the identity of the server can be trusted**, and are being **replaced every 90 days**. It won't be compromised due to key length of 2048-bit within that time just to impersonate you.

ऐसा लगता है कि आप X.509 (और TLS :rofl:) को बेहतर नहीं समझते हैं... :rofl:
प्रमाणपत्र परेशानी नहीं है बल्कि कुंजी है। और X.509 दुनिया में, कुंजी को निरस्त करना संभव नहीं है... इसलिए 90 दिनों का रोलओवर यहां हमेशा प्रासंगिक नहीं होता है, और यह सर्वर के लिए एक परेशानी है जो ईसीडीएचई/डीएचई का उपयोग नहीं कर रहा है बल्कि सादे पुराने आरएसए प्रमाणीकरण का उपयोग कर रहा है। और 2020 में भी बहुत कुछ ऐसा ही है...

आप RSA-2048 की ताकत के लिए भी गलत मानते हैं। आपको न केवल समय की गणना किसी दी गई कुंजी को तोड़ने के लिए सबसे अच्छा वर्तमान तरीका है, बल्कि भविष्य में भी भविष्य में आपकी कुंजी अब सार्थक नहीं है। ईसीडीएचई/डीएचई नहीं (जो कि, मैं दोहराता हूं, इतना दुर्लभ नहीं) के मामले में, यह 90 डी नहीं बल्कि 10-30y है। और यह न केवल खाते में लेने का समय है, बल्कि लागत, प्रौद्योगिकी विकास और क्रिप्टो कमजोरी/चाल की खोज भी है। और यह आपके स्पष्टीकरण मामले में विशेष रूप से दिखाई दे रहा है।
RSA-256 को 09/2019 में एक मानक ~$1000 लैपटॉप पर ~60s में क्रैक किया गया था। लेकिन RSA-512 2015 में ~4h और ~$75 में टूट गया था।
https://www.doyler.net/security-not-included/cracking-256-bit-rsa-keys
https://eprint.iacr.org/2015/1000.pdf
दोनों के बीच निश्चित रूप से [यहां एक बड़ी संख्या डालें] गुणा अंतर नहीं है, लेकिन स्थिर लागत पर कम या ज्यादा 1.8 है।
यह आरएसए कुंजी फैक्टरिंग के लिए कैडो-एनएफएस बेंचमार्क में भी काफी दिखाई देता है। RSA-120 1.9h है, RSA-130 7.5h है (और उम्मीद के मुताबिक 81d नहीं), RSA-140 23h (और 227y नहीं) है और RSA-155 5.3d (और 7452 मिलेनियम नहीं) है।

यही कारण है कि ANSSI या NIST जैसी संस्थाएं न केवल आधुनिक कंप्यूटर क्षमताओं या क्रिप्टोग्राफी ज्ञान की वर्तमान स्थिति पर, बल्कि प्रमुख उपयोग / अर्थपूर्णता की समय सीमा में होने वाले भविष्य के सुधारों पर भी अपनी सिफारिशों को आधार बनाती हैं।

यह सर्वर के लिए एक परेशानी है जो ईसीडीएचई/डीएचई का उपयोग नहीं कर रहा है बल्कि सादे पुराने आरएसए प्रमाणीकरण का उपयोग कर रहा है। और यह काफी हद तक 2020 में भी है

तो यहां सुरक्षा में सुधार के लिए आपकी सलाह है कि पीएफएस केवल सिफर सूट को प्रोत्साहित करने के बजाय बड़े कुंजी आकार का उपयोग करने के लिए प्रोत्साहित किया जाए? क्यों?

आप RSA-2048 की ताकत के लिए भी गलत मानते हैं
आपको न केवल किसी दिए गए कुंजी को तोड़ने के लिए सबसे अच्छा वर्तमान तरीका समय की गणना करना है, बल्कि भविष्य में भविष्य में आपकी कुंजी अब और अधिक सार्थक नहीं है।

कृपया आगे विस्तार करें। पिछले एक दशक में आप किस मामले से अवगत हैं, यह गलत रहा है। 1024-बिट आरएसए के तथ्यात्मक/टूटे जाने का कोई ज्ञात मामला नहीं है, 2048-बिट को अकेला छोड़ दें, जिसमें इसकी सममित कुंजी शक्ति को देखते हुए एंट्रोपी के 2 ^ 32 बिट अधिक हैं।

1. 2048-बिट आरएसए 1024-बिट आरएसए से ~4 अरब गुना अधिक मजबूत है।
2. 3072-बिट केवल ~ 65k गुना अधिक मजबूत है (जब एनआईएसटी द्वारा आधिकारिक तौर पर परिभाषित 112-बिट्स की 128-बिट्स की सममित सुरक्षा की तुलना की जाती है)।
3. यदि हम मान लें कि 1024-बिट (80-बिट सममित कुंजी शक्ति) को 1 वर्ष की गणना शक्ति के भीतर समझौता किया जा सकता है। 2048-बिट के लिए यह 4 अरब वर्ष है।
4. आप दावा कर रहे हैं कि कुछ अज्ञात तकनीकी प्रगति उस गणना समय को बहुत कम कर सकती है, लेकिन 3072-बिट आरएसए को खतरा नहीं है?

हम 1024-बिट की तुलना 1 सेकंड के भीतर टूटने योग्य के रूप में कर सकते हैं, फिर 2048-बिट अभी भी 136 वर्षों के बराबर है ( (1/31536000) * 2^32 )। इस तरह की उपलब्धि होने से बहुत दूर है, अगर आप इस बात पर जोर देना चाहते हैं कि यह किसी भी तरह से एक वैध चिंता है, तो क्या आप जानते हैं कि 1 सेकंड में 512-बिट का भी गुणन होता है? 512-बिट आरएसए को पहली बार 1999 में 6 महीनों में फैक्टर किया गया था, 2015 के बाद से एक जीथब प्रोजेक्ट (एफएएएस) रहा है जो आपको 512-बिट आरएसए को फैक्टर करने के लिए 100 डॉलर से कम और कुछ घंटों के लिए आसानी से एडब्ल्यूएस का लाभ उठाने में सक्षम बनाता है।

इसे ध्यान में रखते हुए, 1024-बिट आरएसए लगभग 2^28 (~ 250k) से 2^30 (1 बिलियन) अधिक कठिन है (मेरे पास सटीक संख्या नहीं है, क्षमा करें, लेकिन ऐसा लगता है), और वर्तमान शिक्षाविद अभी भी उससे दूर होने के नाते, मुझे यकीन नहीं है कि आप कैसे सोचते हैं कि 1024-बिट आरएसए कहीं भी इतनी तेजी से गणना की जा रही है, जिसे 2048-बिट आरएसए से पहले होना चाहिए, इस तरह से टूटने के बारे में चिंता करने की कोई बात नहीं है। .

यहां सामान्य दृष्टिकोण जीएनएफएस (जनरल नंबर फील्ड चलनी) है, जो आवश्यक संसाधनों के साथ अधिक संभव हो जाता है, कुंजी आकार जितना बड़ा होता है । आरएसए फैक्टरिंग इतिहास का यह अच्छा चार्ट भी है, और एक संबंधित उत्तर जिसने 2048-बिट आरएसए को उसके आधार पर 2048 तक और 2015-2020 तक 1024-बिट का अनुमान लगाया है, जिसे अकादमिक रूप से अभी तक हासिल नहीं किया गया है।

उपरोक्त को ध्यान में रखते हुए, मैं आपको यह बताना चाहूंगा कि कैसे 3072-बिट आरएसए एक अतिरिक्त सुरक्षा लाभ प्रदान कर रहा है। यदि 2048-बिट आरएसए पर किसी अन्य तरीके से हमला किया जाता है या तकनीकी रूप से इतनी गति से आगे बढ़ता है, तो मुझे नहीं लगता कि 3072-बिट आरएसए कितना अतिरिक्त सुरक्षा प्रदान करेगा?

ईसीडीएचई / डीएचई नहीं होने की स्थिति में (जो कि, मैं दोहराता हूं, इतना दुर्लभ नहीं)

मुझे पसंद है कि आप कैसे दावा करते हैं कि यह "इतना दुर्लभ नहीं है", यह कितना आम है कि आप अपने हैंडशेक का सामना करते हैं, इन दिनों डीएचई या ईसीडीएचई के बजाय आरएसए कुंजी एक्सचेंज का उपयोग करते हैं? क्या आपके पास भी एक उदाहरण है?

यह 90d नहीं बल्कि 10-30y . है

मेरा मानना ​​​​है कि मैं प्रमाण पत्र के लिए 90 दिन की नवीनीकरण अवधि बताने में काफी स्पष्ट था, जब इसका उद्देश्य केवल प्रमाणीकरण की सेवा करना था, न कि प्रमुख विनिमय।

और यह न केवल खाते में लेने का समय है, बल्कि लागत, प्रौद्योगिकी विकास और क्रिप्टो कमजोरी/चाल की खोज भी है। और यह आपके स्पष्टीकरण मामले में विशेष रूप से दिखाई दे रहा है।

हाँ, लागत। जिन संसाधनों को मैंने आपको 1024-बिट RSA का हवाला देते हुए लिंक किया है, जिसमें GNFS को निष्पादित करने के लिए टेराबाइट्स RAM की आवश्यकता होती है, रैखिक कमी चरण को संभालने के लिए सबसे महंगा/कठिन हिस्सा है। घातीय कठिनाई के साथ यही बात है, जो कुछ सस्ता/आसान है वह बहुत तेजी से कठिनाई में बढ़ सकता है।

RSA-256 को 09/2019 में एक मानक ~$1000 लैपटॉप पर ~60s में क्रैक किया गया था। लेकिन RSA-512 2015 में ~4h और ~$75 में टूट गया था।

मैं पहले से ही Github प्रोजेक्ट से जुड़ा हूं जो AWS पर 512-बिट फैक्टरिंग कर सकता है। मुझे 256-बिट आरएसए के सममित एंट्रॉपी बिट्स की सटीक मात्रा नहीं है, शायद लगभग 30-बिट्स? (इसलिए लगभग 1,048,576 बार 512-बिट RSA के बीच अंतर होता है)। आपके द्वारा लिंक किए गए 512-बिट पेपर में 432 सीपीयू (36 वीसीपीयू + 60जीआईबी रैम के साथ 12 इंस्टेंस) और मैट्रिक्स के लिए 1.5-2 जीबी मेमोरी या स्टोरेज के साथ कुल 2770 सीपीयू घंटे का उल्लेख है (मैं इस गणना से बहुत परिचित नहीं हूं, यदि आप झंकार करने के लिए स्वतंत्र हैं)।

मेरा गणित शायद यहां खराब है, लेकिन उस जानकारी के आधार पर दो प्रणालियों की गणना शक्ति की तुलना करने का प्रयास करें, 2770 घंटे से मिनट 2770 * 60 = 166200 होंगे जिसकी तुलना हम 256-बिट आरएसए के 1 मिनट से log2(166200) = 17.34 के रूप में कर सकते हैं।

1991 में, 330-बिट आरएसए को दिनों के भीतर फ़ैक्टर किया गया था , बाद में एक इंटेल कोर2डुओ सीपीयू इसे एक घंटे से थोड़ा अधिक समय में संभाल सकता था। 256-बिट आरएसए उस समय से कम होता, इसे एक आशावादी 60 मिनट देता है और कहता है कि ~ 30 वर्षों के भीतर यह ~ 1 मिनट तक बढ़ गया है, 60 गुना की एक बड़ी कमी। यह 2^6 (64)... 6 बिट कहने के बराबर है। जैसा कि पहले बताया गया है, केवल समय के हिसाब से, न कि बढ़ी हुई रैम आवश्यकताओं जैसे संसाधनों को देखते हुए, यह अभी भी एक वैध खतरा होने से दूर है। अगले 30 वर्षों में 6 और बिट्स को बंद करें, और आपने 256-बिट आरएसए के 1 सेकंड के फैक्टरिंग को प्रबंधित किया है, बधाई हो, एक उचित समय सीमा में 2048-बिट आरएसए तक जाने के लिए लंबा रास्ता तय करना।

यहां तक ​​कि 512-बिट आरएसए के लिए 15 वर्षों में 6 महीने से 4 घंटे तक सुधार 24hr * (6month * 30day) = 4320hr / 4hr = log2(1080hr) = 10 ~2^10 है। यह निश्चित रूप से कमी से बेहतर है, ~ 1k गुना बेहतर, लेकिन फिर भी तुलना में खतरनाक दर नहीं है। मुझे लगता है कि आगे इस बात का समर्थन किया जाता है कि शिक्षाविदों के बड़े आरएसए प्रमुख आकारों को कारक बनाने में सक्षम होने के साथ प्रगति कैसे धीमी हो गई है।

यह आरएसए कुंजी फैक्टरिंग के लिए कैडो-एनएफएस बेंचमार्क में भी काफी दिखाई देता है। RSA-120 1.9h है, RSA-130 7.5h है (और उम्मीद के मुताबिक 81d नहीं), RSA-140 23h (और 227y नहीं) है और RSA-155 5.3d (और 7452 मिलेनियम नहीं) है।

गणना करने के लिए ये अपेक्षित समय कहाँ से प्राप्त किए जा रहे हैं? RSA-155 (उर्फ 512-बिट RSA) 6 महीने पहले 1999 में फैक्टर किया गया था , RSA-120 (397-बिट RSA) और RSA-130 (430-बिट RSA) इसी तरह केवल 1-2-सममित बिट्स अलग होने की संभावना है ? तो लगभग 4 गुना वृद्धि की उम्मीद की जा सकती है...?

यही कारण है कि ANSSI या NIST जैसी संस्थाएं न केवल आधुनिक कंप्यूटर क्षमताओं या क्रिप्टोग्राफी ज्ञान की वर्तमान स्थिति पर, बल्कि प्रमुख उपयोग / अर्थपूर्णता की समय सीमा में होने वाले भविष्य के सुधारों पर भी अपनी सिफारिशों को आधार बनाती हैं।

आपने ऐसा कुछ भी पर्याप्त प्रदान नहीं किया है जो इंगित करता है कि 2048-बिट आरएसए कहीं भी कमजोर है, यहां तक ​​​​कि ऐतिहासिक संदर्भ के साथ जहां उल्लेखनीय सुधार किए गए हैं, ऐसा नहीं लगता है कि यह घातीय वृद्धि के साथ प्रासंगिक है। ऐसा लगता है कि आप कुछ हद तक रैखिक दृष्टिकोण ले रहे हैं? मुझे उम्मीद है कि आप इस बात से अवगत होंगे कि 128-बिट एईएस को सुरक्षित क्यों माना जाता है (जाहिरा तौर पर ग्रोवर के एल्गोरिदम का उपयोग करके एक दिन क्वांटम कंप्यूटर के लिए कमजोर हो सकता है) और कहा जाता है कि 256-बिट एईएस को हमारे सौर मंडल की पूरी ऊर्जा की आवश्यकता होती है। bruteforce द्वारा दरार करने के लिए थक गया।

इसके अलावा, इस बात पर ध्यान दें कि कौन सा डेटा संवेदनशील है कि आप केवल पीएफएस-सक्षम सिफर सूट का उपयोग करने जैसे सर्वोत्तम अभ्यास पर विचार किए बिना इसे सुरक्षित रखने का प्रयास कर रहे हैं, जहां इस डेटा को संभावित रूप से अब से कई दशकों तक डिक्रिप्ट करने के लिए समस्याग्रस्त माना जाता है (काफी थोड़ा सा संवेदनशील डेटा अब से उतने महत्वपूर्ण दशक नहीं हैं जितने वर्तमान में हैं)।

टीएल; डीआर

यह काफी नीचे आता है। 2048-बिट को तोड़ना, भले ही अब से दशकों बाद भी, हास्यास्पद रूप से महंगा होने वाला है, लेकिन आशावादी बनें और कहें कि 1 मिलियन डॉलर और 10 साल (या यदि आप चाहें तो 1)।

• क्या यह हमलावर आप में विशेष रूप से अभी रुचि रखता है कि वे N उपयोगकर्ताओं के लिए आपके सर्वर ट्रैफ़िक को रिकॉर्ड करने के लिए सुसज्जित होने जा रहे हैं (जहाँ N भंडारण आवश्यकताओं से परे कोई मायने नहीं रखता है, क्योंकि आप असुरक्षित रूप से सभी एन्क्रिप्शन के लिए एक ही कुंजी का उपयोग कर रहे हैं) .
• यह ट्रैफ़िक X वर्षों के लिए रिकॉर्ड किया जा रहा है, जहाँ हर 90 दिनों में आपका प्रमाणपत्र बदल रहा है, प्रत्येक के लिए एक अलग हमले की आवश्यकता है (समय और $$$$)? या हमलावर पहले से जानता है कि वे किस विशिष्ट डेटा को रिकॉर्ड करना चाहते हैं, भले ही यह कई दशकों से पहले उन्हें विश्वास हो कि वे एन्क्रिप्शन को तोड़ सकते हैं?
• यह किसी भी तरह से आपके सर्वर या उपयोगकर्ता क्लाइंट को सीधे हैक करने और उस सिस्टम से समझौता करने से बेहतर रणनीति और सस्ता है (मेरा मतलब है कि वे पहले से ही यातायात पर कब्जा करने के लिए खुद को एक एमटीएम हमले में डाल चुके हैं और किसी भी तरह पर्याप्त धन के साथ आपके रहस्यों तक पहुंचने के लिए मृत हैं? ), क्या उनके पास अधिक व्यावहारिक हमले को चुनने के लिए उपलब्ध संसाधन नहीं होंगे?
• क्या आरएसए निजी कुंजी तक पहुंच प्राप्त करने के लिए किसी को सीधे धमकी देना या ब्लैकमेल करना सस्ता और आसान नहीं होगा? तब कुंजी की लंबाई कोई मायने नहीं रखती है, यदि आप स्मार्ट थे और पीएफएस केवल सिफर सूट का इस्तेमाल करते थे, तो यह रणनीति अप्रासंगिक होगी।

सू मूल रूप से...

पीएफएस सिफर सूट (डीएचई / ईसीडीएचई) को प्रोत्साहित करें, बैंडेड खराब सुरक्षा प्रथाओं में मामूली सुधार नहीं

तो यहां सुरक्षा में सुधार के लिए आपकी सलाह है कि पीएफएस केवल सिफर सूट को प्रोत्साहित करने के बजाय बड़े कुंजी आकार का उपयोग करने के लिए प्रोत्साहित किया जाए? क्यों?

क्योंकि LE का हाथ डिफ़ॉल्ट कुंजी आकार पर है, httpd कॉन्फ़िगरेशन पर नहीं। और LE पहले से ही httpd config को लागू करने के बजाय पहले से ही कार्रवाई करता है (https HTTP-01 पर अक्षम करना, TLS-SNI-01 को हटाने योग्य…)

कृपया आगे विस्तार करें।

ज़रूर। और सरल कैडो-एनएफएस का बेंचमार्क देखें। क्रैकिंग का समय अपेक्षित सैद्धांतिक समय नहीं है।
दो पूर्वाग्रहों के कारण व्यवहार में सैद्धांतिक कठिनाई अंतराल नहीं देखा जाता है। हम केवल कला के किसी दिए गए राज्य और उसी वर्तमान समय के लिए दरार समय की तुलना कर सकते हैं और सैद्धांतिक अंतराल की अपेक्षा कर सकते हैं (और व्यवहार में, यह मामला नहीं है, कैडो-एनएफएस देखें), लेकिन कुछ भी सुनिश्चित नहीं करता है कि एक्स + 1 बिट्स 2 है यदि हम वर्तमान ज्ञान और गणना शक्ति की तुलना करते हैं और 1 महीने बाद हमारे पास क्या होगा, तो X से कई गुना कठिन है।
और मेरे द्वारा दिए गए 2 उदाहरण भी देखें। 2015 और 2019 के बीच 256 और 512 बिट्स के बीच केवल 2 गुना अंतर है, समान शक्ति और लागत को देखते हुए, जहां सिद्धांत रूप में 10⁷⁷ गुना अंतर है।
और हम यह सुनिश्चित करने में सक्षम नहीं हैं कि कल 3072 आरएसए ब्रेक ट्रिक नहीं होगी जहां 4096 बिट सुरक्षित रहेंगे।

मैं पहले से ही Github प्रोजेक्ट से जुड़ा हूं जो AWS पर 512-बिट फैक्टरिंग कर सकता है। मुझे 256-बिट आरएसए के सममित एंट्रॉपी बिट्स की सटीक मात्रा नहीं है, शायद लगभग 30-बिट्स? (इसलिए लगभग 1,048,576 बार 512-बिट RSA के बीच अंतर होता है)। आपके द्वारा लिंक किए गए 512-बिट पेपर में 432 सीपीयू (36 वीसीपीयू + 60जीआईबी रैम के साथ 12 इंस्टेंस) और मैट्रिक्स के लिए 1.5-2 जीबी मेमोरी या स्टोरेज के साथ कुल 2770 सीपीयू घंटे का उल्लेख है (मैं इस गणना से बहुत परिचित नहीं हूं, यदि आप झंकार करने के लिए स्वतंत्र हैं)।

हाँ, यह बहुत बड़ी संख्या और अव्यावहारिक लगता है… पहले 512 बिट्स ब्रेक (1999) के समय, इसे अव्यावहारिक माना जाता था क्योंकि सुपर-कंप्यूटर की आवश्यकता किसी के पास नहीं होती थी। लेकिन वास्तव में, 2015 में इस तरह के बुनियादी ढांचे के लिए संबंधित एडब्ल्यूएस बिल है ... 4 घंटे के लिए $ 100 और कुछ वर्षों बाद व्यावहारिक रूप से, 1999 में अरबों अरबों अरबों के अंतर की तुलना में काफी तेज है।
https://arstechnica.com/information-technology/2015/10/break-512-bit-rsa-with-amazon-ec2-is-a-cinch-so-why-all-the-weak-keys/

2015 और 2019 के बीच 256 और 512 बिट्स के बीच केवल 2 गुना अंतर है, समान शक्ति और लागत को देखते हुए, जहां सिद्धांत रूप में 10⁷⁷ गुना अंतर है।

क्या नहीं। मैंने अपनी पोस्ट में आपको इस बारे में बहुत स्पष्ट कर दिया है कि 256-बिट और 512-बिट के बीच का अंतर 2^256 (आपका आधार 10, 10^77) नहीं है, बल्कि 2^20 या उससे कम के बीच का अंतर है। मैंने आपके दो उद्धृत फैक्टरिंग उदाहरणों की तुलना की, यह लगभग 2^17 था)।

मुझे यकीन नहीं है कि आप "2 गुना अंतर" का दावा कैसे कर रहे हैं? समान शक्ति और लागत? 256-बिट आरएसए को लगभग 1 मिनट में फैक्टर किया गया था, जिसमें 512-बिट आरएसए 166,200 मिनट के बराबर था (गणित को मेरी पिछली पोस्ट में उद्धृत किया गया था, अगर मैंने कोई गलती की है तो मुझे सही करने के लिए स्वतंत्र महसूस करें)।

और हम यह सुनिश्चित करने में सक्षम नहीं हैं कि कल 3072 आरएसए ब्रेक ट्रिक नहीं होगी जहां 4096 बिट सुरक्षित रहेंगे।

आप सचमुच 2048-बिट आरएसए के साथ ठीक होने जा रहे हैं, 3072-बिट आरएसए में सुरक्षा में "मामूली" सुधार है, मैंने इसे पहले ही समझाया है, ऐसा लगता है कि आपने इसे छोड़ दिया है या गलत समझा है? बहुत कम समय में 2048-बिट RSA असुरक्षित होने का एकमात्र तरीका यह है कि आपका 3072-बिट RSA प्रगति की दर से खतरे में पड़ने वाला है।

यदि आप सुरक्षित रहना चाहते हैं, तो कुंजी विनिमय के लिए RSA का उपयोग न करें। मैंने आपको एक वेबसाइट का हवाला देने के लिए कहा है जहां आरएसए कुंजी विनिमय की आवश्यकता है ((ईसी) डीएचई किसी भी कारण से समर्थित/बातचीत नहीं है), आप इसका उत्तर क्यों नहीं दे पाए हैं, आपने दावा किया है कि यह इतनी सामान्य घटना है कि यह ऊपर उठाने का औचित्य साबित करता है डिफ़ॉल्ट आरएसए कुंजी लंबाई? कृपया उस कथन का समर्थन करें। आपको ऐसे सर्वर मिल सकते हैं जो आरएसए को एक प्रमुख एक्सचेंज के रूप में पेश करते हैं, उनके पास सर्वर सिफर सूट चयन सक्षम होने की संभावना होगी और पीएफएस सिफर सूट का समर्थन करने वाले किसी भी क्लाइंट द्वारा बातचीत नहीं की जाएगी।

लेकिन वास्तव में, 2015 में इस तरह के बुनियादी ढांचे के लिए संबंधित एडब्ल्यूएस बिल है ... 4 घंटे के लिए $ 100 और कुछ वर्षों बाद व्यावहारिक रूप से, 1999 में अरबों अरबों अरबों के अंतर की तुलना में काफी तेज है।

हार्डवेयर की लागत $ 100 से काफी अधिक है, हास्यास्पद मात्रा नहीं है, लेकिन हां कंप्यूटिंग संसाधनों को आसानी से किराए पर लेने/पहुंचने की उपलब्धता ने इसे और अधिक सुलभ बना दिया है। उपयोग किए गए हार्डवेयर पर ध्यान दें, यह सस्ता/छोटा ईसी 2 उदाहरण नहीं था, जब गणना संसाधनों को किराए पर लेने की बात आती है तो ये काफी बड़ी मशीनें थीं, हमारे पास एक दशक से अधिक समय से 768-बिट आरएसए है, फिर भी आप एफएएस को नहीं देखते हैं सस्ते में इसे संभालने में सक्षम? 2048-बिट RSA अभी लंबा रास्ता तय करना है।

क्या आपके पास गणना करने के लिए एक अरब से अधिक की आवश्यकता वाले 512-बिट का दावा करने वाले किसी का स्रोत है? बहुत यकीन है कि 1999 में हार्डवेयर संसाधन जो कि केवल 6 महीनों में फैले हुए थे, अरबों की लागत से भी एक लंबा रास्ता तय किया था। यह कीमत कहां से आ रही है? सुरक्षा के उच्च बिट्स के बारे में हाल के बयानों से? यह कठिनाई में घातीय वृद्धि के कारण है, जिसके लिए न केवल अधिक गणना समय की आवश्यकता होती है, बल्कि रैम जैसे अन्य संसाधनों की भी आवश्यकता होती है। उन 512-बिट आरएसए फैक्टरिंग एडब्ल्यूएस उदाहरणों में 60 जीबी रैम थी, प्रत्येक (कुल 720 जीबी) ...

कुछ प्रसंस्करण अंतर्दृष्टि पर त्वरित नज़र डालें:

आरएसए-250 (829-बिट्स आरएसए) जिसे 2020 में फैक्टर किया गया था, 3 महीने के भीतर हजारों कंप्यूटरों के साथ हासिल किया गया था और सीएडीओ-एनएफएस का उपयोग करके जिसे आप लाना चाहते हैं, ऐसा लगता है कि उन्होंने लगभग ~ में फैक्टरिंग हासिल कर ली है। 2015 में 512-बिट आरएसए के एडब्ल्यूएस फैक्टरिंग के रूप में गणना समय ~ ( संपादित करें: मेरी गलती, वर्ष, घंटे नहीं) की समान मात्रा (लगभग 2700 सीपीयू घंटे, संदर्भित इंटेल ज़ीऑन गोल्ड 6130 2.1GHz के लिए सामान्यीकृत AFAIK)। दिसंबर 2019 में फैक्टर किया गया RSA-240 (795-बिट RSA) दिलचस्प है कि यह उसी टीम द्वारा और उसी हार्डवेयर पर था जिसने 2010/2016 में 768-बिट RSA को फैक्टर किया था (CADO-NFS का उपयोग करके भी)। उन्होंने CADO-NFS सॉफ़्टवेयर में एल्गोरिथम सुधारों को नोट किया क्योंकि यह ~3x प्रदर्शन लाभ के लिए अनुमत है।

यहां 768-बिट आरएसए के 2010 के फैक्टरिंग पर पेपर है , रैम आवश्यकताओं को देखें:

पहले चरण को उन समूहों पर समानांतर में चलने वाली आठ स्वतंत्र नौकरियों में विभाजित किया गया था, प्रत्येक आठ अनुक्रमों में से प्रत्येक 214 चरणों में एक बार चेक-पॉइंटिंग के साथ। पहले (या तीसरे) चरण अनुक्रम को चलाने के लिए 180 जीबी रैम की आवश्यकता होती है , एक 64 बिट चौड़ा ¯b 1.5 गीगाबाइट लेता है, और एक मील मैट्रिक्स 8 किलोबाइट लेता है, जिसमें से 565 000 औसतन, पहले चरण अनुक्रम में रखा गया था। तीसरे चरण के मूल्यांकन के दौरान प्रत्येक आंशिक योग के लिए 12 गीगाबाइट की आवश्यकता होती है ।

अधिकांश समय उपलब्ध 896 जीबी रैम पर्याप्त होती है, लेकिन गणना के मध्य भाग के दौरान अधिक मेमोरी की आवश्यकता होती है (लगभग 1 टीबी तक)

और इसके विपरीत 512-बिट आरएसए फैक्टरिंग (2009, 2015 में एडब्ल्यूएस एक नहीं) के विपरीत:

2009 तक, बेंजामिन मूडी केवल सार्वजनिक सॉफ्टवेयर (जीजीएनएफएस) और अपने डेस्कटॉप कंप्यूटर (1,900 मेगाहर्ट्ज सीपीयू के साथ एक डुअल-कोर एथलॉन 64) का उपयोग करके 73 दिनों में एक आरएसए-512 बिट कुंजी को कारक बना सकता था। बस पांच गीगाबाइट से कम डिस्क भंडारण की आवश्यकता थी और लगभग 2.5 गीगाबाइट रैम को छानने की प्रक्रिया के लिए।

जैसे-जैसे कुंजी की लंबाई बढ़ती है, वैसे-वैसे RAM आवश्यकताओं को स्केलिंग का एक मोटा पैमाना देना चाहिए। मुझे यकीन है कि प्रसंस्करण के बारे में जागरूक होने के लिए शायद अन्य बाधाएं हैं, खासकर जब वितरित फैशन में ऐसा करते हैं। बेझिझक इसे आगे देखें और पहचानें कि 2048-बिट RSA पर हमला करने के लिए कितनी RAM की आवश्यकता होगी।

आप वास्तव में किससे खुद को बचाने की कोशिश कर रहे हैं जो आपको या आपके उपयोगकर्ताओं के ट्रैफ़िक को लक्षित करने के लिए विशेष रूप से इसे रिकॉर्ड करने और अब से दशकों बाद हमला करने के लिए सुसज्जित है?

कुछ स्क्रिप्ट किडी $ 100 AWS समाधान पर प्रतीक्षा नहीं कर रहे हैं, वे तब तक बेहतर चीजों की ओर बढ़ चुके होते और ट्रैफ़िक रिकॉर्ड करने के लिए आपके नेटवर्क से समझौता करने पर उन्हें बहुत अधिक खर्च करना पड़ता, अन्यथा यह कुछ मैलवेयर है जहाँ किसी विशेष को लक्षित नहीं किया गया था, आपके रिकॉर्ड किए गए डेटा को विभाजित करने के लिए बधाई। प्रति आरएसए कुंजी के 90 दिन की अवधि में अब कई अन्य लोगों के समुद्र में है, हजारों, लाखों शायद, $ 100 एडब्ल्यूएस भले ही उन सभी पर हमला करने के लिए बहुत सस्ता नहीं होगा, खासकर जब डेटा का अज्ञात मूल्य होता है, तो एक होगा पैसे फेंकने के लिए बहुत सारे कबाड़।

नहीं, अगर कोई आपके रहस्यों को चाहता है तो और भी किफायती तरीके हैं।

किसी कारण से, आपको विश्वास है कि 1024-बिट से 2048-बिट आरएसए की 4 अरब गुना मजबूत सुरक्षा अपर्याप्त है, लेकिन 2048-बिट से 3072-बिट आरएसए तक 65k गुना अधिक सुरक्षा पर्याप्त है। आपका तर्क यह है कि 2048-बिट का सुरक्षा सिद्धांत कम्प्यूटेशनल रूप से सुरक्षित है, लेकिन कुछ कैसे 3072-बिट आरएसए के लिए वही तर्क लागू नहीं होता है और यह इतना सुरक्षित है? क्या कांच का दरवाजा सुरक्षित है क्योंकि मैं बड़े और अधिक सुरक्षित ताले जोड़ता हूं?

टीएल; डीआर

कृपया पिछले टीएल; डीआर पर जाएं, लेकिन मैं फिर से दोहराऊंगा ..

• कोई कमजोर 2048-बिट RSA कुंजी का उपयोग करके आपके एन्क्रिप्टेड ट्रैफ़िक को रिकॉर्ड करना चाहता है।
• वे इस मिटम हमले को करने में सक्षम हैं, इस प्रकार उनके पास कौशल या पैसा है और यह शायद एक लक्षित हमला है।
• आपके डेटा को भविष्य में इसके मूल्य को बनाए रखना चाहिए जिसे अभी हासिल करना वांछनीय है, भले ही इसे आपके अनुमानों द्वारा केवल 20+ वर्षों में डिक्रिप्ट किया जा सके।
• रहस्य के मूल्य को प्राप्त करने के लिए किए जाने वाले लागत के लिए हमले को उचित होना चाहिए, यह पता होना चाहिए कि कौन सी 90 दिन की खिड़की पर कब्जा करना है, अन्यथा कथित रहस्य को प्राप्त करने की उम्मीद में हमले की कई बार गणना की जानी चाहिए।
• उक्त डेटा को शीघ्र/सस्ता तरीके से प्राप्त करने के लिए किसी भी अन्य तरीके से यह हमला किसी भी तरह से अधिक प्रभावी है?

उनके सही दिमाग में ऐसा करने वाला कौन है? यह केवल एक उच्च मूल्य लक्ष्य पर व्यावहारिक होने जा रहा है जहां उस जानकारी को प्राप्त करने का कोई अन्य साधन व्यवहार्य नहीं है। कहा गया लक्ष्य किसी तरह ऐसे मूल्यवान रहस्यों के कब्जे में है, लेकिन किसी पेशेवर को भुगतान करने या उन्हें सुरक्षित करने में सर्वोत्तम प्रथाओं पर विचार करने की जहमत नहीं उठाता (वे स्पष्ट रूप से मोज़िला के सिफर सूट सलाह की प्रतिलिपि/पेस्ट के साथ एक सर्वर स्थापित नहीं कर सकते हैं)।

यह बहुत आश्वस्त करने वाला नहीं है। यह LetsEncrypt नहीं है, आप मान रहे हैं कि मूल्यवान रहस्यों वाला उपयोगकर्ता Certbot का उपयोग करता है, RSA के साथ केवल उनके सर्वर द्वारा समर्थित कुंजी एक्सचेंज सिफर सूट (कोई डिफ़ॉल्ट कॉन्फ़िगरेशन ऐसा नहीं करता है), और यह कि 2048-बिट RSA इससे बहुत कमजोर है? यह उपयोगकर्ता कोई भी हो, कहीं और उनकी सुरक्षा प्रथाएं संभवतः उनसे सीधे समझौता करने के लिए पर्याप्त कमजोर हैं, डेटा को डिक्रिप्ट करने के लिए 20-30 वर्षों का इंतजार क्यों करें जब आप एक सक्रिय हमला कर सकते हैं और वर्तमान में सभी रसदार डेटा प्राप्त कर सकते हैं?

सही समाधान सिफर सुइट्स को ठीक से सेटअप करना है, और यह प्रोजेक्ट Certbot ठीक वैसा ही करता है यदि आप इस क्षेत्र में अनुभवहीन हैं और आपके लिए इसकी देखभाल करते हुए इस पर भरोसा करना चाहते हैं। लेकिन किसी कारण से, यह इस चर्चा पर लागू नहीं होता है?

मैंने आपको एक वेबसाइट का हवाला देने के लिए कहा है जहां आरएसए कुंजी विनिमय की आवश्यकता है ((ईसी) डीएचई किसी भी कारण से समर्थित/बातचीत नहीं है)

https://cryptcheck.fr/https/bankofamerica.com (हां, आपने इसे सही पढ़ा)
https://cryptcheck.fr/https/caf.fr (फ्रांस के लिए राज्य प्रशासन, यूएस पूरक सुरक्षा आय के बराबर)
https://cryptcheck.fr/https/xn--trkiye-3ya.gov.tr
https://cryptcheck.fr/https/pfisng.dsna-dti.aviation-civile.gouv.fr
https://cryptcheck.fr/https/reader.xsnews.nl
https://cryptcheck.fr/https/protecpo.inrs.fr
https://cryptcheck.fr/https/tiscali.it

मैं अपने क्रिप्टचेक v2 पर 7221 हैंडशेक विश्लेषण (~0.9%) और 2091 से अधिक 349961 हैंडशेक विश्लेषण (~0.6%) पर अपने v1.

https://www.bankofamerica.com/

प्रोटोकॉल: टीएलएस 1.2
मुख्य विनिमय: ECDHE_RSA
प्रमुख विनिमय समूह: P-256
सिफर: एईएस_128_जीसीएम
सीए: सौंपना

माना जाता है कि https://cryptcheck.fr/https/bankofamerica.com उसी डोमेन के लिए अतिरिक्त सर्वर आईपी की पहचान कर रहा है जो ईसीडीएचई कुंजी एक्सचेंज प्रदान नहीं करता है?

https://www.caf.fr/

प्रोटोकॉल: टीएलएस 1.2
मुख्य विनिमय: आरएसए
सिफर: AES_128_CBC HMAC-SHA1 के साथ
सीए: सर्टिंगा

मुझे नहीं पता कि यह वेबसाइट किस बारे में है या इसके कौन से संवेदनशील रहस्य हैं?

https://www.turkiye.gov.tr/

प्रोटोकॉल: टीएलएस 1.2
मुख्य विनिमय: आरएसए
सिफर: AES_128_CBC HMAC-SHA1 के साथ
सीए: ग्लोबलसाइन

मुझे आपके अजीब दिखने वाले डोमेन नाम से इस पर पुनर्निर्देशित किया गया था कि मैं कल्पना नहीं कर सकता कि कोई भी सीधे यात्रा करेगा और इसे किसी नाम के वैध/भरोसेमंद मानेगा।

यह कई अन्य लोगों की तरह स्पष्ट रूप से एक सरकारी वेबसाइट है। वे अक्सर पीछे रह जाते हैं और उन्हें व्यापक दर्शकों द्वारा सुलभ होने की आवश्यकता होती है, हालांकि आरएसए डिफ़ॉल्ट कुंजी एक्सचेंज नहीं होना चाहिए, लेकिन फिर से, यहां कौन से संचार हो रहे हैं जिनसे आप स्वयं को सुरक्षित रखना चाहते हैं? जाहिर तौर पर सरकार खुद भी ज्यादा चिंतित नहीं दिख रही है।

https://pfisng.dsna-dti.aviation-civile.gouv.fr/jts/auth/authrequired

प्रोटोकॉल: टीएलएस 1.2
मुख्य विनिमय: आरएसए
सिफर: एईएस_128_जीसीएम
सीए: सर्टिंगा

फिर, कोई सुराग नहीं कि यह लॉगिन के साथ सरकारी सेवा के अलावा और क्या है। क्या लॉगिन विवरण से परे कोई संवेदनशील जानकारी है? अब से 20-30 साल बाद संवेदनशील जानकारी तक पहुंच को लेकर यहां क्या चिंताएं हैं? कि मैं उसी उपयोगकर्ता नाम और पासवर्ड का कहीं और उपयोग करता हूं और अभी भी 20-30 वर्षों के समय में ऐसा करना जारी रखता हूं?

यदि लॉगिन विवरण वांछित थे (और खातों पर डेटा का मूल्य) तो क्या फ़िशिंग घोटाला उतना प्रभावी नहीं होगा। क्या इसे आरएसए प्रमाणपत्र पर हमला करने की तुलना में कम समय या छोटे बजट में हासिल किया जा सकता है?

https://reader.xsnews.nl/

यूआरएल लोड/समाधान करने की कोशिश में एक मिनट से अधिक समय व्यतीत करने के बाद, मैं इस वेबसाइट तक नहीं पहुंच सका।

https://protecpo.inrs.fr/ProtecPo/jsp/Accueil.jsp

प्रोटोकॉल: टीएलएस 1.2
मुख्य विनिमय: आरएसए
सिफर: एईएस_128_जीसीएम
सीए: GEANT

ऐसा लगता है कि यह कुछ सॉफ़्टवेयर के लिए एक वेबसाइट है जिसका उपयोग आप खरीदारी का निर्णय लेने में सहायता के लिए कर सकते हैं। यहां कौन सी संवेदनशील जानकारी खतरे में है?

https://www.tiscali.it/

प्रोटोकॉल: टीएलएस 1.2
मुख्य विनिमय: आरएसए
सिफर: AES_256_CBC HMAC-SHA1 . के साथ
सीए: थावटे

एक समाचार साइट? फिर से कौन सी संवेदनशील जानकारी इस वेबसाइट के साथ बातचीत करने से संबंधित है?

सारांश

इनमें से किसी भी परिणाम में ऐसा कुछ भी नहीं है जो 2048-बिट आरएसए के अनुमानित 20-30 वर्षों से अधिक संवेदनशील संचार की रक्षा करने की आवश्यकता को इंगित करता हो। इन वेबसाइटों को अभी भी क्लाइंट और सर्वर के बीच उस ट्रैफ़िक को पकड़ने के लिए एक प्रभावी एमआईटीएम हमले की आवश्यकता होगी जो उनमें से किसी के लिए एक वैध चिंता की संभावना नहीं है?

इनमें से कोई भी LetsEncrypt जारी किए गए प्रमाणपत्रों का उपयोग नहीं करता है। Certbot के लिए परिवर्तन करना केवल तभी फायदेमंद होता है जब आप निश्चित रूप से जानते हैं कि वे वेबसाइटें Certbot का उपयोग विशेष रूप से उन CA के लिए ACME क्लाइंट के रूप में कर रही हैं (यह मानते हुए कि उनके पास तृतीय-पक्ष ACME समर्थन है)।

वास्तव में कुछ वेबसाइटों को इंगित करने के लिए धन्यवाद जहां आरएसए बातचीत की गई कुंजी एक्सचेंज है (बैंक ऑफ अमेरिका को छोड़कर जो गलत लगता है और केवल सार्वजनिक सामना करने वाली वेबसाइट के लिए सिफर सूट के रूप में मान्य किया गया है, न कि कोई वास्तविक संवेदनशील एक्सचेंज)।

मैं अपने क्रिप्टचेक v2 पर 7221 हैंडशेक विश्लेषण (~0.9%) और 2091 से अधिक 349961 हैंडशेक विश्लेषण (~0.6%) पर अपने v1.

ठीक है, तो आपकी "दुर्लभ नहीं" 7,221 और 349,961 वेबसाइटों में से 1% से कम है जिसे आपने CryptCheck से स्कैन किया है? अब उन संचारों को सुरक्षित करने के लिए 3072-बिट आरएसए का उपयोग करके पेश किए गए दर्शकों और वास्तविक मापन योग्य मूल्य पर विचार करें, क्या यह वास्तव में कुछ सार्थक हासिल कर रहा है और क्या यह सुरक्षा से समझौता करने के लिए सस्ते विकल्पों के खिलाफ अब सुरक्षित होगा? (जैसा कि, किसी भी अन्य वैकल्पिक लक्षित हमले की तुलना में 2048-बिट कमजोर/सस्ता था, जहां 3072-बिट हमले की निचली सीमा को बढ़ाता है)

एलेक्सा की शीर्ष 10 लाख साइटों में से कितनी आरएसए कुंजी एक्सचेंज पर बातचीत कर रही हैं? उनमें से कितने लोग LetsEncrypt को CA के रूप में उपयोग करते हैं?

मैंने 512-बिट और 256-बिट आरएसए (एनआईएसटी से समीकरण के आधार पर) के लिए सममित बिट्स की गणना की , और हमें 40-बिट्स (256-बिट आरएसए), और 57-बिट्स (512-बिट आरएसए) मिलते हैं।

दिलचस्प बात यह है कि हाल की प्रगति के साथ दो गणना वार की तुलना करते समय पहले उद्धृत 17-बिट अंतर से मेल खाता है (ऐसा प्रतीत होता है कि एनआईएसटी दस्तावेज़ जिसे मैंने संदर्भित किया था वह आखिरी बार 2020 में अपडेट किया गया था)।

इससे यह भी पता चलता है कि 1024-बिट आरएसए की दूरी केवल 23-बिट्स के समतुल्य सममित कुंजी शक्ति, 8,388,608 है। और हम देख सकते हैं कि 768-बिट और 795-बिट आरएसए के लिए वर्तमान प्रगति या 829-बिट आरएसए का वर्तमान रिकॉर्ड है:

768 == 69.74588053597235
795 == 70.91595938496408
829 == 72.35600867501326

• 2010 के बाद से 768-बिट आरएसए रिकॉर्ड, 2020 में रिकॉर्ड के रूप में 829-बिट आरएसए के साथ, एक दशक की अवधि में 3-बिट्स से कम सुधार। 2000 बनाम 2700 सीपीयू वर्ष (सिंगल-कोर)। नवंबर 2019 में 795-बिट RSA घटकर 900 CPU वर्ष रह गया।
• 57-बिट (512-बिट आरएसए) से 72-बिट (829-बिट आरएसए) ~ 2700 गणना घंटे के साथ ~ ( संपादित करें: घंटे बनाम साल, ओह) 2015 और 2020 के बीच। ~ 15-बिट्स (32,768) सुधार ~? (829-बिट आरएसए में 3 महीने लगे और तुलनात्मक रूप से हजारों मशीनें)। 768-बिट (दिसंबर 2009) और 795-बिट (नवंबर 2019) आरएसए फैक्टरिंग अकेले सॉफ्टवेयर/एल्गोरिदम सुधारों के कारण लगभग 3x तेज होने पर प्रकाश डाला गया।
• 1991 के बाद से 256-बिट RSA सुधार के लिए 2^6 (64) अनुमान।
• ~ 2 ^ 10 (1024) 16 साल से अधिक 512-बिट के साथ 1080 x अंतर के लिए (1999 - 2015) 6 महीने बनाम 4 घंटे, यह स्पष्ट नहीं है कि यह तुलना कितनी सटीक है, 8,000 एमआईपीएस वर्ष बनाम 2770 साल इंटेल सीपीयू आमतौर पर संदर्भित। यहां मुख्य अंतर संभवत: समय को कम करने के लिए क्लाउड कंप्यूट के साथ सस्ते में किराए के हार्डवेयर तक पहुंच के कारण था, जबकि 15 साल के एचडब्ल्यू सुधार और सॉफ्टवेयर में एल्गोरिदम सुधार का लाभ उठाना।

मैंने अभी-अभी महसूस किया है कि मैंने 829-बिट RSA फैक्टरिंग का हवाला देते हुए और AWS 512-बिट RSA फैक्टरिंग समय से इसकी तुलना करते हुए पहले एक गलती की है। वे दोनों समय की ~ 2700 गणना इकाइयों का हवाला देते हैं, लेकिन मैं 829-बिट आरएसए वर्षों के साथ, और 512-बिट आरएसए घंटे के साथ फिसल गया। यह लगभग 8,760 ( (8760hrs * 2700yrs) / 2700hrs , जहां 8,760 एक वर्ष में घंटे है) का अंतर प्रतीत होता है (2 ^ 13) जो मुझे लगता है कि 4 साल ( (4hrs * 8760hrs) / 24hrs / 365days ) है जो करीब होगा AWS पर एक मिलियन डॉलर का कंप्यूट टाइम? (इस तथ्य को अनदेखा करते हुए कि आपको शायद थोड़ी अधिक रैम की आवश्यकता है)

256-बिट आरएसए 1 मिनट की गणना समय बनाम 829-बिट आरएसए 2700 वर्ष गणना समय = log2(525600mins * 2700yrs) (एक वर्ष में मिनट) लगभग 2^30 के बराबर है। फिर से, 512-बिट RSA गणना कठिनाई के समान, यह शक्ति में अनुमानित 2^32 बिट अंतर के डेल्टा के बहुत करीब है। हम आरएसए कुंजी को तेजी से कारक करने में सक्षम हो सकते हैं, लेकिन गणना की कठिनाई मोटे तौर पर बनी रहती है?

सबसे बड़ी जानकारी नहीं है, लेकिन पर्याप्त है कि हमें प्रगति और सुधार की दर का एक मोटा विचार मिलता है।

• गणना करने में कठिनाई दशकों से लगभग सटीक और सुसंगत है?
• तेजी से फैक्टरिंग करने के लिए बेहतर गणना की दर में अच्छी तरह से सुधार हुआ है, लेकिन एक महत्वपूर्ण राशि से नहीं?

1024-बिट अभी भी कुछ समय के लिए पहुंच से बाहर रहने वाला है, और 2048-बिट और भी अधिक ऐतिहासिक प्रगति के आधार पर ऊपर कवर किया गया है। इस बात के बहुत कम प्रमाण हैं कि 3072-बिट आरएसए इसके अतिरिक्त 2^16 (65के) से 2^22 (4 मिलियन) अतिरिक्त कठिनाई के बिट्स के साथ 2^30 (1 बिलियन) से 2 ^ की तुलना में अधिक सुरक्षा लाभ की राशि होगी। 32 (4 बिलियन) 2048-बिट में 1024-बिट RSA से अधिक है। (ऐसा नहीं है कि यह उल्लेखनीय अतिरिक्त कठिनाई नहीं जोड़ता है, लेकिन इस धारणा के आधार पर कि 2048-बिट आरएसए स्वयं पर्याप्त रूप से पर्याप्त नहीं होगा जब इसे करना चाहिए)

वर्तमान 829-बिट RSA प्रयास के आधार पर, और 2048-बिट RSA के लिए बिट्स के सुरक्षा स्तर में लगभग 38-बिट अंतर है। यदि हम निरंतर कंप्यूटिंग शक्ति लेते हैं जो 3 महीनों में 829-बिट आरएसए (एक वर्ष में 4 तीन महीने की अवधि) का कारक है, तो हमें 68,719,476,736 वर्ष ( 2^38 / 4 ) मिलते हैं, भले ही हमारे पास इसे 1 तक लाने के लिए प्रगति हो। अरब गुना कम काम (2^30), यह अभी भी लगभग 64 साल है, और यह हजारों मशीनों के साथ है ।

यदि आप अभी भी सोचते हैं कि मेरे (संभवतः खराब?) गणित, लागत-लाभ विश्लेषण, और सामान्य ज्ञान तर्क के बावजूद न्यूनतम के रूप में 3072-बिट सार्थक है ... .

बस याद रखें कि आप Certbot के साथ बदलाव की वकालत कर रहे हैं, न कि LetsEncrypt न्यूनतम मुद्दे को लागू करने के लिए। सर्टबॉट पहले से ही उचित सिफर सूट को कॉन्फ़िगर करके उपयोगकर्ताओं की मदद करता है जो वैसे भी पूरी समस्या से बचते हैं, इसलिए वास्तव में यहां किसे फायदा होने वाला है - जबकि बाकी सभी (सर्टबॉट का उपयोग करके) जिनके पास आरएसए नहीं है, उन्हें कुंजी एक्सचेंज के रूप में उपयोग किया जा रहा है और अधिक लोड और बैंडविड्थ जोड़ रहा है। उनके सर्वर (भले ही अधिकांश के लिए मामूली हों)।

मुद्दा बंद होना चाहिए।

https://www.keylength.com/

https://www.keylength.com/

आपने 4 साल पहले इस सूत्र में उस जानकारी का योगदान दिया था । ऐसा प्रतीत नहीं होता है कि आप उस वेबसाइट की सलाह के संदर्भ को समझते हैं और यह यहां कैसे लागू होता है।

यदि आप अपने प्रमाणपत्रों के लिए 3072-बिट आरएसए या बड़ी कुंजी लंबाई के साथ अधिक सहज महसूस करते हैं, तो स्पष्ट रूप से ऑप्ट-इन करें जैसे कि आप पहले से ही कर सकते हैं, 3072-बिट को नए डिफ़ॉल्ट के रूप में अपनाने के लिए व्यावहारिक सुरक्षा की देखभाल करते समय कोई उचित कारण नहीं है . 2048-बिट आरएसए पर्याप्त है ।

आपने 4 साल पहले इस सूत्र में उस जानकारी का योगदान दिया था । ऐसा प्रतीत नहीं होता है कि आप उस वेबसाइट की सलाह के संदर्भ को समझते हैं और यह यहां कैसे लागू होता है।

आप अधिक नहीं समझते हैं। ANSSI सलाह उदाहरण के लिए है

प्रशासन और उपयोगकर्ताओं के बीच टेलीसर्विसेज और इलेक्ट्रॉनिक एक्सचेंजों के विकास के हिस्से के रूप में, प्रशासनिक अधिकारियों को इन सेवाओं के कार्यान्वयन के प्रभारी अपनी सूचना प्रणाली की सुरक्षा की गारंटी देनी चाहिए।
सामान्य सुरक्षा संदर्भ विशेष रूप से प्रशासनिक अधिकारियों द्वारा एक दूसरे के साथ संबंधों में और उपयोगकर्ताओं के साथ उनके संबंधों में लागू सूचना प्रणालियों पर लगाया जाता है (ये टेलीसर्विसेज हैं जैसे प्रशासन को जुर्माना का भुगतान)।
परोक्ष रूप से, सामान्य सुरक्षा संदर्भ उन सभी सेवा प्रदाताओं के लिए अभिप्रेत है जो प्रशासनिक अधिकारियों को उनके द्वारा कार्यान्वित इलेक्ट्रॉनिक एक्सचेंजों को सुरक्षित करने में सहायता करते हैं, साथ ही उन निर्माताओं के लिए जिनकी गतिविधि उत्पादों की पेशकश करना है। सुरक्षा का।
सामान्य तौर पर, अपनी सूचना प्रणाली और इलेक्ट्रॉनिक एक्सचेंजों की सुरक्षा के प्रबंधन को व्यवस्थित करने के इच्छुक किसी भी अन्य संगठन के लिए, सामान्य सुरक्षा संदर्भ को कला की स्थिति के अनुसार अच्छे अभ्यासों की मार्गदर्शिका के रूप में प्रस्तुत किया जाता है।

और इसलिए फ्रांस में किसी भी उद्देश्य और किसी भी तरह से लागू होता है, और सैन्य उद्देश्य जैसे समझदार संदर्भ तक ही सीमित नहीं है।

और सलाह में से एक है "कम से कम 3072 बिट्स के मॉड्यूल का उपयोग करने की अनुशंसा की जाती है, यहां तक ​​​​कि 2030 से अधिक के उपयोग के लिए भी "। और 3072 बिट्स अब एक सलाह नहीं है, लेकिन 2030 के बाद उपयोग/प्रभाव की उम्मीद होने पर अनिवार्य है।

यहां तक ​​कि CNIL, गोपनीयता और अच्छे अभ्यास के बारे में फ्रेंच इकाई, किसी भी वेबसाइट के लिए मानक अनुशंसा में ANSSI पेपर का उपयोग करती है: https://www.cnil.fr/fr/securite-securiser-les-sites-web

ANSSI ने TLS को लागू करने या किसी वेबसाइट को सुरक्षित करने के लिए अपनी साइट विशिष्ट सिफारिशों को प्रकाशित किया है।

(और लेट्स एनक्रिप्ट के विरोध में भी है क्योंकि यह बताते हुए कि आपको you must authorize only incoming IP network flows on this machine on port 443 and block all the other ports. करना है लेकिन यह )

एनआईएसटी सलाह सूचना देने की संवेदनशीलता के लिए बाध्य नहीं है, लेकिन सामान्य सलाह उन सभी मामलों में लागू होती है जिन्हें आपको कुंजी या प्रमाण भी प्रबंधित करना होता है।

यह पहली बार नहीं है जब LE सरकारी एजेंसी या अन्य से अत्याधुनिक सलाह के विरोध में डिफ़ॉल्ट कॉन्फ़िगरेशन का उपयोग करता है…

ओह, और बीएसआई समीक्षा यह इस साल सलाह देता है। यह बताता है

महत्वपूर्ण नोट: सभी असममित तंत्रों के लिए एक समरूप सुरक्षा स्तर प्राप्त करने के लिए, आरएसए, डीएच, और डीएसएस के लिए 3000 बिट्स की एक प्रमुख लंबाई का उपयोग करना उचित है । 2023 से, क्रिप्टोग्राफिक कार्यान्वयन के लिए कम से कम 3000 बिट्स की एक महत्वपूर्ण लंबाई की आवश्यकता होती है जो इस तकनीकी दिशानिर्देश का अनुपालन करेगी।

@aeris भले ही फ्रांस 3072-बिट RSA को अनिवार्य रूप से लागू कर रहा हो, यह कहीं और कानून नहीं है। ध्यान दें सलाह और सिफारिश अनिवार्य आवश्यकता के समान नहीं हैं।

मुझे आश्चर्य होगा अगर वे सुरक्षा/गोपनीयता के लिए सर्वोत्तम अभ्यास के रूप में सिफर सूट में आरएसए कुंजी एक्सचेंज का उपयोग करने का भी सुझाव देते हैं। यदि आप सुरक्षा और गोपनीयता को सही ढंग से संभालना चाहते हैं, तो केवल पीएफएस सिफर सूट अपनाएं, आपका आरएसए प्रमाणपत्र उस बिंदु से अप्रासंगिक होगा क्योंकि यह केवल प्रमाणीकरण में एक भूमिका निभाता है।

वैसे भी, मुझे लगता है कि मैं यहां अपने आप को दोहरा रहा हूं और मुझे अंतहीन आगे-पीछे करने में कोई दिलचस्पी नहीं है। यदि आपको कुछ सुरक्षा प्राधिकारियों/सलाहकारों का अनुपालन करना है, तो इसके बारे में स्पष्ट रूप से बताकर ऐसा करें। मैंने पहले से ही अच्छी तरह से विस्तार से बताया है कि 2048-बिट सुरक्षित है और निकट भविष्य के लिए ऐसा ही रहेगा, अगर ऐसा नहीं होता, तो 3072-बिट आरएसए अब सुरक्षित होने की संभावना नहीं है।

जैसा कि आप इस विषय के बारे में भावुक हैं, कृपया कोशिश करें और समझें कि मैंने आपको क्या बताया है, NIST / ANSSI / BSI / आदि का पाठ करने के बजाय, यह उनके सर्वोत्तम हित में है कि वे AES- के समान, आवश्यकता से थोड़ा अधिक सलाह दें।

आप 3072-बिट से प्राप्त कर रहे हैं, यह "अधिक सुरक्षित" की झूठी भावना है, क्योंकि 2048-बिट पर्याप्त से अधिक होने के कारण, यदि यह नहीं था, तो यह सोचने का कोई कारण नहीं है कि 3072-बिट अब सुरक्षित होने जा रहा है क्योंकि यह है अतिरिक्त 16-बिट सुरक्षा ऐसे अग्रिमों के साथ नहीं रहने वाली है। समझदारी से काम लें और एक प्रमुख एक्सचेंज के रूप में आरएसए का उपयोग न करें... यदि आप कहीं और सुरक्षा प्रथाओं को लागू करने के बजाय सुरक्षित होने की भावना के रूप में केवल एक बड़ी आरएसए कुंजी लंबाई पर भरोसा करते हैं, तो आप खुद को बेवकूफ बना रहे हैं।

यदि आप वास्तविक सुरक्षा लाभ के बजाय अनुपालन के लिए बहस करना जारी रखना चाहते हैं, तो मैं आपको इसके लिए छोड़ दूँगा। व्यक्तिगत रूप से यह डिफ़ॉल्ट के लिए एक सार्थक परिवर्तन नहीं है, और अधिकांश Certbot उपयोगकर्ताओं के लिए कमियों और वास्तविक सुरक्षा में कोई व्यावहारिक लाभ नहीं होने के कारण अवांछित होने की संभावना है।

यह पहली बार नहीं है जब LE सरकारी एजेंसी या अन्य से अत्याधुनिक सलाह के विरोध में डिफ़ॉल्ट कॉन्फ़िगरेशन का उपयोग करता है…

शायद इसलिए कि आप जो सोच सकते हैं, उसके बावजूद वे बेहतर जानते हैं। यहां तक ​​कि आपके सामने पहले प्रस्तुत की गई सभी सूचनाओं के बावजूद, आप इसमें रुचि नहीं रखते हैं या इसके लिए बिल्कुल भी खुले नहीं हैं।

हालांकि यह शायद आपको आगे नहीं समझाएगा, 2^128-बिट सममित शक्ति को सफलतापूर्वक हमला करने की आवश्यकता है :

वर्तमान कुल विश्व ऊर्जा खपत प्रति वर्ष लगभग 500 ईजे (5×10^20 जे) है (या तो यह आलेख कहता है)।

यह वर्ष 2040 में कुल 2^138 की ओर ले जाएगा - और यह एक दस साल की लंबी गणना के लिए है जो पूरे ग्रह के सभी संसाधनों को जुटाता है।

एक और मनोरंजक अंतर्दृष्टि :

संक्षेप में: भले ही आप दुनिया में सभी डॉलर का उपयोग करते हैं (डॉलर जो मौजूद नहीं हैं, जैसे कि संचित ऋण) और इस प्रक्रिया में पूरे ग्रह को भूनते हैं, आप मुश्किल से एक संपूर्ण कुंजी खोज का 1/1000 वां हिस्सा कर सकते हैं

256-बिट सममित एन्क्रिप्शन कुंजी btw हमारे सौर मंडल के भीतर उपलब्ध सभी ऊर्जा को क्रैक करने के लिए पार कर जाएगी :

भौतिक ब्रह्मांड के नियमों का मतलब है कि इन मामूली आकारों की चाबियां भी कभी भी जबरदस्ती नहीं की जाएंगी। इसका मतलब यह नहीं है कि उन्हें कभी नहीं तोड़ा जा सकता है। एल्गोरिदम में खामियां खोजी जा सकती हैं

"इसे तोड़ नहीं सकता" से मजबूत कुछ भी नहीं है, इसलिए 100 बिट्स से अधिक की ताकत की तुलना करना या तो वैसे भी अर्थहीन है। - स्रोत

अब वे सभी उद्धरण 3072-बिट आरएसए जैसे 128-बिट कुंजियों पर केंद्रित हैं, लेकिन 2048-बिट आरएसए के 110-112 बिट्स अभी भी काफी महत्वपूर्ण हैं। हालाँकि यह बहुत सस्ता है सिर्फ XKCD सलाह वाला मार्ग लेना :)

ऐसा लगता है कि तर्क सुरक्षा से अनुपालन में स्थानांतरित हो गए हैं।

ऐसा लगता है कि तर्क सुरक्षा से अनुपालन में स्थानांतरित हो गए हैं।

या नहीं। सुरक्षा पारिस्थितिकी तंत्र से संबंधित जाने-माने संस्थाओं से यह केवल अत्याधुनिक सलाह है कि आपके पैरों में शूटिंग से बचने के लिए डिफ़ॉल्ट रूप से क्या उपयोग किया जाए जैसा कि हम कम से कम एक दशक से टीएलएस/एक्स.509 दुनिया में नियमित रूप से देखते हैं।