स्टेन ड्रापकिन। .NET में उच्च स्तरीय क्रिप्टोग्राफी जाल

स्टेन ड्रापकिन .NET फ्रेमवर्क (2001 में .NET 1.0-बीटा के साथ शुरू) के साथ 16 वर्षों के अनुभव के साथ एक सुरक्षा और अनुपालन विशेषज्ञ है। दुर्भाग्य से, वह खुद रूसी में लेख नहीं लिखता है, इसलिए हम DotNext Piter के साथ अपनी रिपोर्ट का अनुवाद जारी करने के लिए उसके साथ सहमत हुए । इस रिपोर्ट ने सम्मेलन में पहला स्थान जीता !

सममित क्रिप्टोग्राफी, असममित, हाइब्रिड, उच्च-स्तरीय, निम्न-स्तर, धारा और आधुनिक अण्डाकार क्रिप्टोग्राफी। क्रिप्टोग्राफी के बारे में छब्बीस मिनट का वीडियो, और बहुत तेज़ी से - पाठ के रूप में।



कट के तहत - वीडियो, स्लाइड और अनुवाद। पढ़ने में मजा आता है!


स्लाइड शो

मेरा नाम स्टेन ड्रापकिन है, मैं सूचना सुरक्षा और नियामक अनुपालन में विशेषज्ञता वाली कंपनी का तकनीकी निदेशक हूं। इसके अलावा, मैं कई ओपन सोर्स लाइब्रेरीज़ का लेखक हूं, जो समुदाय द्वारा बहुत अच्छी तरह से प्राप्त की जाती हैं। कितने इन्फर्नो के बारे में सुना? यह लाइब्रेरी .NET में क्रिप्टोग्राफी के लिए सही दृष्टिकोण प्रदर्शित करती है, और .NET के लिए टाइनीमॉम माइक्रो- ओआरएम लागू करता है। इसके अलावा, मैंने कई किताबें लिखी हैं जो आज के लेख के विषय के लिए प्रासंगिक हो सकती हैं। उनमें से एक, 2014 संस्करण, "सुरक्षा प्रेरित .NET है।" 2017 का दूसरा भाग है ".NET में सुरक्षा अनुप्रयोग, सफलतापूर्वक।"

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

तो क्रिप्टो-ज्ञानोदय के ये चरण क्या दिखते हैं? पहला चरण - "XOR इतना शांत है, देखो, माँ, मैं कैसे हो सकता हूं!" निश्चित रूप से आप में से कई इस चरण से परिचित हैं और एक्सओआर फ़ंक्शन के चमत्कारों से अवगत हैं। लेकिन, मुझे उम्मीद है, इस चरण का अधिकांश हिस्सा बढ़ गया है और अगले में स्थानांतरित हो गया है, जो कि एईएस (उन्नत एन्क्रिप्शन स्टैंडर्ड) का उपयोग करके एन्क्रिप्शन और डिक्रिप्शन प्रदर्शन करने के लिए सीखा है, जो एक प्रसिद्ध और उच्च माना एल्गोरिथ्म है। ज्यादातर डेवलपर्स जो DotNext पर नहीं आते हैं, वे इस स्तर पर हैं। लेकिन, चूंकि आप DotNext का अनुसरण करते हैं और निम्न-स्तरीय API के खतरों के बारे में रिपोर्ट से परिचित हैं, तो आप अगले चरण में सबसे अधिक संभावना रखते हैं - "मैंने सब कुछ किया है (ए) गलत तरीके से, मुझे उच्च-स्तरीय एपीआई पर स्विच करने की आवश्यकता है"। खैर, तस्वीर को पूरा करने के लिए, मैं अंतिम चरण का भी उल्लेख करूंगा - यह समझ कि समस्या के सबसे अच्छे समाधान के साथ, क्रिप्टोग्राफी की बिल्कुल भी आवश्यकता नहीं हो सकती है। इस चरण तक पहुंचना सबसे कठिन है, और इस पर बहुत कम लोग हैं। एक उदाहरण पीटर जी। न्यूमैन है, जिन्होंने निम्नलिखित कहा: "यदि आपको लगता है कि आपकी समस्या का समाधान क्रिप्टोग्राफी में है, तो आप यह नहीं समझते हैं कि वास्तव में आपकी समस्या क्या है।"

तथ्य यह है कि निम्न स्तर की क्रिप्टोग्राफी खतरनाक है। .NET के बारे में कई रिपोर्टों में चर्चा की गई है। आप 2015 में व्लादिमीर कोचेतकोव की रिपोर्ट का उल्लेख कर सकते हैं, "सिस्टम की खराबी । सुरक्षा। क्रिप्टोग्राफी" । उनका मुख्य विचार यह है कि निम्न-स्तर के क्रिप्टोग्राफ़िक एपीआई के साथ काम करने के प्रत्येक चरण में, इसे जाने बिना, हम कई निर्णय लेते हैं, जिनमें से कई के लिए हमें उचित ज्ञान नहीं है। मुख्य निष्कर्ष यह है कि, आदर्श रूप से, निम्न-स्तरीय क्रिप्टोग्राफी के बजाय उच्च-स्तरीय क्रिप्टोग्राफी का उपयोग किया जाना चाहिए। यह एक अद्भुत निष्कर्ष है, लेकिन यह हमें एक और समस्या की ओर ले जाता है - क्या हम जानते हैं कि उच्च-स्तरीय क्रिप्टोग्राफी को कैसे देखना चाहिए? इसके बारे में थोड़ी बात करते हैं।

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

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

