ECIES राउटर्स | I2P - अदृश्य इंटरनेट परियोजना

नोट

नेटवर्क तैनाती और परीक्षण प्रगति पर है। संशोधन के अधीन। स्थिति:

ECIES राउटर्स 0.9.48 के तहत कार्यान्वित, देखें Common।
टनल निर्माण 0.9.48 के तहत कार्यान्वित, देखें Tunnel-Creation-ECIES।
ECIES राउटर्स को एन्क्रिप्टेड संदेश 0.9.49 के तहत कार्यान्वित, देखें ECIES-ROUTERS।
नए टनल निर्माण संदेश 0.9.51 के तहत कार्यान्वित।

अवलोकन

सारांश

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

LS2 Prop123 और ECIES-X25519-AEAD-Ratchet Prop144 (अब ECIES में निर्दिष्ट) के लिए प्रस्ताव ElGamal को गंतव्यों के लिए ECIES के साथ बदलने की परिभाषित करते हैं।

यह प्रस्ताव राउटरों के लिए ElGamal को ECIES-X25519 के साथ बदलने की परिभाषित करता है। यह प्रस्ताव आवश्यक परिवर्तनों का अवलोकन प्रदान करता है। अधिकांश विवरण अन्य प्रस्तावों और विनिर्देशों में हैं। लिंक के लिए संदर्भ अनुभाग देखें।

लक्ष्य

अधिक लक्ष्य के लिए Prop152 देखें।

राउटर पहचानियों में ElGamal को ECIES-X25519 से बदलें
विद्यमान क्रिप्टोग्राफ़िक तत्वों का पुन: उपयोग करें
जहाँ संभव हो टनल निर्माण संदेश सुरक्षा में सुधार करें, जबकि अनुकूलता बनाए रखें
मिश्रित ElGamal/ECIES साथियों के साथ सुरंगों का समर्थन करें
वर्तमान नेटवर्क के साथ अधिकतम अनुकूलता
पूरे नेटवर्क के लिए “फ्लैग डे” उन्नयन की आवश्यकता न हो
जोखिम को कम करने के लिए चरणबद्ध रोलआउट
नया, छोटा टनल निर्माण संदेश

गैर-लक्ष्य

अतिरिक्त गैर-लक्ष्यों के लिए Prop152 देखें।

दोहरे-कुंजी राउटरों की आवश्यकता नहीं
लेयर एन्क्रिप्शन परिवर्तन, इसके लिए Prop153 देखें

डिज़ाइन

कुंजी स्थान और क्रिप्टो प्रकार

गंतव्यों के लिए, कुंजी leaseset में है, गंतव्य में नहीं, और हम एक ही leaseset में कई एन्क्रिप्शन प्रकारों का समर्थन करते हैं।

राउटर के लिए इसकी कोई आवश्यकता नहीं है। राउटर की एन्क्रिप्शन कुंजी इसकी राउटर पहचान में है। साझा संरचना विशिष्टता देखें Common।

राउटरों के लिए, हम राउटर पहचान में 256 बाइट ElGamal कुंजी को 32 बाइट X25519 कुंजी और 224 बाइट पैडिंग से बदलेंगे। यह कुंजी प्रमाण में क्रिप्टो प्रकार द्वारा संकेतित किया जाएगा। क्रिप्टो प्रकार (LS2 में उपयोग के समान) 4 है। यह एक लिटिल-एंडियन 32-बाइट X25519 सार्वजनिक कुंजी को इंगित करता है। यह साझा संरचनाओं के निर्दिष्ट मानक निर्माण के समान है Common।

यह प्रस्ताव 145 Prop145 में प्रस्तावित ECIES-P256 के लिए क्रिप्टो प्रकार 1-3 के लिए समान है। हालांकि इस प्रस्ताव को कभी अपनाया नहीं गया, जावा कार्यान्वयन विकासकर्ताओं ने राउटर पहचान कुंजी प्रमाणों में क्रिप्टो प्रकारों के लिए कोड बेस में कई स्थानों पर जांच जोड़कर तैयारी की। इनमें से अधिकांश कार्य 2019 के मध्य में किया गया।

टनल निर्माण संदेश

