PAKE के बारे में बात करें

अब बात करते हैं सूचना सुरक्षा की। यह प्रकाशन पाठ्यक्रम "क्रिप्टोग्राफिक सूचना सुरक्षा" के लॉन्च के लिए समर्पित है, जो 30 मई से शुरू होता है। चलो चलते हैं।

PAKE का पहला नियम: PAKE के बारे में कभी बात न करें। PAKE का दूसरा नियम कहता है कि पहला नियम बकवास है, क्योंकि PAKE या पासवर्ड ऑथेंटिकेटेड की (rus। पासवर्ड प्रमाणीकरण के साथ की एक्सचेंज) सबसे उपयोगी तकनीकों में से एक है जो व्यावहारिक रूप से कभी भी कहीं भी उपयोग नहीं की जाती है। इसे जहां भी संभव हो लागू किया जाना चाहिए, लेकिन इतना सरल नहीं है।




यह समझने के लिए कि हम बकवास के बारे में क्यों बात कर रहे हैं, आइए एक वास्तविक समस्या देखें।

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

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

यदि आपके सर्वर से कभी समझौता किया जाता है या यदि आपके डेवलपर्स कुछ बेवकूफ गलती करते हैं, तो यह अप्रिय परिणाम हो सकता है। उदाहरण के लिए, पिछले साल की शुरुआत में, ट्विटर ने अपने सभी उपयोगकर्ताओं (और यह 330 मिलियन!) को पासवर्ड बदलने के लिए कहा - क्योंकि यह पता चला कि कंपनी ने टेक्स्टुअल (गैर-हैशेड) पासवर्ड संग्रहीत किए थे।

फिलहाल, लॉगिंग की समस्या किसी भी तरह से पासवर्ड हैशिंग के लाभों के विपरीत नहीं है। हालांकि, आपको एक बेहतर समाधान खोजने की आवश्यकता है: एक जिसमें पासवर्ड स्पष्ट पाठ में सर्वर को कभी नहीं भेजा जाएगा। क्रिप्टोग्राफ़िक टूल जो हमें इसे प्राप्त करने में मदद करेगा, PAKE है, और विशेष रूप से, OPAQUE नामक एक नया प्रोटोकॉल, जिसे हम इस लेख के अंत में कवर करेंगे।

PAKE क्या है?

PAKE प्रोटोकॉल, जो पहले Bellovin और Merritt द्वारा प्रस्तावित किया गया था, एक विशिष्ट प्रकार का कुंजी विनिमय प्रोटोकॉल है । कुंजी विनिमय प्रोटोकॉल (या "मुख्य समझौते") दोनों पक्षों (ग्राहक और सर्वर को कॉल करने के लिए) को सार्वजनिक कुंजी क्रिप्टोग्राफी का उपयोग करके एक साझा कुंजी पर सहमत होने के लिए डिज़ाइन किए गए हैं। प्रारंभिक कुंजी विनिमय प्रोटोकॉल (उदाहरण के लिए, क्लासिक डिफी-हेलमैन ) अनधिकृत थे, जिससे उन्हें मानव-मध्य जैसे हमलों के लिए असुरक्षित बना दिया गया था। PAKE प्रोटोकॉल की एक विशिष्ट विशेषता यह है कि क्लाइंट एक पासवर्ड के साथ सर्वर को प्रमाणित करता है। स्पष्ट कारणों के लिए, यह माना जाता है कि पासवर्ड या उसका हैश पहले से ही सर्वर के लिए जाना जाता है, जो सत्यापन की अनुमति देता है।

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

PAKE प्रोटोकॉल का एक आदर्शीकृत प्रतिनिधित्व। दोनों ओर से इनपुट में कुछ यादृच्छिकता शामिल है, जो यहां नहीं दिखाया गया है। Eavesdropper को साझा गुप्त कुंजी K का पता लगाने की आवश्यकता नहीं है, जो स्वयं यादृच्छिक है और पासवर्ड का कार्य नहीं है।