.NET के लिए एक उच्च-स्तरीय क्रिप्टोग्राफिक एपीआई के लिए आवश्यकताओं से निपटा होने के बाद, अब हम इसे कैसे पा सकते हैं? आप बस Google की कोशिश कर सकते हैं, लेकिन यह बहुत ही आदिम होगा - हम पेशेवर डेवलपर हैं, और यह हमारी विधि नहीं है। इसलिए, हम इस समस्या की जांच कर रहे हैं और विभिन्न विकल्पों का परीक्षण कर रहे हैं। लेकिन इसके लिए हमें सबसे पहले अपने लिए सही आइडिया बनाने की जरूरत है कि ऑथेंटिकेटेड एनक्रिप्शन क्या है और इसके लिए हमें बेसिक कॉन्सेप्ट्स को समझने की जरूरत है। वे इस प्रकार हैं: प्लेटेक्स्ट पी (प्लेनटेक्स्ट), जिसे हम कुछ गुप्त कुंजी के (कुंजी) का उपयोग करके समान लंबाई के सिफरटेक् सी (सिफरटेक्स्ट) में परिवर्तित करते हैं। जैसा कि आप देख सकते हैं, अब तक हम एक बहुत ही सरल योजना के साथ काम कर रहे हैं। इसके अलावा, हमारे पास एक प्रमाणीकरण टैग टी और नॉन एन है। एक महत्वपूर्ण पैरामीटर एन है, यानी, एक कुंजी के साथ नॉन का पुन: उपयोग करना। जैसा कि आप में से बहुत से लोग जानते हैं, यह पाठ की गोपनीयता के उल्लंघन की ओर जाता है, जो स्पष्ट रूप से अवांछनीय है। एक अन्य महत्वपूर्ण अवधारणा AD (एसोसिएटेड डेटा) है, अर्थात, संबद्ध डेटा। यह वैकल्पिक डेटा है जो प्रमाणित है लेकिन एन्क्रिप्शन और डिक्रिप्शन में भाग नहीं लेता है।



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

nonce = SecretAeadAes.GenerateNonce(); c = SecretAeadAes.Encrypt(p, nonce, key, ad); d = SecretAeadAes.Decrypt(c, nonce, key, ad); 

यहाँ C # कोड है जिसके साथ Libsodium.NET के साथ एन्क्रिप्शन किया जाता है। पहली नज़र में, यह काफी सरल और संक्षिप्त है: पहली पंक्ति में, नॉन उत्पन्न होता है, जिसे तब दूसरी पंक्ति में उपयोग किया जाता है, जहां एन्क्रिप्शन स्वयं होता है, और तीसरे में, जहां पाठ को डिक्रिप्ट किया जाता है। ऐसा लग रहा था - क्या कठिनाइयाँ हो सकती हैं? शुरुआत करने के लिए, Libsodium.NET एक नहीं, बल्कि तीन अलग-अलग सममित एन्क्रिप्शन विधियों की पेशकश करता है:

समय

 nonce = SecretAeadAes.GenerateNonce(); c = SecretAeadAes.Encrypt(p, nonce, key, ad); d = SecretAeadAes.Decrypt(c, nonce, key, ad); 

दो

 nonce = SecretAead.GenerateNonce(); c = SecretAead.Encrypt(p, nonce, key, ad); d = SecretAead.Decrypt(c, nonce, key. ad); 

तीन

 nonce = SecretBox.GenerateNonce(); c = SecretBox.Create(p, nonce, key); d = SecretBox.Open(c, nonce, key); 

जाहिर है, सवाल उठता है - आपकी विशिष्ट स्थिति में उनमें से कौन बेहतर है? इसका उत्तर देने के लिए, आपको इन विधियों के अंदर जाने की आवश्यकता है, जो हम अभी करेंगे।

पहला तरीका, SecretAeadAes , एईएस-जीसीएम का 96-बिट गैर-उपयोग करता है। यह महत्वपूर्ण है कि उसके पास प्रतिबंधों की एक लंबी सूची है। उदाहरण के लिए, इसका उपयोग करते समय, आपको 550 गीगाबाइट से अधिक एक कुंजी के साथ एन्क्रिप्ट नहीं करना चाहिए, और अधिकतम 2 ³² संदेशों के साथ एक संदेश में 64 से अधिक गीगाबाइट नहीं होना चाहिए। इसके अलावा, पुस्तकालय इन प्रतिबंधों के करीब आने की चेतावनी नहीं देता है, आपको उन्हें स्वयं ट्रैक करने की आवश्यकता है, जो एक डेवलपर के रूप में आप पर अतिरिक्त बोझ पैदा करता है।

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

अंत में, तीसरी विधि, SecretBox । यह तुरंत ध्यान दिया जाना चाहिए कि इस एपीआई के तर्कों में कोई संबद्ध डेटा नहीं है। यदि आपको AD के साथ प्रमाणित एन्क्रिप्शन की आवश्यकता है, तो यह विधि आपके लिए उपयुक्त नहीं है। यहां उपयोग किए जाने वाले एन्क्रिप्शन एल्गोरिदम को xSalsa20/Poly1305 कहा जाता है, xSalsa20/Poly1305 काफी बड़ा है - 192 बिट्स। हालाँकि, AD की कमी एक महत्वपूर्ण सीमा है।