टनल निर्माण विनिर्देशन Tunnel-Creation में कई परिवर्तन आवश्यक हैं ताकि ECIES के बजाय ElGamal का उपयोग किया जा सके। इसके अलावा, हम टनल निर्माण संदेशों में सुधार करेंगे ताकि सुरक्षा बढ़ सके।

फेज 1 में, हम ECIES हॉप्स के लिए निर्माण अनुरोध रिकॉर्ड और निर्माण उत्तर रिकॉर्ड के प्रारूप और एन्क्रिप्शन को बदल देंगे। यह परिवर्तन मौजूदा ElGamal राउटरों के साथ संगत होंगे। यह परिवर्तन प्रस्ताव 152 Prop152 में परिभाषित हैं।

फेज 2 में, हम निर्माण अनुरोध संदेश, निर्माण उत्तर संदेश, निर्माण अनुरोध रिकॉर्ड और निर्माण उत्तर रिकॉर्ड का एक नया संस्करण जोड़ेंगे। प्रभावशीलता के लिए आकार कम किया जाएगा। ये बदलाव सुरंग में सभी हॉप्स द्वारा समर्थित होने चाहिए, और सभी हॉप्स ECIES होने चाहिए। यह परिवर्तन प्रस्ताव 157 Prop157 में परिभाषित हैं।

अंत-से-अंत एन्क्रिप्शन

इतिहास

जावा I2P के मूल डिजाइन में, राउटर और उसके सभी स्थानीय गंतव्यों द्वारा साझा एक ElGamal सेशन कुंजी प्रबंधक (SKM) था। एक साझा SKM जानकारी का रिसाव कर सकता था और हमलावरों द्वारा सहसंबंध करने की अनुमति देता था, डिजाइन को राउटर और प्रत्येक गंतव्य के लिए अलग-अलग ElGamal SKM का समर्थन करने के लिए बदल दिया गया था। ElGamal डिज़ाइन ने केवल गुमनाम प्रेषकों का समर्थन किया; प्रेषक ने केवल अल्पकालिक कुंजियाँ भेजीं, कोई स्थिर कुंजी नहीं। संदेश को प्रेषक की पहचान से नहीं जोड़ा गया था।

फिर, हमने ECIES Ratchet SKM डिज़ाइन किया ECIES-X25519-AEAD-Ratchet Prop144 में, अब ECIES में निर्दिष्ट किया गया है। यह डिज़ाइन शोर “IK” पैटर्न का उपयोग करता है, जिसमें प्रेषक की स्थिर कुंजी पहले संदेश में शामिल थी। यह प्रोटोकॉल ECIES (प्रकार 4) गंतव्यों के लिए उपयोग किया जाता है। IK पैटर्न गुमनाम प्रेषकों की अनुमति नहीं देता है।

इसलिए, हमने प्रस्ताव में एक तरीका भी शामिल किया है कि एक Ratchet SKM को गुमनाम संदेश कैसे भेजें, एक शून्य-भरी स्थिर कुंजी का उपयोग करके। इसने शोर “N” पैटर्न को अनुकरण किया, लेकिन एक संगत तरीके से, ताकि ECIES SKM गुमनाम और गैर-गुमनाम दोनों संदेश प्राप्त कर सके। इरादा ECIES राउटरों के लिए ज़ीरो-कुंजी का उपयोग करने का था।

उपयोग मामलों और धमकी मॉडल्स

राउटरों को भेजे गए संदेशों के लिए उपयोग मामला और धमकी मॉडल गंतव्यों के बीच अंत-से-अंत संदेशों से बहुत अलग है।

गंतव्य उपयोग मामला और धमकी मॉडल:

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

राउटर उपयोग मामला और धमकी मॉडल:

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

राउटर उपयोग-केस गैर-लक्ष्य:

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

डिजाइन निष्कर्ष

ECIES राउटर SKM को गंतव्यों के लिए ECIES में निर्दिष्ट एक पूर्ण रैचेट SKM की आवश्यकता नहीं है। गैर-गुमनाम संदेश की आवश्यकता नहीं है जो IK पैटर्न का उपयोग करते हैं। धमकी मॉडल को ईलीगेट्र2-एन्कोडेड अल्पकालिक कुंजियों की आवश्यकता नहीं है।