बेशक, PAKE के साथ स्पष्ट समस्या यह है कि कई डेवलपर्स पहली जगह में "कुंजी विनिमय" प्रोटोकॉल नहीं चलाना चाहते हैं! वे केवल यह सुनिश्चित करना चाहते हैं कि उपयोगकर्ता पासवर्ड जानता है।

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

SRP: PAKE, जिसके बारे में समय ही भूल गया है

PAKE अवधारणा हमें सर्वर में प्रवेश करने के लिए आज उपयोग किए जाने वाले भोले दृष्टिकोण पर एक स्पष्ट सुरक्षा लाभ प्रदान करती है। और विधियाँ स्वयं पुरानी हैं, इस अर्थ में कि PAKE 1992 से जाना जाता है! इसके बावजूद प्रकाश ने उसे कभी नहीं देखा। ऐसा क्यों हो रहा है?

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

• लोकप्रिय भाषाओं में उच्च गुणवत्ता वाले PAKE कार्यान्वयन की कमी, जो इसे उपयोग करने के लिए परेशान करती है;
• क्रिप्टोग्राफी विशेषज्ञ अपने काम के सार और मूल्य को खराब तरीके से व्यक्त नहीं करते हैं, इसलिए अधिकांश लोग यह भी नहीं जानते हैं कि PAKE बिल्कुल भी मौजूद है।

इस तथ्य के बावजूद कि मैंने कहा कि PAKE का उपयोग अब नहीं किया जाता है, अभी भी नियमों के अपवाद हैं।

टॉम वू (टिम वू के साथ भ्रमित नहीं होना) द्वारा 1998 में विकसित एक महान प्रोटोकॉल है, जिसे "एसआरपी" ("सिक्योर रिमोट पासवर्ड" के लिए छोटा) कहा जाता है। वास्तव में, यह केवल कुछ अतिरिक्त कार्यों के साथ एक तीन-चरण PAKE है जो पहले कार्यों में लागू नहीं किए गए थे। जहाँ तक मुझे पता है, एसआरपी इस मायने में अलग है कि यह दुनिया में सबसे आम PAKE प्रोटोकॉल है। मैं इस कथन के दो प्रमाण दूंगा:

1. एसआरपी को टीएलएस सिफर्सुइट के रूप में मानकीकृत किया गया था और पुस्तकालयों में लागू किया गया था, उदाहरण के लिए, ओपनएसएसएल , हालांकि कोई भी इसका विशेष रूप से उपयोग नहीं करता है।
2. Apple अपने iCloud की वॉल्ट में SRP का व्यापक उपयोग करता है

अपने आप में दूसरा तथ्य एसआरपी को दुनिया में सबसे व्यापक रूप से इस्तेमाल किए जाने वाले क्रिप्टोग्राफिक प्रोटोकॉल में से एक बना सकता है, ऐप्पल स्टैम्प्स की संख्या बहुत अधिक है। और मजाकिया कुछ भी नहीं है।

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

इन अनावश्यक विवरणों के बजाय, मुझे SRP पर अपने विचारों का एक संक्षिप्त सारांश लिखने दें:

1. एसआरपी कुछ चीजों को सही करता है। सबसे पहले, PAKE के पुराने संस्करणों के विपरीत, आपको सर्वर पर एक कच्चा पासवर्ड (या, समकक्ष, एक हैश जो एक पासवर्ड के बजाय एक हमलावर द्वारा इस्तेमाल किया जा सकता है) को स्टोर करने की आवश्यकता नहीं है। इसके बजाय, सर्वर एक "सत्यापनकर्ता" संग्रहीत करता है, जो पासवर्ड हैश का एक तरफ़ा कार्य है। इसका मतलब है कि एक पासवर्ड डेटाबेस लीक एक हमलावर को केवल एक उपयोगकर्ता को बदलने की अनुमति नहीं देता है, जब वह आगे महंगा शब्दकोश हमलों को अंजाम नहीं देता है। (इसके लिए तकनीकी नाम "असममित" PAKE है।)
2. बेहतर खबर है, SRP (v4 v6a) का वर्तमान संस्करण अभी तक हैक नहीं हुआ है!
3. हालाँकि (डेवलपर्स द्वारा नाराज न हों) SRP प्रोटोकॉल की वास्तुकला पूरी तरह से पागल है, और इसके पुराने संस्करणों को कई बार हैक किया गया था - यही कारण है कि अब हमारे पास संस्करण 6a है। साथ ही, मूल शोध लेख में "सुरक्षा का प्रमाण" वास्तव में कुछ भी साबित नहीं करता है ।
4. SRP वर्तमान में पूर्णांक (अंतिम) अंकगणित पर आधारित है, और विभिन्न कारणों से (ऊपर 3 खंड देखें) इसकी वास्तुकला स्पष्ट रूप से एक अण्डाकार वक्र में स्थानांतरित नहीं की जा सकती है । इसके लिए अधिक बैंडविड्थ और अभिकलन की आवश्यकता होती है, इसलिए SRP कर्वे25519 जैसे ऐड-ऑन में विकसित किए गए कई प्रदर्शन सुधारों का लाभ नहीं उठा सकता है।
5. एसआरपी पूर्व-कंप्यूटिंग हमलों के लिए असुरक्षित है क्योंकि यह उपयोगकर्ता को किसी भी हमलावर को नमक देता है जो एसआरपी सत्र शुरू कर सकता है। इसका मतलब यह है कि मैं आपके नमक के लिए सर्वर से पूछ सकता हूं और सर्वर के समझौता होने से पहले संभावित पासवर्ड हैश का शब्दकोश तैयार कर सकता हूं।
6. इन सभी कमियों के बावजूद, SRP बेहद सरल है, और काम करने वाले कोड के साथ भी आता है। इसके अलावा, ओपनएसएसएल के पास काम करने वाला कोड है जो यहां तक ​​कि टीएलएस के साथ एकीकृत होता है, जिससे इसे लागू करना अपेक्षाकृत आसान हो जाता है।

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

OPAQUE: नई पीढ़ी को ले जाएं

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

फिर, पिछले साल की शुरुआत में, जरेकी, क्रैव्ज़क और जू ने दुनिया को एक नया प्रोटोकॉल का खुलासा किया जिसे ओमेगा कहा जाता है। इसके कई महत्वपूर्ण लाभ हैं:

1. इसे लागू किया जा सकता है भले ही डिफी-हेलमैन और असतत लघुगणक की समस्याएं हों। इसका मतलब है कि, एसआरपी के विपरीत, यह प्रभावी दीर्घवृत्त घटता का उपयोग करके आसानी से किया जा सकता है।
2. इससे भी बेहतर: OPAQUE एक हमलावर को नमक प्रकट नहीं करता है। वह पासवर्ड के साथ नमक को जोड़ने के लिए "भुलक्कड़ PRF" का उपयोग करके इस समस्या को हल करता है ताकि क्लाइंट को नमक न मिले और सर्वर को पासवर्ड प्राप्त न हो।
3. OPAQUE किसी भी पासवर्ड हैशिंग फ़ंक्शन के साथ काम करता है। चूँकि सभी हैशिंग कार्य क्लाइंट पर किए जाते हैं, OPAQUE वास्तव में सर्वर से लोड को ले सकता है, ऑनलाइन सेवा को मुक्त कर सकता है, उदाहरण के लिए, अत्यंत ज्वालामुखी सुरक्षा सेटिंग्स का उपयोग करने के लिए, उदाहरण के लिए, बहुत सारी रैम के साथ scrypt कॉन्फ़िगर करें।
4. संदेश गणना और प्रतिपादक के संदर्भ में, OPAQUE SRP से बहुत अलग नहीं है। लेकिन चूंकि इसे अधिक कुशल मापदंडों के साथ लागू किया जा सकता है, इसलिए यह बहुत अधिक कुशलता से काम करने की संभावना है।
5. SRP के विपरीत, OPAQUE के पास उचित सुरक्षा सबूत (एक बहुत मजबूत मॉडल में) हैं।

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

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

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

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

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