Libsodium.NET का उपयोग करते समय , कुछ प्रश्न उठते हैं। उदाहरण के लिए, उपरोक्त उदाहरणों में कोड की पहली पंक्ति द्वारा उत्पन्न गैर के साथ हमें वास्तव में क्या करना चाहिए? लाइब्रेरी हमें इस बारे में कुछ नहीं बताती है, हमें इसका पता लगाना होगा। सबसे अधिक संभावना है, हम मैन्युअल रूप से इस गैर को सिफरटेक्स की शुरुआत या अंत में जोड़ देंगे। इसके अलावा, हमें यह आभास हो सकता है कि पहले दो तरीकों में AD किसी भी लम्बाई का हो सकता है। लेकिन वास्तव में, पुस्तकालय 16 बाइट्स लंबे समय तक एडी का समर्थन करता है - आखिरकार, 16 बाइट्स सभी के लिए पर्याप्त होंगे, है ना? चलो आगे बढ़ते हैं। डिक्रिप्शन त्रुटियों के साथ क्या होता है? इस लाइब्रेरी में, अपवादों को फेंकने के लिए इन मामलों में निर्णय लिया गया था। यदि डिक्रिप्शन के दौरान आपके वातावरण में डेटा अखंडता का उल्लंघन हो सकता है, तो आपके पास कई अपवाद होंगे जिन्हें संभालने की आवश्यकता होगी। यदि आपका मुख्य आकार 32 बाइट्स नहीं है तो क्या होगा? लाइब्रेरी हमें इस बारे में कुछ नहीं बताती है, ये आपकी समस्याएं हैं जो इसमें रुचि नहीं रखती हैं। गहन परिदृश्यों में कचरा संग्रहकर्ता पर भार कम करने के लिए बाइट सरणियों का पुन: उपयोग एक अन्य महत्वपूर्ण विषय है। उदाहरण के लिए, कोड में हमने एक एरे को देखा कि नॉन जनरेटर हमारे पास लौटा। मैं हर बार एक नया बफ़र नहीं बनाना चाहूंगा, लेकिन मौजूदा का पुनः उपयोग करूंगा। इस लाइब्रेरी में यह संभव नहीं है, हर बार बाइट्स की एक पुनर्जीवित की जाएगी।

हमने पहले से ही देखी गई योजना का उपयोग करते हुए, हम विभिन्न Libsodium.NET एल्गोरिदम की तुलना करने की कोशिश करेंगे।



पहला एल्गोरिथ्म, एईएस-जीसीएम, गैर-96 बिट लंबे (चित्र में पीला स्तंभ) का उपयोग करता है। यह 128 बिट्स से कम है, जो कुछ असुविधा पैदा करता है, लेकिन बहुत महत्वपूर्ण नहीं है। अगला स्तंभ नीला है, यह प्रमाणीकरण टैग के कब्जे वाली जगह है, एईएस-जीसीएम के साथ यह 16 बाइट्स या 128 बिट्स है। दूसरे नीले अंक, कोष्ठक में, एन्ट्रापी या यादृच्छिकता की मात्रा का अर्थ है, इस टैग में निहित - 128 बिट से कम। कितना कम - इस एल्गोरिथ्म में निर्भर करता है कि कितना डेटा एन्क्रिप्ट किया गया है। जितना अधिक एन्क्रिप्ट किया जाता है, कमजोर टैग। इस अकेले को इस एल्गोरिथम के बारे में संदेह को जन्म देना चाहिए, जो केवल तभी बढ़ेगा जब हम सफेद कॉलम को देखेंगे। इसमें कहा गया है कि गैर की पुनरावृत्ति (टकराव) एक ही कुंजी द्वारा बनाए गए सभी सिफरटेक्स्ट के मिथ्याकरण को जन्म देगी। यदि बाहर, कहते हैं, दो में एक सामान्य कुंजी द्वारा बनाए गए आपके 100 सिफरटेक्स हैं, तो एक गैर-टकराव है, इस गैर-प्रमाणीकरण से प्रमाणीकरण कुंजी का एक आंतरिक रिसाव होगा और एक हमलावर को इस कुंजी से निर्मित किसी अन्य सिफरटेक्स्ट को नकली करने की अनुमति देगा। यह एक बहुत महत्वपूर्ण सीमा है।

चलिए दूसरी Libsodium.NET विधि पर चलते हैं । जैसा कि मैंने कहा, यहाँ गैर के लिए, बहुत कम जगह का उपयोग किया जाता है, केवल 64 बिट्स। टैग 128 बिट्स पर रहता है, लेकिन इसमें केवल 106 बिट्स एन्ट्रापी या उससे कम है, दूसरे शब्दों में, 128 बिट्स के सुरक्षा स्तर से काफी कम है, जो कि ज्यादातर मामलों में वे हासिल करने की कोशिश करते हैं। जालसाजी के लिए, एईएस-जीसीएम के मामले में यहां की स्थिति थोड़ी बेहतर है। नॉन के टकराव से सिफरटेक्स का मिथ्याकरण होता है, लेकिन केवल उन ब्लॉकों के लिए जिनमें टकराव हुआ। पिछले उदाहरण में, हमने 100 नहीं, बल्कि 2 सिफरटेक्स जाली बनाए होंगे।

अंत में, xSalsa / Poly एल्गोरिथ्म के मामले में, हमारे पास 192 बिट्स का एक बहुत बड़ा नॉनस है, जो टकराव को बहुत कम संभावना बनाता है। प्रमाणीकरण विधि पिछली पद्धति की तरह ही है, इसलिए टैग फिर से 128 बिट्स लेता है और इसमें 106 बिट्स एन्ट्रापी या उससे कम होता है।

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

