ECIES-X25519-AEAD-Ratchet

नोट

नेटवर्क तैनाती और परीक्षण चल रहा है। मामूली संशोधनों के अधीन। आधिकारिक विनिर्देश के लिए SPEC देखें।

0.9.46 तक निम्नलिखित सुविधाएँ लागू नहीं की गई हैं:

• MessageNumbers, Options, और Termination ब्लॉक
• प्रोटोकॉल-लेयर प्रतिक्रियाएँ
• शून्य स्थिर कुंजी
• मल्टीकास्ट

अवलोकन

यह I2P की शुरुआत के बाद से पहला नया एंड-टू-एंड एन्क्रिप्शन प्रकार का प्रस्ताव है, जो ElGamal/AES+SessionTags Elg-AES को बदलने के लिए है।

यह पिछले कार्यों पर निम्नानुसार निर्भर करता है:

• सामान्य संरचनाएँ विनिर्देश Common Structures
• I2NP विनिर्देश जिसमें LS2 शामिल है
• ElGamal/AES+Session Tags Elg-AES
• http://zzz.i2p/topics/1768 नया असममित क्रिप्टो अवलोकन
• लो-लेवल क्रिप्टो अवलोकन CRYPTO-ELG
• ECIES http://zzz.i2p/topics/2418
• NTCP2 प्रस्ताव 111
• 123 नए नेटडीबी प्रविष्टियाँ
• 142 नया क्रिप्टो टेम्पलेट
• Noise प्रोटोकॉल
• Signal डबल रैचेट एल्गोरिथ्म

लक्ष्य एंड-टू-एंड, गंतव्य-से-गंतव्य संचार के लिए नई एन्क्रिप्शन का समर्थन करना है।

डिज़ाइन में सिग्नल के डबल रैचेट को शामिल करते हुए नॉइज़ हैंडशेक और डेटा चरण का उपयोग किया जाएगा।

इस प्रस्ताव में सिग्नल और नॉइज़ के सभी संदर्भ केवल पृष्ठभूमि जानकारी के लिए हैं। इस प्रस्ताव को समझने या लागू करने के लिए सिग्नल और नॉइज़ प्रोटोकॉल का ज्ञान आवश्यक नहीं है।

वर्तमान ElGamal उपयोग

समीक्षा के रूप में, 256-बाइट सार्वजनिक कुंजियों को निम्नलिखित डेटा संरचनाओं में पाया जा सकता है। सामान्य संरचनाएँ विनिर्देश का संदर्भ लें।

• एक राउटर पहचान में यह राउटर की एन्क्रिप्शन कुंजी है।

• एक गंतव्य में गंतव्य की सार्वजनिक कुंजी पुराने i2cp-से-i2cp एन्क्रिप्शन के लिए उपयोग की गई थी जो संस्करण 0.6 में अक्षम कर दिया गया था, यह वर्तमान में अप्रयुक्त है सिवाय LeaseSet एन्क्रिप्शन के लिए IV के, जो अप्रचलित है। LeaseSet में सार्वजनिक कुंजी का उपयोग किया जाता है।

• एक LeaseSet में यह गंतव्य की एन्क्रिप्शन कुंजी है।

• एक LS2 में यह गंतव्य की एन्क्रिप्शन कुंजी है।

की सर्टिफिकेट्स में एन्क्रिप्शन प्रकार

समीक्षा के रूप में, हमने स्वाक्षरी प्रकार का समर्थन जोड़ते समय एन्क्रिप्शन प्रकार का समर्थन जोड़ा। एन्क्रिप्शन प्रकार क्षेत्र हमेशा शून्य होता है, गंतव्यों और राउटर पहचान दोनों में। क्या इसे कभी बदलना है यह अभी तय नहीं है। सामान्य संरचनाएँ विनिर्देश Common Structures का संदर्भ लें।

असममित क्रिप्टो उपयोग

समीक्षा के रूप में, हम ElGamal का उपयोग निम्नलिखित के लिए करते हैं:

1. टनल बिल्ड संदेश (कुंजी राउटर पहचान में है) प्रतिस्थापन इस प्रस्ताव में शामिल नहीं है। प्रस्ताव 152 प्रस्ताव 152 देखें।

2. नेटडीबी और अन्य I2NP संदेशों के लिए राउटर-से-राउटर एन्क्रिप्शन (कुंजी राउटर पहचान में है) इस प्रस्ताव पर निर्भर करता है।

   1. के लिए एक प्रस्ताव की आवश्यकता है, या कुंजी को RI विकल्पों में रखना।

3. क्लाइंट एंड-टू-एंड ElGamal+AES/SessionTag (कुंजी LeaseSet में है, गंतव्य कुंजी अप्रयुक्त है) प्रतिस्थापन इस प्रस्ताव में शामिल है।

4. NTCP1 और SSU के लिए अस्थायी DH प्रतिस्थापन इस प्रस्ताव में शामिल नहीं है। NTCP2 के लिए प्रस्ताव 111 देखें। SSU2 के लिए कोई वर्तमान प्रस्ताव नहीं है।

लक्ष्य

• पिछड़े संगत
• LS2 (प्रस्ताव 123) पर आधारित और आवश्यक
• NTCP2 (प्रस्ताव 111) के लिए जोड़े गए नए क्रिप्टो या प्राइमिटिव्स का उपयोग करें
• समर्थन के लिए कोई नया क्रिप्टो या प्राइमिटिव्स की आवश्यकता नहीं
• क्रिप्टो और हस्ताक्षर के बीच अलगाव बनाए रखें; सभी वर्तमान और भावी संस्करणों का समर्थन करें
• गंतव्यों के लिए नया क्रिप्टो सक्षम करें
• राउटरों के लिए नया क्रिप्टो सक्षम करें, लेकिन केवल लहसुन संदेशों के लिए - टनल निर्माण एक अलग प्रस्ताव होगा
• बिटटॉरेंट जैसे 32-बाइट बाइनरी गंतव्य हैश पर निर्भर कुछ भी न तोड़ें
• अस्थायी-स्थिर DH का उपयोग करते हुए 0-RTT संदेश डिलीवरी बनाए रखें
• इस प्रोटोकॉल परत पर संदेशों को बफर या कतार में रखने की आवश्यकता नहीं है; प्रतिक्रिया की प्रतीक्षा किए बिना दोनों दिशाओं में असीमित संदेश डिलीवरी का समर्थन जारी रखें
• 1 RTT के बाद अस्थायी-अस्थायी DH पर अपग्रेड करें
• आउट-ऑफ-ऑर्डर संदेशों के निपटान को बनाए रखें
• 256-बिट सुरक्षा बनाए रखें
• अग्रगामी गोपनीयता जोड़ें
• प्रमाणीकरण (AEAD) जोड़ें
• ElGamal की तुलना में बहुत अधिक CPU-कुशल
• डीएच को कुशल बनाने के लिए जावा jbigi पर निर्भर न करें
• DH संचालन को न्यूनतम करें
• ElGamal (514 बाइट ElGamal ब्लॉक) की तुलना में बहुत अधिक बैंडविड्थ-कुशल
• यदि वांछित हो तो एक ही टनल पर नए और पुराने क्रिप्टो का समर्थन करें
• प्राप्तकर्ता एक ही टनल पर आने वाले नए और पुराने क्रिप्टो को कुशलतापूर्वक अलग करने में सक्षम हो
• अन्य नए और पुराने या भावी क्रिप्टो को अलग नहीं कर सकते
• नए बनाम मौजूदा सत्र लंबाई वर्गीकरण को समाप्त करें (पैडिंग का समर्थन करें)
• कोई नए I2NP संदेशों की आवश्यकता नहीं
• AES पेलोड में SHA-256 चेकसम को AEAD से बदलें
• प्रेषण और प्राप्ति सत्रों को बांधने का समर्थन करें ताकि पुष्टिकरण प्रोटोकॉल के भीतर हो सकें, बजाय केवल आउट-ऑफ-बैंड के। इससे प्रतिक्रियाओं को तुरंत अग्रगामी गोपनीयता प्राप्त करने में भी सक्षम बनाएगा।
• कुछ संदेशों (राउटरइन्फो स्टोर्स) के एंड-टू-एंड एन्क्रिप्शन को सक्षम करें जिन्हें हम वर्तमान में CPU ओवरहेड के कारण नहीं करते हैं।
• I2NP लहसुन संदेश या लहसुन संदेश डिलीवरी निर्देश प्रारूप को न बदलें।
• लहसुन क्लोव सेट और क्लोव प्रारूपों में अप्रयुक्त या अतिरंजित क्षेत्रों को समाप्त करें।

