नोट
नेटवर्क परिनियोजन और परीक्षण प्रगति पर है। हल्के संशोधनों के लिए संभव। आधिकारिक विनिर्देशन के लिए SPEC देखें।
अवलोकन
मानक बेस 32 (“b32”) पते गंतव्य के हैश को शामिल करते हैं। यह एन्क्रिप्टेड ls2 (प्रस्तावना 123) के लिए काम नहीं करेगा।
आप एक पारंपरिक बेस 32 पता एन्क्रिप्टेड LS2 (प्रस्तावना 123) के लिए उपयोग नहीं कर सकते हैं, क्योंकि इसमें केवल गंतव्य का हैश शामिल होता है। यह गैर-अंधा सार्वजनिक कुंजी प्रदान नहीं करता है। क्लाइंट्स को गंतव्य की सार्वजनिक कुंजी, सिग प्रकार, अंधा सिग प्रकार, और एक वैकल्पिक गुप्त या निजी कुंजी लीसेट को प्राप्त करने और डिक्रिप्ट करने के लिए जानना चाहिए। इसलिए, केवल एक बेस 32 पता अपर्याप्त है। क्लाइंट को या तो पूरा गंतव्य चाहिए (जो कि सार्वजनिक कुंजी को शामिल करता है), या सार्वजनिक कुंजी स्वयं से चाहिए। यदि क्लाइंट के पास एक पता पुस्तिका में पूरा गंतव्य है, और पता पुस्तिका हैश द्वारा उलटे खोज का समर्थन करती है, तो सार्वजनिक कुंजी प्राप्त की जा सकती है।
इसलिए हमें एक नया प्रारूप चाहिए जो हैश के बजाय एक बेस32 पते में सार्वजनिक कुंजी डालता है। इस प्रारूप में सार्वजनिक कुंजी के हस्ताक्षर प्रकार, और अंधा योजना का हस्ताक्षर प्रकार भी शामिल होना चाहिए।
यह प्रस्ताव इन पतों के लिए एक नया b32 प्रारूप दस्तावेज करता है। जबकि हमने चर्चाओं के दौरान इस नए प्रारूप को “b33” पते के रूप में संदर्भित किया है, वास्तविक नया प्रारूप सामान्य “.b32.i2p” प्रत्यय को बनाए रखता है।
लक्ष्य
- भविष्य की अंधावस्था योजनाओं का समर्थन करने के लिए बिना अंधे और अंधा सिग प्रकार दोनों शामिल करें
- 32 बाइट्स से बड़े पबक्स का समर्थन करें
- सुनिश्चित करें कि b32 अक्षर सभी या अधिकांशत: यादृच्छिक हैं, खासकर शुरुआत में (नहीं चाहते कि सभी पते एक ही अक्षरों से शुरू हों)
- पार्स करने योग्य
- संकेत दें कि अंधा रहस्य और/या प्रति-ग्राहक कुंजी की आवश्यकता है
- टाइपो का पता लगाने के लिए चेकसम जोड़ें
- लंबाई को न्यूनतम रखें, सामान्य प्रयोग के लिए DNS लेबल की लंबाई 63 अक्षरों से कम रखें
- केस-असंवेदनशीलता के लिए बेस 32 का उपयोग जारी रखें
- सामान्य “.b32.i2p” प्रत्यय को बनाए रखें।
गैर-लक्ष्य
- अंधा रहस्य और/या प्रति-ग्राहक कुंजी शामिल करने वाले “निजी” लिंक का समर्थन न करें; यह असुरक्षित होगा।
डिज़ाइन
- नया प्रारूप बिना अंधा सार्वजनिक कुंजी, बिना अंधा सिग प्रकार, और अंधा सिग प्रकार को शामिल करेगा।
- केवल निजी लिंक के लिए एक रहस्य और/या निजी कुंजी वैकल्पिक रूप से शामिल करें
- मौजूदा “.b32.i2p” प्रत्यय का उपयोग करें, लेकिन लंबी लंबाई के साथ।
- एक चेकसम जोड़ें।
- एन्क्रिप्टेड लीसेट्स के लिए पते 56 या अधिक एन्कोड किए गए अक्षरों द्वारा पहचाने जाते हैं (35 या अधिक डिकोड किए गए बाइट्स), पारंपरिक बेस 32 पतों के लिए 52 अक्षरों (32 बाइट्स) की तुलना में।
विनिर्देशन
निर्माण और एन्कोडिंग
{56+ अक्षर}.b32.i2p(35+ बाइट्स बाइनरी में) का होस्टनाम निम्नलिखित तरीके बनाएँ:
फ्लैग (1 बाइट)
बिट 0: 1-बाइट सिग प्रकारों के लिए 0, 2-बाइट सिग प्रकारों के लिए 1
बिट 1: गुप्त के बिना 0, यदि गुप्त की आवश्यकता है तो 1
बिट 2: प्रति-ग्राहक प्रमाणीकरण के लिए 0,
यदि ग्राहक की निजी कुंजी की आवश्यकता है तो 1
बिट्स 7-3: अप्रयुक्त, 0 पर सेट करें
सार्वजनिक कुंजी सिग प्रकार (फ्लैग में संकेत के अनुसार 1 या 2 बाइट)
यदि 1 बाइट, तो ऊपरी बाइट शून्य मान ली जाती है
अंधा कुंजी सिग प्रकार (फ्लैग में संकेत के अनुसार 1 या 2 बाइट)
यदि 1 बाइट, तो ऊपरी बाइट शून्य मान ली जाती है
सार्वजनिक कुंजी
सिग प्रकार द्वारा संकेतित बाइट्स की संख्या
पोस्ट-प्रोसेसिंग और चेकसम:
उपरोक्त बाइनरी डेटा का निर्माण करें।
चेकसम को नन्हे-एंडियन के रूप में मानें।
चेकसम = CRC-32(data[3:end]) की गणना करें
data[0] ^= (बाइट) चेकसम
data[1] ^= (बाइट) (चेकसम >> 8)
data[2] ^= (बाइट) (चेकसम >> 16)
होस्टनाम = Base32.encode(data) || ".b32.i2p"
b32 के अंत में कोई भी अप्रयुक्त बिट्स 0 होने चाहिए। एक मानक 56 अक्षर (35 बाइट) पते के लिए कोई अप्रयुक्त बिट्स नहीं होते।
डिकोडिंग और सत्यापन
".b32.i2p" को होस्टनाम से हटाएं
data = Base32.decode(hostname)
चेकसम = CRC-32(data[3:end]) की गणना करें
चेकसम को नन्हे-एंडियन के रूप में मानें।
flags = data[0] ^ (बाइट) चेकसम
अगर 1 बाइट सिग प्रकार:
pubkey sigtype = data[1] ^ (बाइट) (चेकसम >> 8)
blinded sigtype = data[2] ^ (बाइट) (चेकसम >> 16)
अन्यथा (2 बाइट सिग प्रकार) :
pubkey sigtype = data[1] ^ ((बाइट) (चेकसम >> 8)) || data[2] ^ ((बाइट) (चेकसम >> 16))
blinded sigtype = data[3] || data[4]
सार्वजनिक कुंजी प्राप्त करने के लिए फ्लैग्स के आधार पर बाकी का पार्स करें
रहस्य और निजी कुंजी बिट्स
रहस्य और निजी कुंजी बिट्स ग्राहकों, प्रॉक्सी, या अन्य ग्राहक-पक्ष कोड को संकेत देने के लिए उपयोग किए जाते हैं कि लीसेट को डिक्रिप्ट करने के लिए रहस्य और/या निजी कुंजी की आवश्यकता होगी। विशिष्ट कार्यान्वयन उपयोगकर्ता को आवश्यक डेटा प्रदान करने के लिए प्रेरित कर सकते हैं, या आवश्यक डेटा की अनुपस्थिति में कनेक्शन प्रयासों को अस्वीकार कर सकते हैं।
न्यायसंगतता
- हैश के साथ पहले 3 बाइट्स को XOR करने से एक सीमित चेकसम क्षमता मिलती है, और यह सुनिश्चित करता है कि शुरुआत में सभी बेस32 अक्षर यादृच्छिक हों। केवल कुछ फ्लैग और सिग प्रकार संयोजन मान्य होते हैं, इसलिए कोई भी टाइपो कमजोर संयोजन बना सकता है और उसे अस्वीकार कर दिया जाएगा।
- सामान्य मामले में (1 बाइट सिग प्रकार, कोई रहस्य नहीं, कोई प्रति-ग्राहक प्रमाणीकरण नहीं), होस्टनाम {56 अक्षर}.b32.i2p, 35 बाइट्स में डिकोड होगा, ठीक टोर के समान।
- टोर 2-बाइट चेकसम की 1/64K नकली नकारात्मक दर है। 3 बाइट्स के साथ, थोड़े अनदेखे बाइट्स को छोड़कर, हमारी दर करीब 1 मिलियन में 1 हो रही है, क्योंकि ज्यादातर फ्लैग/सिग प्रकार संयोजन अमान्य हैं।
- Adler-32 का छोटे इनपुट के लिए खराब विकल्प है, और छोटे परिवर्तनों का पता लगाने के लिए । इसके बजाय CRC-32 का उपयोग करें। CRC-32 तेज होता है और व्यापक रूप से उपलब्ध है।
कैशिंग
जबकि इस प्रस्ताव के दायरे के बाहर है, राउटर्स और/या क्लाइंट्स को सार्वजनिक कुंजी के गंतव्य के साथ मैपिंग को याद रखना और कैश करना चाहिए (शायद स्थायी रूप से) और इसके विपरीत।
नोट्स
- नए प्रारूप को पुराने स्वरूपों से लंबाई के द्वारा अलग करें। पुराने b32 पते हमेशा {52 अक्षर}.b32.i2p होते हैं। नए {56+ अक्षर}.b32.i2p होते हैं।
- टोर चर्चा धागा: https://lists.torproject.org/pipermail/tor-dev/2017-January/011816.html
- 2-बाइट सिग प्रकारों की उम्मीद न करें, हम केवल 13 तक गए हैं। अब कार्यान्वयन की आवश्यकता नहीं है।
- नए प्रारूप को जम्प लिंक में (और जंप सर्वरों द्वारा पेश किए गए) अगर चाहें तो इस्तेमाल किया जा सकता है, जैसे कि b32।
मुद्दे
- कोई भी रहस्य, निजी कुंजी, या सार्वजनिक कुंजी जो 32 बाइट्स से लंबी होती है DNS अधिकतम लेबल लंबाई 63 अक्षर से अधिक होगी। संभवतः ब्राउज़र परवाह नहीं करेंगे।
माइग्रेशन
कोई पिछड़ी संगतता समस्या नहीं है। लंबा b32 पते पुराने सॉफ़्टवेयर में 32-बाइट हैश में परिवर्तित होने में विफल रहेगा।