इससे पहले कि हम Libsodium.NET को और अधिक विस्तार से जानें , हमें इसके उद्देश्य को समझने की आवश्यकता है - दुर्भाग्य से, इस पुस्तकालय का उपयोग करने वाले सभी लोग इसके बारे में नहीं जानते हैं। ऐसा करने के लिए, इसके प्रलेखन का संदर्भ लें, जिसमें कहा गया है कि Libsodium.NET libsodium के लिए C # आवरण है। यह एक और ओपन सोर्स प्रोजेक्ट है, जिसके प्रलेखन में कहा गया है कि यह संगत API के साथ NaCl का कांटा है। खैर, एक और ओपन सोर्स प्रोजेक्ट NaCl के प्रलेखन की ओर मुड़ें। इसमें, एक लक्ष्य के रूप में, NaCl को उच्च-स्तरीय क्रिप्टोग्राफ़िक टूल बनाने के लिए सभी आवश्यक संचालन प्रदान करने के लिए पोस्ट किया गया है। यह यहां है कि कुत्ते को दफन किया गया है: NaCl और उसके सभी गोले का कार्य निम्न-स्तरीय तत्व प्रदान करना है, जिसमें से फिर कोई और पहले से ही उच्च-स्तरीय क्रिप्टोग्राफिक एपीआई को इकट्ठा कर सकता है। उच्च स्तर के पुस्तकालयों के रूप में इन गोले की कल्पना नहीं की गई थी। इसलिए नैतिक: यदि आपको एक उच्च-स्तरीय क्रिप्टोग्राफ़िक एपीआई की आवश्यकता है, तो आपको एक उच्च-स्तरीय लाइब्रेरी खोजने की आवश्यकता है, और निम्न-स्तरीय आवरण का उपयोग न करें और यह दिखावा करें कि आप उच्च-स्तरीय के साथ काम कर रहे हैं।

आइए देखें कि इनफर्नो में एन्क्रिप्शन कैसे काम करता है।



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

रुचि से, आइए कुछ स्ट्रिंग को एन्क्रिप्ट करने का प्रयास करें। यह सबसे सरल परिदृश्य होना चाहिए जिसे हर कोई लागू कर सकता है। मान लें कि हमारे पास केवल दो अलग-अलग स्ट्रिंग मान हैं: "बाएँ" और "सही"।



तस्वीर में आप इनफर्नो का उपयोग करके इन पंक्तियों के एन्क्रिप्शन को देखते हैं (हालांकि इस उदाहरण के लिए यह महत्वपूर्ण नहीं है कि कौन सी लाइब्रेरी का उपयोग किया जाता है)। हम एक कुंजी के साथ दो लाइनों को एन्क्रिप्ट करते हैं और दो सिफरटेक्स्ट, c1 और c2 । क्या इस कोड में सब कुछ सही है? क्या वह उत्पादन के लिए तैयार है? कोई कह सकता है कि समस्या थोड़े समय में संभव है, लेकिन यह मुख्य से बहुत दूर है, इसलिए हम मान लेंगे कि कुंजी का उपयोग एक ही है, और यह पर्याप्त लंबाई का है। मेरा मतलब कुछ और है: पारंपरिक क्रिप्टोग्राफिक दृष्टिकोणों के साथ, हमारे उदाहरण में c1 , c2 से छोटा होगा। इसे लंबाई रिसाव कहा जाता है - कई मामलों में c2 c1 तुलना में एक बाइट होगा। यह एक हमलावर को यह समझने की अनुमति दे सकता है कि कौन सा स्ट्रिंग इस सिफरटेक्स्ट, "LEFT" या "राइट" द्वारा दर्शाया गया है। इस समस्या को हल करने का सबसे आसान तरीका यह है कि दोनों लाइनों की लंबाई समान है - उदाहरण के लिए, "LEFT" पंक्ति के अंत में एक वर्ण जोड़ें।

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

अब फाइल को एनक्रिप्ट करने की कोशिश करते हैं। तुरंत मुझे कहना होगा कि Libsodium.NET फ़ाइल एन्क्रिप्शन में या, अधिक मोटे तौर पर, स्ट्रीम एन्क्रिप्शन डिफ़ॉल्ट रूप से लागू नहीं होता है, इसे मैन्युअल रूप से वहां करना होगा - जो, मेरा मानना ​​है, सही ढंग से करना बहुत मुश्किल है। इन्फर्नो में , इसके साथ चीजें बहुत बेहतर हैं।



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

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

हमें संबद्ध डेटा के प्रमाणीकरण के बारे में भी बात करनी चाहिए, क्योंकि यह एक ऐसा विषय है जिसे अक्सर कवर नहीं किया जाता है। AD "कमजोर" हो सकते हैं: इसका मतलब है कि वे प्रमाणित हैं, लेकिन वे एन्क्रिप्शन और डिक्रिप्शन प्रक्रिया में शामिल नहीं हैं। इसके विपरीत, "मजबूत" विज्ञापन इस प्रक्रिया को ही बदल देते हैं। अधिकांश AD पुस्तकालयों को मैं जानता हूं कि वे कमजोर हैं, जबकि Inferno दूसरे दृष्टिकोण का उपयोग करता है, जहां एन्क्रिप्शन / डिक्रिप्शन प्रक्रिया में AD का उपयोग किया जाता है ...