इसलिए, राउटर SKM शोर “N” पैटर्न का उपयोग करेगा, जैसा कि Prop152 में सुरंग निर्माण के लिए निर्दिष्ट है। यह गंतव्यों के लिए ECIES में निर्दिष्ट पेलोड प्रारूप का उपयोग करेगा। IK में निर्दिष्ट ज़ीरो स्थिर कुंजी (कोई बाइंडिंग या सेशन नहीं) मोड का उपयोग नहीं किया जाएगा।

लुकअप के उत्तर को लुकअप में अनुरोधित होने पर एक रैचेट टैग के साथ एन्क्रिप्ट किया जाएगा। यह Prop154, अबI2NP में निर्दिष्ट है में प्रलेखित है।

डिजाइन राउटर को एक ही ECIES सेशन की मैनेजर रखने में सक्षम बनाता है। वर्णित रूप में गंतव्यों के लिए “ड्यूल की” सेशन की मैनेजर्स चलाने की कोई आवश्यकता नहीं है [ECIES] में। राउटरों के पास केवल एक सार्वजनिक कुंजी है।

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

एक ECIES राउटर को प्री-0.9.46 बाढ़फिल राउटरों से नेटडिब लुकअप से प्राप्त उत्तर के रूप में प्राप्त ElGamal-टैग किए गए संदेश प्राप्त करने के लिए आंशिक ElGamal Seशसन की मैनेजर की आवश्यकता हो सकती है, क्योंकि इन राउटरों में Prop152 में निर्दिष्ट ECIES-टैग किए गए उत्तरों के कार्यान्वयन की आवश्यकता नहीं है। यदि नहीं, तो एक ECIES राउटर प्री-0.9.46 बाढ़फिल राउटर से एन्क्रिप्टेड उत्तर का अनुरोध नहीं कर सकता है।

यह वैकल्पिक है। निर्णय विभिन्न I2P कार्यान्वयनों में भिन्न हो सकता है और यह उस नेटवर्क की मात्रा पर भी निर्भर हो सकता है जो 0.9.46 या उससे उच्चतर को उन्नत किया गया है। इस तारीख तक, लगभग 85% नेटवर्क 0.9.46 या उससे अधिक का है।

विनिर्देशन

X25519: देखें ECIES।

राउटर पहचान और कुंजी प्रमाणपत्र: देखें Common।

टनल निर्माण: देखें Prop152।

नया टनल निर्माण संदेश: देखें Prop157।

अनुरोध एन्क्रिप्शन

अनुरोध एन्क्रिप्शन वही है जैसा कि Tunnel-Creation-ECIES और Prop152 में निर्दिष्ट है, “शोर N” पैटर्न का उपयोग करते हुए।

लुकअप के उत्तरों को यदि लुकअप में अनुरोधित किया गया है तो एक रैचेट टैग के साथ एन्क्रिप्ट किया जाएगा। डेटाबेस लुकअप अनुरोध संदेश 32-बाइट रिप्लाई कुंजी और 8-बाइट रिप्लाई टैग को दर्शाते हैं जैसा कि I2NP और Prop154 में निर्दिष्ट है। उत्तर को एन्क्रिप्ट करने के लिए कुंजी और टैग का उपयोग किया जाता है।

टैग सेट नहीं बनाए जाते हैं। शून्य स्थिर कुंजी योजना निर्दिष्ट ECIES-X25519-AEAD-Ratchet Prop144 और ECIES में उपयोग नहीं किया जाएगा। अल्पकालिक कुंजियाँ Eलीगेट्र2-एन्कोडेड नहीं होंगी।

सामान्यत:, ये नए सत्र संदेश होंगे और एक शून्य स्थिर कुंजी (कोई बाइंडिंग या सत्र नहीं) के साथ भेजे जाएंगे, क्योंकि संदेश का प्रेषक गुमनाम है।

शुरुआत के लिए ck और h के लिए KDF

यह मानक NOISE है पैटर्न “N” के लिए एक मानक प्रोटोकॉल नाम के साथ। यह वही है जैसा कि सुरंग निर्माण संदेशों के लिए Tunnel-Creation-ECIES और Prop152 में निर्दिष्ट है।


यह "e" संदेश पैटर्न है:

// प्रोटोकॉल_name परिभाषित करें।
Set protocol_name = "Noise_N_25519_ChaChaPoly_SHA256"
(31 बाइट्स, US-ASCII इनकोडेड, कोई NULL समापन नहीं)।

// हैश h = 32 बाइट्स परिभाषित करें
// 32 बाइट्स तक पैड करें। इसे हैश न करें, क्योंकि यह 32 बाइट्स से अधिक नहीं है।
h = protocol_name || 0

ck = 32 बाइट चेनिंग कुंजी परिभाषित करें। h डेटा को ck. में कॉपी करें।
चेनकी सेट करें = h

// MixHash(null प्रोलॉग)
h = SHA256(h);

// यहां तक किया जा सकता है सभी राउटरों द्वारा पहले से ही गणना की जाती है।

मैसेज के लिए KDF

संदेश निर्माता प्रत्येक संदेश के लिए एक अल्पकालिक X25519 कुंजीद्वय उत्पन्न करते हैं। प्रत्येक संदेश के लिए अद्वितीय अल्पकालिक कुंजियाँ होनी चाहिए। यह वही है जैसा कि सुरंग निर्माण संदेशों के लिए Tunnel-Creation-ECIES और Prop152 में निर्दिष्ट है।



// लक्ष्य राउटर की X25519 स्थैतिक कुंजी (hesk, hepk) Router Identity से
hesk = GENERATE_PRIVATE()
hepk = DERIVE_PUBLIC(hesk)

// MixHash(hepk)
// नीचे का अर्थ है जोड़ें
h = SHA256(h || hepk);

// यहां तक किया जा सकता है प्रत्येक राउटर द्वारा
// आने वाले सभी संदेशों के लिए पहले से गणना की जाती है

// प्रेषक एक X25519 अल्पकालिक कुंजीद्वय उत्पन्न करता है
sesk = GENERATE_PRIVATE()
sepk = DERIVE_PUBLIC(sesk)

// MixHash(sepk)
h = SHA256(h || sepk);

"e" संदेश पैटर्न का अंत।

यह "es" संदेश पैटर्न है:

// शोर es
// प्रेषक रिसीवर की स्थिर सार्वजनिक कुंजी के साथ एक X25519 DH करता है।
// लक्ष्य राउटर
// एन्क्रिप्टेड रिकॉर्ड से पहले प्रेषक की अल्पकालिक कुंजी निकालता है।
sharedSecret = DH(sesk, hepk) = DH(hesk, sepk)

// MixKey(DH())
//[chainKey, k] = MixKey(sharedSecret)
// चै-चा-पॉली पैरामीटर को एन्क्रिप्ट/डिक्रिप्ट करने के लिए
keydata = HKDF(chainKey, sharedSecret, "", 64)
// चेन कुंजी का उपयोग नहीं किया जाता है
//chainKey = keydata[0:31]

// AEAD पैरामीटर
k = keydata[32:63]
n = 0
plaintext = 464 बाइट निर्माण अनुरोध रिकॉर्ड
ad = h
ciphertext = ENCRYPT(k, n, plaintext, ad)

"es" संदेश पैटर्न का अंत।

// MixHash(ciphertext) आवश्यक नहीं है
//h = SHA256(h || ciphertext)

पेलोड

पेलोड वही ब्लॉक प्रारूप है जैसा कि ECIES और Prop144 में परिभाषित किया गया है। सभी संदेशों में पुनरावृत्ति निवारण के लिए एक DateTime ब्लॉक होना चाहिए।

उत्तर एन्क्रिप्शन

डेटाबेस लुकअप संदेशों के उत्तर डेटाबेस स्टोर या डेटाबेस खोज उत्तर संदेश होते हैं। वे मौजूदा सत्र संदेशों के रूप में एन्क्रिप्ट किए जाते हैं जैसा कि I2NP और Prop154 में निर्दिष्ट 32-बाइट उत्तर कुंजी और 8-बाइट उत्तर टैग के साथ एन्क्रिप्ट किए जाते हैं।

डेटाबेस स्टोर संदेशों के लिए कोई स्पष्ट उत्तर नहीं होते हैं। प्रेषक इसे अपने लिए एक जार्लिक संदेश के रूप में बंडल किए गए डिलीवरी स्टेटस संदेश को अपने लिए बंडल कर सकता है।