सत्र टैग्स के कई समस्याओं को समाप्त करें, जिनमें शामिल हैं:

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

गैर-लक्ष्य / सीमा के बाहर

• LS2 प्रारूप परिवर्तन (प्रस्ताव 123 पूरा हो चुका है)
• नया DHT रोटेशन एल्गोरिथ्म या साझा यादृच्छिक उत्पादन
• टनल निर्माण के लिए नया एन्क्रिप्शन। प्रस्ताव 152 प्रस्ताव 152 देखें।
• टनल लेयर एन्क्रिप्शन के लिए नया एन्क्रिप्शन। प्रस्ताव 153 प्रस्ताव 153 देखें।
• I2NP DLM / DSM / DSRM संदेशों के एन्क्रिप्शन, प्रेषण और प्राप्ति के तरीके। नहीं बदल रहा है।
• कोई LS1-से-LS2 या ElGamal/AES-से-इस प्रस्ताव संचार समर्थित नहीं है। यह प्रस्ताव एक द्विदिश बातचीत प्रोटोकॉल है। गंतव्य पिछड़े संगतता को संभाल सकते हैं दो लीजसेट प्रकाशित करके एक ही टनल का उपयोग करके, या दोनों एन्क्रिप्शन प्रकारों को LS2 में डालकर।
• खतरे के मॉडल में परिवर्तन
• लागूकरण विवरण यहाँ चर्चा नहीं किए गए हैं और प्रत्येक परियोजना के लिए छोड़ दिए गए हैं।
• (आशावादी) मल्टीकास्ट का समर्थन करने के लिए विस्तार या हुक जोड़ें

औचित्य

लगभग 15 वर्षों से ElGamal/AES+SessionTag हमारा एकमात्र एंड-टू-एंड प्रोटोकॉल रहा है, मूल रूप से प्रोटोकॉल में कोई संशोधन नहीं। अब क्रिप्टोग्राफिक प्राइमिटिव्स हैं जो तेज हैं। हमें प्रोटोकॉल की सुरक्षा में वृद्धि करने की आवश्यकता है। हमने प्रोटोकॉल के मेमोरी और बैंडविड्थ ओवरहेड को न्यूनतम करने के लिए एकाधिक युक्तियाँ और उपाय विकसित किए हैं, लेकिन वे रणनीतियाँ कमजोर, ट्यून करने में कठिन हैं और प्रोटोकॉल को और अधिक टूटने के लिए प्रवृत्त बनाती हैं, जिससे सत्र गिर जाता है।

लगभग उसी समय से, ElGamal/AES+SessionTag विनिर्देश और संबंधित दस्तावेज़ीकरण ने बताया है कि सत्र टैग्स की डिलीवरी कितनी बैंडविड्थ-महंगी है, और सत्र टैग डिलीवरी को “सिंक्रनाइज़्ड PRNG” से बदलने का प्रस्ताव रखा है। एक सिंक्रनाइज़्ड PRNG एक सामान्य बीज से दोनों छोर पर समान टैग्स को निर्धारित रूप से उत्पन्न करता है। एक सिंक्रनाइज़्ड PRNG को “रैचेट” भी कहा जा सकता है। यह प्रस्ताव (अंततः) उस रैचेट तंत्र को निर्दिष्ट करता है, और टैग डिलीवरी को समाप्त करता है।