यह इस बात पर भी ध्यान देना चाहिए कि उच्च-स्तरीय क्रिप्टोग्राफी के लिए किस स्तर की सुरक्षा का प्रयास करना चाहिए। संक्षेप में, मेरा उत्तर है: 128-बिट प्रमाणीकरण टैग के साथ 256-बिट एन्क्रिप्शन। एक कुंजी इतनी बड़ी क्यों है? इसके कई कारण हैं, जिनमें से प्रत्येक अपने आप में महत्वपूर्ण है, लेकिन अब मैं चाहूंगा कि आप एक बात याद रखें: हमें क्रिप्टोग्राफ़िक कुंजियाँ बनाते समय अपने आप को संभावित पूर्वाग्रह से बचाने की आवश्यकता है। मुझे समझाइए कि पूर्वाग्रह से क्या मतलब है। पूर्वाग्रह के बिना एक यादृच्छिक बिट जनरेटर के लिए, प्रत्येक बिट के लिए, मान 0 या 1 को स्वीकार करने की संभावनाएं बराबर हैं। लेकिन मान लीजिए कि हमारे जनरेटर में बिट मूल्य 56% की संभावना के साथ 1 ले जाएगा, 50% नहीं। पहली नज़र में, यह पूर्वाग्रह छोटा है, लेकिन वास्तव में यह महत्वपूर्ण है: 25%। आइए अब गणना करने की कोशिश करें कि हमारे जनरेटर के साथ निश्चित संख्या में बिट्स पैदा करते समय हमें कितना एंट्रॉपी मिलता है।



चित्र में आप वह सूत्र देखते हैं जिसके द्वारा यह गणना की जाएगी। यह महत्वपूर्ण है कि इसमें केवल दो चर हैं: पूर्वाग्रह जिसके बारे में हम पहले ही बात कर चुके हैं (पूर्वाग्रह), और जनरेटर द्वारा निर्मित बिट्स की संख्या। हम मानते हैं कि पूर्वाग्रह 25% है - यह काफी चरम मामला है, व्यवहार में आप इस तरह के विकृत यादृच्छिक संख्या जनरेटर के साथ सिस्टम में काम नहीं करेंगे। वैसे भी, 25% पूर्वाग्रह और 128-बिट कुंजी के साथ, हमें केवल 53 बिट्स एन्ट्रापी मिलते हैं। सबसे पहले, यह 128 बिट से काफी कम है, जो आमतौर पर एक यादृच्छिक संख्या जनरेटर से उम्मीद की जाती है, और दूसरी बात, आधुनिक प्रौद्योगिकियों के साथ, इस तरह की कुंजी बस क्रूर बल हो सकती है। लेकिन अगर 128-बिट कुंजी के बजाय हम 256-बिट का उपयोग करते हैं, तो हमें 106 बिट्स एन्ट्रापी मिलते हैं। यह पहले से ही काफी अच्छा है, हालांकि अपेक्षित 256 से कम है। आधुनिक प्रौद्योगिकियों के साथ, इस तरह की कुंजी को क्रैक करना लगभग असंभव है।

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

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



मान लीजिए कि कुछ ऐलिस हैं, जो एक यादृच्छिक संख्या जनरेटर का उपयोग करते हैं, एक महत्वपूर्ण जोड़ी बनाते हैं जिसमें एक निजी और एक सार्वजनिक शामिल होता है। अगला, कुछ बॉब हैं जो ऐलिस के लिए एक संदेश एन्क्रिप्ट करना चाहते हैं: "हैलो ऐलिस!" अपनी सार्वजनिक कुंजी का उपयोग करते हुए, वह एक सिफरटेक्स्ट बनाता है, जिसे वह उसके पास भेजता है। वह अपनी कुंजी के निजी भाग का उपयोग करते हुए इस सिफरटेक्स्ट को डिक्रिप्ट करती है।

आइए व्यवहार में इस परिदृश्य को पुन: पेश करने का प्रयास करें।



जैसा कि आप ऊपर देख सकते हैं, हम आरएसए का एक उदाहरण बनाते हैं और कुछ पाठ को एन्क्रिप्ट करते हैं। तुरंत ध्यान दें कि .NET हमें पेडिंग मोड चुनने के लिए मजबूर करता है। उनमें से पांच हैं, सभी अस्पष्ट नामों के साथ। अगर हम उन सभी को बारी-बारी से आजमाते हैं, तो हमें पता चलेगा कि अंतिम तीन केवल एक अपवाद हैं और काम नहीं करते हैं। हम शेष दो में से एक का उपयोग करेंगे - OaepSHA1 । यहां, कुंजी आकार में 1 किलोबाइट होगी, जो आरएसए के लिए बहुत छोटा है, यह व्यावहारिक रूप से हैक की गई कुंजी है। इसलिए, हमें मुख्य आकार को मैन्युअल रूप से सेट करना होगा। प्रलेखन से हम सीखते हैं कि एक विशेष गुण है .KeySize , जो कुंजी आकार प्राप्त या सेट करता है।



पहली नज़र में, यह वही है जो हमें चाहिए, इसलिए हम लिखते हैं: rsa.KeySize = 3072 । लेकिन अगर, अस्पष्ट संदेह द्वारा निर्देशित किया जाता है, तो उसके बाद हम जांचते हैं कि कुंजी का आकार अब किसके बराबर है, तो हम यह पता लगाएंगे कि यह अभी भी 1 किलोबाइट लेता है। इससे कोई फर्क नहीं पड़ता, हम WriteLine(rsa.KeySize) पद्धति, या rsa.ExportParameters(false).Modulus.Length * 8 का उपयोग करके इस पैरामीटर की जांच करेंगे rsa.ExportParameters(false).Modulus.Length * 8 - बाद वाले मामले में, RSA कुंजी का सार्वजनिक घटक निर्यात किया जाता है, इसके लिए हमें तर्क "गलत" की आवश्यकता है। इस कुंजी का मापांक एक सरणी है, जिसे हम 8 से गुणा करते हैं और बिट्स में आकार प्राप्त करते हैं - जो फिर से 1 किलोबाइट होगा। जैसा कि आप देख सकते हैं, यह एल्गोरिदम अभी भी उत्पादन के लिए भेजने के लिए बहुत जल्दी है।

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