औचित्य

यह डिज़ाइन मौजूदा क्रिप्टोग्राफ़िक तत्वों, प्रोटोकॉल और कोड का अधिकतम पुन: उपयोग करता है।

यह डिज़ाइन जोखिम को कम करता है।

कार्यान्वयन नोट्स

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

मुद्दे

प्रस्तावना 145 Prop145 या तो प्रस्ताव 152 Prop152 के साथ ज्यादातर-संगत की तरह फिर से लिखा जा सकता है या नहीं।

माइग्रेशन

कार्यान्वयन, परीक्षण, और रोलआउट में कई रिलीज़ और लगभग एक वर्ष लगेंगे। चरण निम्नानुसार हैं। प्रत्येक चरण को एक विशेष रिलीज़ में असाइन करना TBD और विकास की गति पर निर्भर करेगा।

प्रत्येक I2P कार्यान्वयन के लिए कार्यान्वयन और माइग्रेशन का विवरण भिन्न हो सकता है।

बुनियादी पॉइंट-पॉइंट

ECIES राउटर ElGamal राउटरों से कनेक्ट और कनेक्शन प्राप्त कर सकते हैं। यह अब संभव होना चाहिए, क्योंकि कई जाँचें प्रस्ताव 145 Prop145 के अनुपूर्ण अपडेट को देखते हुए मिड-2019 तक जावा कोड बेस में जोड़ी गई थीं। सुनिश्चित करें कि कोड बेस में ऐसा कुछ नहीं है जो गैर-ElGamal राउटरों के लिए पॉइंट-पॉइंट कनेक्शन को रोकता हो।

कोड सटीकता जांचें:

यह सुनिश्चित करें कि ElGamal राउटर डेटाबेस लुकअप संदेशों के लिए AEAD-एन्क्रिप्टेड उत्तरों का अनुरोध नहीं करते हैं (जब उत्तर एक अन्वेषणीय सुरंग के माध्यम से राउटर पर वापस आता है)
सुनिश्चित करें कि ECIES राउटर डेटाबेस लुकअप संदेशों के लिए AES-एन्क्रिप्टेड उत्तरों का अनुरोध नहीं करते हैं (जब उत्तर एक अन्वेषणीय सुरंग के माध्यम से राउटर पर वापस आता है)

बाद के चरणों तक, जबतक विनिर्देश और कार्यान्वयन पूर्ण न हो:

सुनिश्चित करें कि ElGamal राउटर ECIES राउटरों के माध्यम से सुरंग निर्माण का प्रयास नहीं करते हैं।
सुनिश्चित करें कि ElGamal राउटर ECIES बाढ़फिल राउटरों को एन्क्रिप्टेड ElGamal संदेश नहीं भेजते (डेटाबेस लुकअप्स और डेटाबेस स्टोर्स)
सुनिश्चित करें कि ECIES राउटर ElGamal बाढ़फिल राउटरों को एन्क्रिप्टेड ECIES संदेश नहीं भेजते (डेटाबेस लुकअप्स और डेटाबेस स्टोर्स)
सुनिश्चित करें कि ECIES राउटर अपने आप को बाढ़फिल में नहीं बदलते।

कोई परिवर्तन आवश्यक नहीं होना चाहिए। लक्ष्य रिलीज़, यदि परिवर्तन आवश्यक हैं: 0.9.48

नेटडिब अनुकूलता

सुनिश्चित करें कि ECIES राउटर की जानकारी ElGamal बाढ़फिल्स में संग्रहित और पुनर्प्राप्त की जा सकती है। यह अब संभव होना चाहिए, क्योंकि कई जाँचें प्रस्ताव 145 Prop145 के अनुपूर्ण अपडेट को देखते हुए मिड-2019 तक जावा कोड बेस में जोड़ी गई थीं। सुनिश्चित करें कि कोड बेस में ऐसा कुछ नहीं है जो नेटवर्क डेटाबेस में गैर-ElGamal RouterInfos के संग्रहण को रोकता हो।

सुरंग भवन

प्रस्ताव 152 Prop152 में परिभाषित की तरह सुरंग निर्माण को कार्यान्वित करें। ECIES राउटर के लिए सभी ElGamal हॉप्स का प्रयोग करके इसकी अपनी निर्माण अनुरोध रिकॉर्ड का प्रयोग करके इनबाउंड सुरंग के लिए परीक्षण और डिबग करें।