एक रैचेट (एक सिंक्रनाइज़्ड PRNG) का उपयोग करके सत्र टैग्स को उत्पन्न करके, हम नए सत्र संदेश और आवश्यकता पड़ने पर बाद के संदेशों में सत्र टैग्स भेजने के ओवरहेड को समाप्त करते हैं। 32 टैग्स के एक विशिष्ट टैग सेट के लिए, यह 1KB है। इससे भेजने वाली तरफ सत्र टैग्स के भंडारण को भी समाप्त कर दिया जाता है, इस प्रकार भंडारण आवश्यकताओं को आधा कर दिया जाता है।

Key Compromise Impersonation (KCI) हमलों से बचने के लिए, एक पूर्ण द्वि-तरफा हैंडशेक की आवश्यकता होती है, जो Noise IK पैटर्न के समान होता है। NOISE में नॉइज़ “पेलोड सुरक्षा गुण” तालिका देखें। KCI के बारे में अधिक जानकारी के लिए, पेपर https://www.usenix.org/system/files/conference/woot15/woot15-paper-hlauschek.pdf देखें

खतरे का मॉडल

NTCP2 (प्रस्ताव 111) की तुलना में खतरे का मॉडल कुछ अलग है। MitM नोड्स OBEP और IBGW हैं और यह माना जाता है कि उनके पास वर्तमान या ऐतिहासिक वैश्विक नेटडीबी का पूर्ण दृश्य है, फ्लडफिल्स के साथ षड्यंत्र रचकर।

लक्ष्य इन MitMs को ट्रैफ़िक को वर्गीकृत करने से रोकना है नए और मौजूदा सत्र संदेशों के रूप में, या नए क्रिप्टो बनाम पुराने क्रिप्टो के रूप में।

विस्तृत प्रस्ताव

यह प्रस्ताव ElGamal/AES+SessionTags को बदलने के लिए एक नया एंड-टू-एंड प्रोटोकॉल परिभाषित करता है। डिज़ाइन में सिग्नल के डबल रैचेट को शामिल करते हुए नॉइज़ हैंडशेक और डेटा चरण का उपयोग किया जाएगा।

क्रिप्टोग्राफिक डिज़ाइन का सारांश

पुनर्डिज़ाइन करने के लिए प्रोटोकॉल के पाँच हिस्से हैं:

• 1. नए और मौजूदा सत्र कंटेनर प्रारूप नए प्रारूपों के साथ बदल दिए जाते हैं।
• 2. ElGamal (256 बाइट सार्वजनिक कुंजियाँ, 128 बाइट निजी कुंजियाँ) को बदल दिया जाएगा ECIES-X25519 (32 बाइट सार्वजनिक और निजी कुंजियाँ) से
• 3. AES को बदल दिया जाएगा AEAD_ChaCha20_Poly1305 (नीचे ChaChaPoly के रूप में संक्षिप्त) से
• 4. SessionTags को रैचेट्स से बदल दिया जाएगा, जो अनिवार्य रूप से एक क्रिप्टोग्राफिक, सिंक्रनाइज़्ड PRNG है।
• 5. ElGamal/AES+SessionTags विनिर्देश में परिभाषित AES पेलोड, को NTCP2 में उपयोग किए गए ब्लॉक प्रारूप के समान ब्लॉक प्रारूप से बदल दिया जाता है।

पाँचों परिवर्तनों में से प्रत्येक के लिए नीचे अपना अनुभाग है।

I2P के लिए नए क्रिप्टोग्राफिक प्राइमिटिव्स

मौजूदा I2P राउटर लागूकरणों को निम्नलिखित मानक क्रिप्टोग्राफिक प्राइमिटिव्स के लागूकरणों की आवश्यकता होगी, जो वर्तमान I2P प्रोटोकॉल के लिए आवश्यक नहीं हैं:

• ECIES (लेकिन यह अनिवार्य रूप से X25519 है)
• एलिगेटर2