हम RSACng के एक उदाहरण का अनुरोध करते हैं, फिर से कुंजी का आकार 3 किलोबाइट पर सेट करें, फिर से मुख्य आकार को WriteLine(rsa.KeySize) माध्यम से WriteLine(rsa.KeySize) - और फिर पता करें कि कुंजी का आकार अभी भी एक किलोबाइट के बराबर है। इसके अलावा, अगर हम उस वस्तु के प्रकार का अनुरोध करते हैं जिसने कुंजी उत्पन्न की है - जैसा कि हम याद करते हैं, हमने RSACng के एक उदाहरण का अनुरोध किया - हमें पता चला कि यह RSACryptoServiceProvider है। मैं बस निराशा की अपनी व्यक्तिगत भावना को यहां साझा करना चाहता हूं, और चिल्लाता हूं, "क्यों, माइक्रोसॉफ्ट!"

लंबे समय तक पीड़ा और पीड़ा के बाद, हमें पता चलता है कि वास्तव में आपको डिजाइनर का उपयोग करने की आवश्यकता है, न कि कारखाने का।



यहां डिफ़ॉल्ट कुंजी आकार मान 2048 बिट्स है, जो पहले से बहुत बेहतर है। यहां तक ​​कि बेहतर क्या है - यहां हम अंततः 3 किलोबाइट का मुख्य आकार निर्धारित करने का प्रबंधन करते हैं। जैसा कि वे कहते हैं, उपलब्धि अनलॉक हो गई।

आपको याद दिला दूं कि अभी तक हमारे सभी प्रयास केवल आरएसए के निर्माण में ही कम हुए हैं, हमने अभी तक एन्क्रिप्शन शुरू नहीं किया है। अभी भी ऐसे सवाल हैं जिनका जवाब हमें पहले देना होगा। शुरुआत के लिए, आप डिफ़ॉल्ट कुंजी आकारों पर किस हद तक भरोसा कर सकते हैं? आरएसए फैक्ट्री के कार्यान्वयन को ओवरराइड किया जा सकता है machine.config, इसलिए, यह आपके ज्ञान के बिना बदल सकता है (उदाहरण के लिए, एक सिस्टम प्रशासक बदल सकता है)। और इसका मतलब है कि डिफ़ॉल्ट कुंजी का आकार भी बदल सकता है। इस प्रकार, आपको कभी भी डिफ़ॉल्ट रूप से प्रदान किए गए मूल्यों पर भरोसा नहीं करना चाहिए, कुंजी आकार हमेशा स्वतंत्र रूप से सेट होना चाहिए। अगला, डिफ़ॉल्ट RSA कुंजी आकार कितने अच्छे हैं? .NET में दो RSA कार्यान्वयन हैं, एक आधारित RSACryptoServiceProvider, दूसरा आधारितRSACng। पहले में, डिफ़ॉल्ट आकार 1 किलोबाइट है, दूसरे दो में। मज़े के लिए, आइए इन मूल्यों की बिटकॉइन (BCN) नेटवर्क पर उन लोगों के साथ तुलना करें। मैं एक व्यथा विषय को बढ़ाने के लिए पहले से माफी मांगता हूं, लेकिन हम बिटकॉइन या क्रिप्टोक्यूरेंसी पर चर्चा नहीं करेंगे, हम केवल नेटवर्क के बारे में बात करेंगे। उसके पास एक प्रकाशित हैशेट है, जो हर महीने बढ़ रहा है और आज प्रति सेकंड 2 ⁶⁴ हैश के बराबर है । यह प्रति वर्ष 2 ⁹⁰ हैश के बराबर है । सादगी के लिए, मान लीजिए कि एक हैश एक बुनियादी ऑपरेशन के बराबर है - हालांकि यह पूरी तरह से सच नहीं है, यह अधिक जटिल है। यदि आप वास्तविक पेशेवरों द्वारा लिखित क्रिप्टोग्राफी पर किताबें पढ़ते हैं, और मेरे जैसे लोग नहीं हैं, तो आप जानते हैं कि 2 ⁷⁰ ऑपरेशन (यानी बीसीएन का एक मिनट) 1-किलोबाइट आरएसए कुंजी, और 2 ⁹⁰ को क्रैक करने के लिए पर्याप्त हैं(एक वर्ष बीसीएन) - 2 किलोबाइट कुंजी को क्रैक करने के लिए। दोनों मूल्यों से हमें चिंता होनी चाहिए - यह वही है जो मौजूदा प्रौद्योगिकियों के साथ प्राप्त किया जा सकता है। यही कारण है कि मैं दृढ़ता से अनुशंसा करता हूं कि आप हमेशा कुंजी आकार स्वयं सेट करें, और इसे कम से कम 3 किलोबाइट आकार में बनाएं, और यदि प्रदर्शन आपको अनुमति देता है, तो 4.

.NET में, यह पता लगाना इतना आसान नहीं है कि सार्वजनिक और निजी कुंजी कैसे निर्यात करें।



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