यह कुछ इस तरह काम करता है:

सर्वर "नमक" को संग्रहीत करता है, और क्लाइंट के पास पासवर्ड। Salt2 = PRF (नमक, पासवर्ड) है, यह क्लाइंट और सर्वर के बीच एक प्रोटोकॉल का उपयोग करके गणना की जाती है जिसमें क्लाइंट कभी भी नमक को पहचान नहीं पाएगा और सर्वर को पासवर्ड पता चल जाएगा। क्लाइंट को salt2K = PasswordHash (नमक 2, पासवर्ड) प्राप्त होता है - और यह सब क्लाइंट पर माना जाता है।

भुलक्कड़ PRF का वास्तविक कार्यान्वयन कई समूह तत्वों और घातांक का उपयोग करके किया जा सकता है। इससे भी बेहतर, अगर क्लाइंट गलत पासवर्ड दर्ज करता है, तो प्रोटोकॉल को एक डमी मूल्य "नमक 2" प्राप्त होता है, जो नमक के वास्तविक मूल्य के बारे में कुछ नहीं कहता है।

समस्या 2: सबूत है कि ग्राहक को सही कुंजी के प्राप्त हुआ। निश्चित रूप से, ग्राहक को कुंजी के प्राप्त हुई, लेकिन सर्वर को पता नहीं है कि यह क्या है। सर्वर यह भी नहीं जानता कि क्या यह सही कुंजी है।

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

C = एन्क्रिप्ट (K, क्लाइंट सीक्रेट कुंजी | सर्वर की सार्वजनिक कुंजी)


OPAQUE प्रोटोकॉल का पूर्ण संस्करण, लेख का अंश।

जब क्लाइंट OPAQUE प्रोटोकॉल का उपयोग करके प्रमाणित करना चाहता है, तो सर्वर उसे संग्रहीत C कोड भेजता है। यदि ग्राहक पहले चरण में सही पासवर्ड दर्ज करता है, तो वह K प्राप्त कर सकता है, और इस सिफर को डिक्रिप्ट कर सकता है। अन्यथा, यह बेकार है। वायर्ड गुप्त कुंजी का उपयोग करते हुए, वह अब हैंडशेक को पूरा करने के लिए एक प्रामाणिक कुंजी के साथ एक मानक समझौता प्रोटोकॉल चला सकता है। (सर्वर क्लाइंट की सार्वजनिक कुंजी की प्रतिलिपि के खिलाफ जाँच करके ग्राहकों के इनपुट की जाँच करता है, और क्लाइंट वही करता है।)

अब इसे सब एक साथ रख दें। इन सभी चरणों को एक प्रोटोकॉल में जोड़ा जा सकता है, जिसमें SRP के समान चरणों की संख्या होती है। यदि आप सत्यापन चरणों पर ध्यान नहीं देते हैं, तो यह ऊपर प्रोटोकॉल की तरह दिखेगा। सिद्धांत रूप में, विचार केवल दो संदेशों में है: एक क्लाइंट से, और दूसरा सर्वर पर वापस भेजा जाता है।

OPAQUE के कार्य का अंतिम पहलू यह है कि इसके पास अच्छे सुरक्षा प्रमाण हैं जो हमें बताते हैं कि परिणामी प्रोटोकॉल को सुरक्षित माना जा सकता है यदि हम यादृच्छिक यादृच्छिक मॉडल में एक या एक से अधिक असतत लघुगणक लेते हैं, जो एक मानक धारणा है, जो स्पष्ट रूप से है , सेटिंग्स में जगह लेता है जिसके साथ हम काम करते हैं।

निष्कर्ष

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

स्थापित परंपरा के अनुसार, हम आपकी टिप्पणियों की प्रतीक्षा कर रहे हैं और आपको खुले दरवाजे के दिन का दौरा करने के लिए आमंत्रित करते हैं , जो 27 मई को हमारे शिक्षक, क्रिप्टैनालिस्ट ऐलेना किर्शनोवा द्वारा आयोजित किया जाएगा।