जिन मौजूदा I2P राउटर लागूकरणों ने अभी तक NTCP2 (प्रस्ताव 111 ) को लागू नहीं किया है उनके लिए भी लागूकरणों की आवश्यकता होगी:

• X25519 कुंजी उत्पादन और DH
• AEAD_ChaCha20_Poly1305 (नीचे ChaChaPoly के रूप में संक्षिप्त)
• HKDF

क्रिप्टो प्रकार

क्रिप्टो प्रकार (LS2 में उपयोग किया जाता है) 4 है। यह एक लिटिल-एंडियन 32-बाइट X25519 सार्वजनिक कुंजी को इंगित करता है, और यहाँ निर्दिष्ट एंड-टू-एंड प्रोटोकॉल।

क्रिप्टो प्रकार 0 ElGamal है। क्रिप्टो प्रकार 1-3 ECIES-ECDH-AES-SessionTag के लिए आरक्षित हैं, प्रस्ताव 145 प्रस्ताव 145 देखें।

नॉइज़ प्रोटोकॉल फ्रेमवर्क

यह प्रस्ताव NOISE (संशोधन 34, 2018-07-11) पर आधारित आवश्यकताएँ प्रदान करता है। नॉइज़ में STS प्रोटोकॉल STS के समान गुण हैं, जो SSU प्रोटोकॉल का आधार है। नॉइज़ बोलचाल में, एलिस प्रारंभकर्ता है, और बॉब प्रतिक्रियाकर्ता है।

यह प्रस्ताव Noise_IK_25519_ChaChaPoly_SHA256 प्रोटोकॉल पर आधारित है। (प्रारंभिक कुंजी व्युत्पत्ति फ़ंक्शन का वास्तविक पहचानकर्ता “Noise_IKelg2_25519_ChaChaPoly_SHA256” I2P विस्तारों को इंगित करने के लिए - नीचे KDF 1 अनुभाग देखें) यह नॉइज़ प्रोटोकॉल निम्नलिखित प्राइमिटिव्स का उपयोग करता है:

• इंटरैक्टिव हैंडशेक पैटर्न: IK एलिस तुरंत अपनी स्थिर कुंजी को बॉब को भेजती है (I) एलिस पहले से ही बॉब की स्थिर कुंजी जानती है (K)

• वन-वे हैंडशेक पैटर्न: N एलिस अपनी स्थिर कुंजी को बॉब को नहीं भेजती (N)

• DH फ़ंक्शन: X25519 RFC-7748 में निर्दिष्ट 32 बाइट की लंबाई के साथ X25519 DH।

• साइफर फ़ंक्शन: ChaChaPoly RFC-7539 अनुभाग 2.8 में निर्दिष्ट AEAD_CHACHA20_POLY1305। 12 बाइट नोन्स, पहले 4 बाइट शून्य पर सेट। NTCP2 में उपयोग किए गए के समान।

• हैश फ़ंक्शन: SHA256 मानक 32-बाइट हैश, जो I2P में व्यापक रूप से उपयोग किया जाता है।

फ्रेमवर्क में जोड़

यह प्रस्ताव Noise_IK_25519_ChaChaPoly_SHA256 में निम्नलिखित विस्तार परिभाषित करता है। ये आम तौर पर NOISE अनुभाग 13 में दिशानिर्देशों का अनुसरण करते हैं।

1. स्पष्टपन से अस्थायी कुंजियों को एलिगेटर2 के साथ कोड किया गया है।

2. प्रतिक्रिया को एक स्पष्टपन टैग के साथ उपसर्गित किया जाता है।

3. संदेश 1, 2 और डेटा चरण के लिए पेलोड प्रारूप परिभाषित किया गया है। निश्चित रूप से, यह नॉइज़ में परिभाषित नहीं है।

सभी संदेशों में एक I2NP लहसुन संदेश हेडर शामिल है। डेटा चरण में एन्क्रिप्शन का उपयोग नॉइज़ डेटा चरण के समान है, लेकिन उसके साथ संगत नहीं है।