आरएसए के साथ अब तक हमने जो कुछ भी किया है, वह काम की प्रतिलिपि प्राप्त करने की कोशिश में कम हुआ है; अब कुछ एन्क्रिप्ट करने की कोशिश करें।



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

शायद पूरी बात यह है कि हमने SHA-1 पूरक का उपयोग किया है? SHA-1, जैसा कि हम जानते हैं, अब क्रिप्टोग्राफिक रूप से मजबूत कार्य नहीं है, इसलिए हमारे लेखा परीक्षक और अनुपालन विभाग जोर देते हैं कि हम इससे छुटकारा पा लें। बदलें OaepSHA1पर OaepSHA256, कम से कम यह लेखा परीक्षकों को शांत करेगा।



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

आइए यह पता लगाने की कोशिश करें कि जादू का फॉर्मूला कैसा दिखता है, जो एन्क्रिप्टेड डेटा की अधिकतम मात्रा निर्धारित करता है। यह विधि में होना चाहिएint GetMaxDataSizeForEnc(RSAEncryptionPadding pad), जो इस वॉल्यूम की गणना करता है, इनपुट पर पूरक मोड प्राप्त करता है। इस पद्धति का मुख्य नुकसान यह है कि यह मौजूद नहीं है, मैंने इसका आविष्कार किया। मैं इस विचार को व्यक्त करने की कोशिश कर रहा हूं कि यहां तक ​​कि सबसे बुनियादी जानकारी जो एक डेवलपर को आरएसए का सही ढंग से उपयोग करने की आवश्यकता है, वह हमारे लिए उपलब्ध नहीं है। धन्यवाद, Microsoft।

यहाँ कारण हैं कि हस्ताक्षर के लिए भी आरएसए से बचा जाना चाहिए। जैसा कि मुझे उम्मीद है कि मैं दिखाने में कामयाब रहा, .NET में RSA के लिए API बेहद असंतोषजनक हैं। आपको पूरक मोड, डेटा आकार और इस तरह के कई निर्णय लेने के लिए मजबूर किया जाता है, जो अवांछनीय है। इसके अलावा, 128-बिट सुरक्षा स्तर के लिए, आपको कम से कम बहुत ही भारी 4-किलोबाइट कुंजी की आवश्यकता होगी। यह आपको एक किलोबाइट निजी कुंजी, आधा किलोबाइट सार्वजनिक कुंजी और आधा किलोबाइट हस्ताक्षर देगा। कई परिदृश्यों के लिए, ऐसे मूल्य वांछनीय नहीं हो सकते हैं। और यदि आप 256-बिट सुरक्षा प्राप्त करने का प्रयास करते हैं, तो आपको 1570 बिट्स की एक बड़ी कुंजी की आवश्यकता होगी। आरएसए में, ऐसी कुंजी का उपयोग करना लगभग असंभव है। मेरे लैपटॉप पर एक से डेढ़ मिनट में ऐसी चाबी बनती है।इसके अलावा, एक मौलिक स्तर पर आरएसए, एक एल्गोरिथ्म के रूप में, बहुत धीरे-धीरे एक हस्ताक्षर को लागू करता है, कार्यान्वयन की परवाह किए बिना। हस्ताक्षर गति हमारे लिए महत्वपूर्ण क्यों है? यदि आप आरएसए प्रमाणपत्रों के साथ टीएलएस का उपयोग करते हैं, तो हस्ताक्षर सर्वर पर किया जाता है। और हम, डेवलपर्स के रूप में, सर्वर पर वास्तव में जो होता है, उससे सबसे अधिक प्रभावित होते हैं, हम इसके लिए जिम्मेदार हैं, इसका थ्रूपुट हमारे लिए महत्वपूर्ण है। संक्षेप में, मैं एक बार फिर आरएसए का उपयोग नहीं करने की सिफारिश करना चाहता हूं।मैं फिर से आरएसए का उपयोग नहीं करने की सिफारिश करना चाहता हूं।मैं फिर से आरएसए का उपयोग नहीं करने की सिफारिश करना चाहता हूं।

इस मामले में, आरएसए क्या बदल सकता है? मैं आपको आधुनिक अण्डाकार क्रिप्टोग्राफिक प्राइमेटिव से परिचित कराना चाहूंगा। सबसे पहले, आपको ईसीडीएसए (डिजिटल सिग्नेचर एल्गोरिथम) को ध्यान में रखना चाहिए, जिसका उपयोग हस्ताक्षर के लिए आरएसए के बजाय किया जा सकता है। इस और निम्नलिखित संक्षिप्त रूपों में, ईसी एक सामान्य उपसर्ग है जो एलिप्टिक-कर्व ("अण्डाकार") के लिए है। Securitydriven.net/inferno/#DSA हस्ताक्षर पर, आप नमूना ECDSA कोड पा सकते हैं, जो संयोगवश, .NET का मूल निवासी है। एक अन्य महत्वपूर्ण एल्गोरिदम ECIES (एकीकृत एन्क्रिप्शन योजना, "अण्डाकार एकीकृत एन्क्रिप्शन योजना") है। यह एल्गोरिदम आरएसए के बजाय हाइब्रिड एन्क्रिप्शन का प्रदर्शन कर सकता है, अर्थात, जहां आप एक सममित कुंजी उत्पन्न करते हैं, इसके साथ डेटा एन्क्रिप्ट करें और फिर कुंजी को स्वयं एन्क्रिप्ट करें।नमूना कोड securitydriven.net/inferno/#ECIES उदाहरण पर उपलब्ध है। अंत में, एक और बहुत महत्वपूर्ण एल्गोरिथ्म ECDH (डिफी-हेलमैन कुंजी विनिमय, "डिफी-हेलमैन कुंजी विनिमय") है। यह आपको ज्ञात सार्वजनिक कुंजियों वाले दो पक्षों के बीच सममित एन्क्रिप्शन की कुंजी बनाने की अनुमति देता है। कुछ स्थितियों और उपयोग के तरीकों में, यह प्रत्यक्ष गोपनीयता की अनुमति देता है (आगे की गोपनीयता )। लिंक securitydriven.net/inferno/#DHM कुंजी एक्सचेंज उपलब्ध नमूना कोड।

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