फिर ECIES राउटर के द्वारा ElGamal और ECIES हॉप्स के मिश्रण के साथ सुरंग निर्माण का परीक्षण और समर्थन करें।

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

लक्ष्य रिलीज़: 0.9.48, लेट 2020

ECIES बाढ़फिल पर रैचेट संदेश

बलात्कार के रूप में प्रस्ताव 144 Prop144 में परिभाषित के अनुसार ECIES संदेशों (ज़ीरो स्थिर कुंजी के साथ) की ECIES बाढ़फिल पर स्वीकृहणत परीक्षण करें। AEAD उत्तरों के स्वीकृहणत परीक्षण द्वारा ग्राहकों के लिए लिन की संदेश।

ECIES राउटरों द्वारा ऑटो-बाढ़फिल को सक्षम करें। फिर ECIES संदेशों को ECIES राउटरों को भेजने को सक्षम करें। कोई न्यूनतम संस्करण जांच आवश्यक नहीं होनी चाहिए जबतक कि एक रिलीज़ के बाद प्रस्ताव 152 के लिए असंगत परिवर्तनों की आवश्यकता नहीं होती है।

लक्ष्य रिलीज़: 0.9.49, प्रारंभिक 2021। ECIES राउटर स्वतः ही बाढ़फिल हो सकते हैं।

रीकियींग और नई इंस्टॉल्स

नई इंस्टॉल्स रिलीज़ 0.9.49 के बाद ECIES को डिफॉल्ट के रूप में सेट कर देंगे।

जोखिम और नेटवर्क के विघटन को न्यूनतम करने के लिए सभी राउटरों को धीरे-धीरे पुनःकुंजी बनाएं। वर्षों पहले हस्तांतरण प्रकार के प्रवास के लिए पुनःकुंजी के लिए मौजूदा कोड का उपयोग करें। यह कोड प्रत्येक राउटर को पुनःकुंजी के लिए प्रत्येक रिस्टार्ट पर छोटे बेतरतीब मौके का देता है। कई रिस्टार्ट के बाद, एक राउटर संभवतः ECIES में पुनःेखलित हो जाएगा।

रीकियींग को शुरू करने का मापदंड यह है कि नेटवर्क का एक पर्याप्त भाग, शायद 50%, ECIES राउटरों के माध्यम से सुरंगें बना सकते हैं (0.9.48 या उच्चतर)।

उपशेर्लि नेटवर्क के अधिकांश (शायद 90% या उससे अधिक) ECIES राउटरों के माध्यम से सुरंगें बना सकते हैं (0.9.48 या उच्चतर) और ECIES बाढ़फिलों पर संदेश भेज सकते हैं (0.9.49 या उच्चतर)। यह लक्ष्य शायद 0.9.52 रिलीज़ के लिए पहुँच जाएगा।

रीकियींग को कई रिलीज़ों में लगेगा।

लक्ष्य रिलीज़: 0.9.49 के लिए नए राउटर ECIES को डिफॉल्ट के रूप में सेट करने के लिए; 0.9.49 धीरे-धीरे रीकियींग शुरू करने के लिए; 0.9.50 - 0.9.52 रीकियींग दर को बार-बार बढ़ाने के लिए; लेट 2021 के लिए नेटवर्क के अधिकांश को रीकियींग किया जाएगा।

नया टनल बिल्ड मैसेज (चरण 2)

प्रस्ताव 157 Prop157 में परिभाषित के अनुसार नए टनल बिल्ड मैसेज का कार्यान्वयन और परीक्षण करें। रिलीज़ 0.9.51 में समर्थन का विस्तार करें। अतिरिक्त परीक्षण करें, फिर रिलीज़ 0.9.52 में सक्षम करें।

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

लक्ष्य रिलीज़: 0.9.52, लेट 2021।

रीकियींग पूर्ण

इस बिंदु पर, कुछ TBD संस्करण से अधिक उम्र के राउटर अधिकांश साथियों के माध्यम से सुरंग नहीं बना पाएंगे।

लक्ष्य रिलीज़: 0.9.53, प्रारंभिक 2022।

नोट