हैंडशेक पैटर्न

हैंडशेक नॉइज़ हैंडशेक पैटर्न का उपयोग करते हैं।

निम्नलिखित अक्षर मैपिंग का उपयोग किया जाता है:

• e = एक-बार अस्थायी कुंजी
• s = स्थिर कुंजी
• p = संदेश पेलोड

एक-बार और अबाधित सत्र नॉइज़ N पैटर्न के समान हैं।

<- s
  ...
  e es p ->

बाध्य सत्र नॉइज़ IK पैटर्न के समान हैं।

<- s
  ...
  e es s ss p ->
  <- tag e ee se
  <- p
  p ->

सत्र

वर्तमान ElGamal/AES+SessionTag प्रोटोकॉल एक-दिशीय है। इस परत पर, प्राप्तकर्ता नहीं जानता कि संदेश कहाँ से आया है। बाहर जाने वाले और आने वाले सत्र जुड़े नहीं होते हैं। पुष्टिकरण डिलीवरीस्टेटसमैसेज का उपयोग करके आउट-ऑफ-बैंड होते हैं (एक गार्लिकमैसेज में लिपटे) क्लोव में।

एक एक-दिशीय प्रोटोकॉल में उल्लेखनीय अकुशलता है। कोई भी प्रतिक्रिया भी एक महंगे ‘नया सत्र’ संदेश का उपयोग करनी चाहिए। इससे उच्च बैंडविड्थ, CPU और मेमोरी उपयोग होता है।

एक एक-दिशीय प्रोटोकॉल में सुरक्षा कमजोरियाँ भी हैं। सभी सत्र अस्थायी-स्थिर DH पर आधारित होते हैं। बिना वापसी पथ के, बॉब के लिए अपनी स्थिर कुंजी को अस्थायी कुंजी में “रैचेट” करने का कोई तरीका नहीं है। यह न जानते हुए कि संदेश कहाँ से आया है, बाहर जाने वाले संदेशों के लिए प्राप्त अस्थायी कुंजी का उपयोग करने का कोई तरीका नहीं है, इसलिए प्रारंभिक प्रतिक्रिया भी अस्थायी-स्थिर DH का उपयोग करती है।

इस प्रस्ताव के लिए, हम एक द्वि-दिशीय प्रोटोकॉल बनाने के लिए दो तंत्र परिभाषित करते हैं - “जोड़ी बनाना” और “बांधना”। ये तंत्र बढ़ी हुई दक्षता और सुरक्षा प्रदान करते हैं।

सत्र संदर्भ

ElGamal/AES+SessionTags के समान, सभी आने वाले और बाहर जाने वाले सत्र एक दिए गए संदर्भ में होने चाहिए, या तो राउटर के संदर्भ में या एक विशिष्ट स्थानीय गंतव्य के संदर्भ में। जावा I2P में, इस संदर्भ को सत्र कुंजी प्रबंधक कहा जाता है।

संदर्भों के बीच सत्र साझा नहीं किए जाने चाहिए, क्योंकि इससे विभिन्न स्थानीय गंतव्यों के बीच सहसंबंध हो सकता है, या एक स्थानीय गंतव्य और एक राउटर के बीच।

जब एक दिया गंतव्य ElGamal/AES+SessionTags और इस प्रस्ताव दोनों का समर्थन करता है, तो दोनों प्रकार के सत्र एक संदर्भ साझा कर सकते हैं। नीचे खंड 1c) देखें।

आने वाले और बाहर जाने वाले सत्रों की जोड़ी बनाना

जब एक बाहर जाने वाला सत्र प्रारंभकर्ता (एलिस) पर बनाया जाता है, तो एक नया आने वाला सत्र बनाया जाता है और बाहर जाने वाले सत्र के साथ जोड़ा जाता है, जब तक कि कोई प्रतिक्रिया अपेक्षित न हो (उदाहरण के लिए, रॉ डेटाग्राम)।