मैं उन संसाधनों के बारे में कुछ शब्द कहूंगा जो आपके लिए उपयोगी हो सकते हैं। एक अच्छा स्वीकार्य उच्च-स्तरीय SecurityDriven.Inferno लाइब्रेरी है जिसमें अच्छे प्रलेखन हैं। जीन-फिलिप ऑमेसन, सीरियस क्रिप्टोग्राफी द्वारा एक अद्भुत पुस्तक, सीरियस क्रिप्टोग्राफी है। यह नवीनतम नवाचारों को ध्यान में रखते हुए, क्रिप्टोग्राफी की वर्तमान स्थिति का अवलोकन प्रदान करता है। इसके अलावा, मैंने .NET, Succinctly, जो सार्वजनिक डोमेन में है, में पहले से ही उल्लिखित पुस्तक एप्लीकेशन सिक्योरिटी लिखा है। यह .NET सुरक्षा जाल के बारे में और भी जानकारी है। अंत में, स्लाइडशारे में व्लादिमीर कोचेतकोव द्वारा एक उत्कृष्ट प्रस्तुति है, जो कुछ हद तक सरल लेकिन बहुत ठोस तरीके से अनुप्रयोग सुरक्षा सिद्धांत की मूल बातें बताता है और खतरों के विभिन्न स्रोतों की व्याख्या करता है।

निष्कर्ष के रूप में, आइए कुछ अतिरिक्त उदाहरण देखें जो मैंने तैयार किए हैं। बहुत शुरुआत में, मैंने क्रिप्टो-प्रबोधन के चौथे चरण के बारे में बात की, जिसमें यह पता चलता है कि सबसे अच्छे समाधान के लिए क्रिप्टोग्राफी की आवश्यकता नहीं हो सकती है। आइए इस तरह के समाधान का एक उदाहरण देखें। आइए क्लासिक .NET तंत्र - CSRF (क्रॉस-साइट रिक्वेस्ट फोर्जरी, "क्रॉस-साइट रिक्वेस्ट फर्जी") पर एक नज़र डालें, जिसे क्रॉस-साइट रिक्वेस्ट जालसाजी सहित हमलों के एक वर्ग से बचाने के लिए डिज़ाइन किया गया है। इस मॉडल में, हमारे पास एक उपयोगकर्ता एजेंट है - आमतौर पर एक ब्राउज़र। यह GET अनुरोध भेजकर सर्वर के साथ संबंध स्थापित करने का प्रयास करता है। प्रतिक्रिया में, सर्वर एक CSRF टोकन भेजता है, जो HTML "हिडन" फ़ील्ड में छिपा हुआ है। इसके अलावा, एक हेडर के रूप में एक ही टोकन कुकी के रूप में प्रतिक्रिया से जुड़ा हुआ है।उपयोगकर्ता कुछ फ़ॉर्म को संसाधित करता है और एक POST करता है, जो दोनों टोकन के साथ सर्वर पर लौटता है। सर्वर चेक करता है, सबसे पहले, क्या दोनों टोकन भेजे गए थे, और दूसरी बात, क्या वे मेल खाते हैं। यह इस पहचान की तुलना है जो सर्वर को एक हमलावर से खुद को बचाने की अनुमति देता है। यह ASP.NET और ASP.NET Core में निर्मित एक क्लासिक तंत्र है। मिखाइल शचरबकोव ने एक उत्कृष्ट रिपोर्ट बनाई जिसमें सीएसआरएफ के काम की विस्तार से जांच की गई।

इस दृष्टिकोण के साथ समस्या यह है कि CSRF टोकन पीढ़ी एन्क्रिप्शन का उपयोग करती है। कठिनाई यह है कि एन्क्रिप्शन अपने आप में एक जटिल और संसाधन-खपत ऑपरेशन है, यह प्रोसेसर को लोड करता है, मेमोरी की आवश्यकता होती है, और देरी को बढ़ाता है। यह सब अवांछनीय है। इसके अलावा, एक टोकन को इंजेक्ट करना एक बोझिल, भ्रामक और असुविधाजनक प्रक्रिया है। कई मामलों में - उदाहरण के लिए, AJAX का उपयोग करते समय, अतुल्यकालिक कॉल - इसका कार्यान्वयन डेवलपर्स के रूप में आपके साथ रहता है। जिन लोगों को यह पता था कि यह गतिविधि बेहद अप्रिय है।



एक ही या तुलनीय क्रिप्टो एन्क्रिप्शन, कैसे के उपयोग के बिना बनाया जा सकता है - स्लाइड पर दिखाया गया है। मैं समझता हूं कि यहां पाठ काफी जटिल है, इसलिए मैं चर्चा क्षेत्र में इसके बारे में अधिक विस्तार से चर्चा करने के लिए तैयार हूं। मेरे लिए बस इतना ही, बहुत-बहुत धन्यवाद।

. DotNext. DotNext 2018 Moscow — 22-23 2018 - « ».

. , , . ! .