एक नया आने वाला सत्र हमेशा एक नए बाहर जाने वाले सत्र के साथ जोड़ा जाता है, जब तक कि कोई प्रतिक्रिया अनुरोधित न हो (उदाहरण के लिए, रॉ डेटाग्राम)।

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

आने वाले और बाहर जाने वाले सत्रों को जोड़ने से एक द्वि-दिशीय प्रोटोकॉल प्राप्त होता है जिसमें DH कुंजियों को रैचेट करने की क्षमता होती है।

सत्रों और गंतव्यों को बांधना

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

जब एक बाहर जाने वाला सत्र प्रारंभकर्ता (एलिस) पर बनाया जाता है, तो यह दूर के गंतव्य (बॉब) से बांधा जाता है, और कोई भी जोड़ा गया आने वाला सत्र भी दूर के गंतव्य से बांधा जाएगा। जैसे-जैसे सत्र रैचेट होते हैं, वे दूर के गंतव्य से बांधे रहते हैं।

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

बांधने और जोड़ी बनाने के लाभ

सामान्य, स्ट्रीमिंग मामले के लिए, हम एलिस और बॉब को निम्नानुसार प्रोटोकॉल का उपयोग करने की उम्मीद करते हैं:

• एलिस अपने नए बाहर जाने वाले सत्र को एक नए आने वाले सत्र से जोड़ती है, दोनों दूर के गंतव्य (बॉब) से बांधे गए।
• एलिस बांधने की जानकारी और हस्ताक्षर, और एक प्रतिक्रिया अनुरोध शामिल करती है, बॉब को भेजे गए नए सत्र संदेश में।
• बॉब अपने नए आने वाले सत्र को एक नए बाहर जाने वाले सत्र से जोड़ता है, दोनों दूर के गंतव्य (एलिस) से बांधे गए।
• बॉब एलिस को जोड़े गए सत्र में एक प्रतिक्रिया (ack) भेजता है, एक नई DH कुंजी के साथ रैचेट करते हुए।
• एलिस बॉब की नई कुंजी के साथ एक नए बाहर जाने वाले सत्र पर रैचेट करती है, मौजूदा आने वाले सत्र से जुड़ा हुआ।

एक आने वाले सत्र को दूर के गंतव्य से बांधकर, और आने वाले सत्र को एक बाहर जाने वाले सत्र से जोड़कर जो उसी गंतव्य से बांधा गया है, हम दो प्रमुख लाभ प्राप्त करते हैं:

1. बॉब से एलिस की प्रारंभिक प्रतिक्रिया अस्थायी-अस्थायी DH का उपयोग करती है

2. एलिस के बॉब की प्रतिक्रिया प्राप्त करने और रैचेट करने के बाद, एलिस से बॉब के लिए सभी बाद के संदेश अस्थायी-अस्थायी DH का उपयोग करते हैं।

संदेश ACKs

ElGamal/AES+SessionTags में, जब एक LeaseSet एक लहसुन क्लोव के रूप में बंडल किया जाता है, या टैग्स की डिलीवरी की जाती है, तो भेजने वाला राउटर एक ACK का अनुरोध करता है। यह डिलीवरीस्टेटस मैसेज वाला एक अलग लहसुन क्लोव है। अतिरिक्त सुरक्षा के लिए, डिलीवरीस्टेटस मैसेज को एक लहसुन संदेश में लपेटा जाता है। यह तंत्र प्रोटोकॉल के संदर्भ में आउट-ऑफ-बैंड है।

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

एक स्पष्ट ACK केवल एक मौजूदा सत्र संदेश है जिसमें कोई I2NP ब्लॉक नहीं होता। हालांकि, अधिकांश मामलों में, स्पष्ट ACK से बचा जा सकता है, क्योंकि उल्टा ट्रैफ़िक होता है। लागूकरणों के लिए स्ट्रीमिंग या एप्लिकेशन परत को प्रतिक्रिया देने के समय देने के लिए एक छोटे समय (शायद सौ मिलीसेकंड) तक प्रतीक्षा करना वांछनीय हो सकता है।

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

सत्र समय समाप्ति

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