नए netDB एंट्रीज़

स्थिति

इस प्रस्ताव के कुछ भाग पूर्ण हैं और 0.9.38 और 0.9.39 में लागू किए गए हैं।
सामान्य संरचनाएँ, I2CP, I2NP, और अन्य विनिर्देश अब उन परिवर्तनों को दर्शाने के लिए अद्यतन किए गए हैं जो अब समर्थित हैं।

पूर्ण हुए भाग अभी भी छोटे संशोधनों के अधीन हैं।
इस प्रस्ताव के अन्य भाग अभी विकासाधीन हैं
और बड़े पैमाने पर संशोधन के अधीन हैं।

सेवा लुकअप (प्रकार 9 और 11) कम प्राथमिकता वाले हैं और
अनिर्धारित हैं, और एक अलग प्रस्ताव में अलग किए जा सकते हैं।

अवलोकन

यह निम्नलिखित 4 प्रस्तावों का एक अद्यतन और समूहीकरण है:

• 110 LS2
• 120 मैसिव मल्टीहोमिंग के लिए मेटा LS2
• 121 एन्क्रिप्टेड LS2
• 122 अनॉथेंटिकेटेड सर्विस लुकअप (एनीकास्टिंग)

ये प्रस्ताव अधिकांशतः स्वतंत्र हैं, लेकिन स्वास्थ्य के लिए हम कई में एक
सामान्य प्रारूप परिभाषित और उपयोग करते हैं।

निम्नलिखित प्रस्ताव थोड़े संबंधित हैं:

• 140 इनविजिबल मल्टीहोमिंग (इस प्रस्ताव के साथ असंगत)
• 142 न्यू क्रिप्टो टेम्पलेट (नए सममित क्रिप्टो के लिए)
• 144 ECIES-X25519-AEAD-Ratchet
• 145 ECIES-P256
• 146 Red25519
• 148 EdDSA-BLAKE2b-Ed25519
• 149 B32 for Encrypted LS2
• 150 Garlic Farm Protocol
• 151 ECDSA Blinding

प्रस्ताव

यह प्रस्ताव 5 नए DatabaseEntry प्रकारों और उन्हें नेटवर्क डेटाबेस में
संग्रहीत करने और उन्हें पुनः प्राप्त करने की प्रक्रिया को परिभाषित करता है,
साथ ही उन पर हस्ताक्षर करने और उन हस्ताक्षरों को सत्यापित करने की विधि को भी।

लक्ष्य

• पिछड़ा संगत
• पुराने शैली के मल्टीहोमिंग के साथ LS2 का उपयोग
• समर्थन के लिए कोई नया क्रिप्टो या प्राथमिक आवश्यक नहीं
• क्रिप्टो और हस्ताक्षर के अलगाव को बनाए रखें; सभी वर्तमान और भावी संस्करणों का समर्थन करें
• वैकल्पिक ऑफ़लाइन हस्ताक्षर कुंजियों को सक्षम करें
• फिंगरप्रिंटिंग को कम करने के लिए टाइमस्टैम्प की सटीकता कम करें
• गंतव्यों के लिए नया क्रिप्टो सक्षम करें
• मैसिव मल्टीहोमिंग सक्षम करें
• मौजूदा एन्क्रिप्टेड LS के कई मुद्दों को ठीक करें
• फ्लडफिल्स द्वारा दृश्यता को कम करने के लिए वैकल्पिक ब्लाइंडिंग
• एन्क्रिप्टेड एकल-कुंजी और कई रद्द करने योग्य कुंजियों दोनों का समर्थन करता है
• आउटप्रॉक्सी, एप्लिकेशन DHT बूटस्ट्रैप, और अन्य उपयोगों के लिए आसान लुकअप के लिए सेवा लुकअप
• 32-बाइट बाइनरी गंतव्य हैश पर निर्भर कुछ भी न तोड़ें, उदाहरण के लिए बिटटॉरेंट
• लीज़सेट्स में लचीलापन जोड़ें गुणों के माध्यम से, जैसे कि हमारे पास राउटरइन्फो में है।
• प्रकाशित टाइमस्टैम्प और चर समाप्ति को हेडर में डालें, ताकि यह तब भी काम करे जब सामग्री एन्क्रिप्टेड हो (सबसे पुराने लीज़ से टाइमस्टैम्प प्राप्त न करें)
• सभी नए प्रकार मौजूदा लीज़सेट्स के समान DHT स्थान और स्थानों में रहते हैं, ताकि उपयोगकर्ता पुराने LS से LS2 में माइग्रेट कर सकें, या LS2, मेटा और एन्क्रिप्टेड के बीच बदल सकें, बिना गंतव्य या हैश को बदले।
• मौजूदा गंतव्य को ऑफ़लाइन कुंजियों का उपयोग करने के लिए परिवर्तित किया जा सकता है, या ऑनलाइन कुंजियों पर वापस, बिना गंतव्य या हैश को बदले।

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

• नया DHT रोटेशन एल्गोरिदम या साझा यादृच्छिक उत्पादन
• नया एन्क्रिप्शन प्रकार और उस नए प्रकार का उपयोग करने के लिए एंड-टू-एंड एन्क्रिप्शन योजना एक अलग प्रस्ताव में होगी। यहां कोई नया क्रिप्टो निर्दिष्ट या चर्चा नहीं किया गया है।
• RIs या टनल निर्माण के लिए नया एन्क्रिप्शन। यह एक अलग प्रस्ताव में होगा।
• I2NP DLM / DSM / DSRM संदेशों के एन्क्रिप्शन, संचरण और प्राप्ति के तरीके। नहीं बदल रहा है।
• मेटा को वास्तव में कैसे उत्पन्न करें और समर्थन करें, जिसमें बैकएंड इंटर-राउटर संचार, प्रबंधन, विफलता के बाद पुनर्स्थापना, और समन्वय शामिल है। समर्थन I2CP, या i2pcontrol, या एक नए प्रोटोकॉल में जोड़ा जा सकता है। यह मानकीकृत हो सकता है या नहीं।
• लंबे समय तक चलने वाले टनल को वास्तव में कैसे लागू और प्रबंधित करें, या मौजूदा टनल को रद्द करें। यह अत्यंत कठिन है, और बिना इसके, आपके पास एक उचित ग्रेसफुल शटडाउन नहीं हो सकता।
• धमकी मॉडल में परिवर्तन
• ऑफ़लाइन भंडारण प्रारूप, या डेटा को संग्रहीत/पुनः प्राप्त/साझा करने के तरीके।
• कार्यान्वयन विवरण यहां चर्चा नहीं किए गए हैं और प्रत्येक परियोजना के लिए छोड़ दिए गए हैं।

औचित्य

LS2 में एन्क्रिप्शन प्रकार बदलने और भविष्य के प्रोटोकॉल परिवर्तनों के लिए फ़ील्ड जोड़ता है।

एन्क्रिप्टेड LS2 मौजूदा एन्क्रिप्टेड LS के कई सुरक्षा मुद्दों को ठीक करता है लीज़ के पूरे सेट के असममित एन्क्रिप्शन का उपयोग करके।

मेटा LS2 लचीला, कुशल, प्रभावी और बड़े पैमाने पर मल्टीहोमिंग प्रदान करता है।

सेवा रिकॉर्ड और सेवा सूची नामकरण लुकअप और DHT बूटस्ट्रैपिंग जैसी एनीकास्ट सेवाएं प्रदान करते हैं।

नेटडीबी डेटा प्रकार

प्रकार संख्याओं का उपयोग I2NP डेटाबेस लुकअप/स्टोर संदेशों में किया जाता है।

एंड-टू-एंड कॉलम इंगित करता है कि क्या प्रश्नोत्तरी/प्रतिक्रियाएं एक गंतव्य को एक गर्लिक संदेश में भेजी जाती हैं।

मौजूदा प्रकार:

नए प्रकार:

टिप्पणियाँ

• लुकअप प्रकार वर्तमान में डेटाबेस लुकअप संदेश में बिट्स 3-2 में हैं। कोई भी अतिरिक्त प्रकार बिट 4 के उपयोग की आवश्यकता होगी।

• पुराने राउटर द्वारा डेटाबेस स्टोर संदेश प्रकार फ़ील्ड में ऊपरी बिट्स को अनदेखा किया जाता है, इसलिए सभी स्टोर प्रकार विषम हैं। हम इसे एक संपीड़ित RI के रूप में नहीं, बल्कि एक LS के रूप में विफल होना पसंद करेंगे।

• क्या प्रकार हस्ताक्षर द्वारा कवर किए गए डेटा में स्पष्ट या अंतर्निहित या न कुछ होना चाहिए?

लुकअप/स्टोर प्रक्रिया

प्रकार 3, 5, और 7 को एक मानक लीज़सेट लुकअप (प्रकार 1) के जवाब में लौटाया जा सकता है।
प्रकार 9 को कभी भी लुकअप के जवाब में नहीं लौटाया जाता है।
प्रकार 11 को एक नए सेवा लुकअप प्रकार (प्रकार 11) के जवाब में लौटाया जाता है।

केवल प्रकार 3 को क्लाइंट-टू-क्लाइंट गर्लिक संदेश में भेजा जा सकता है।

प्रारूप

प्रकार 3, 7, और 9 सभी एक सामान्य प्रारूप का उपयोग करते हैं::

मानक LS2 हेडर

• नीचे परिभाषित के रूप में

प्रकार-विशिष्ट भाग

• नीचे प्रत्येक भाग में परिभाषित के रूप में

मानक LS2 हस्ताक्षर:

• लंबाई हस्ताक्षर प्रकार द्वारा निहित है जो हस्ताक्षर कुंजी का है

प्रकार 5 (एन्क्रिप्टेड) में एक गंतव्य के साथ शुरू नहीं होता है और एक अलग प्रारूप है। नीचे देखें।

प्रकार 11 (सेवा सूची) कई सेवा रिकॉर्ड का एक समूह है और एक अलग प्रारूप है। नीचे देखें।

गोपनीयता/सुरक्षा विचार

TBD

मानक LS2 हेडर

प्रकार 3, 7, और 9 मानक LS2 हेडर का उपयोग करते हैं, नीचे निर्दिष्ट:

प्रारूप

मानक LS2 हेडर:
  - प्रकार (1 बाइट)
    वास्तव में हेडर में नहीं, लेकिन हस्ताक्षर द्वारा कवर किए गए डेटा का हिस्सा।
    डेटाबेस स्टोर संदेश के फ़ील्ड से लें।
  - गंतव्य (387+ बाइट)
  - प्रकाशित टाइमस्टैम्प (4 बाइट, बड़ा एंडियन, एपॉक से सेकंड, 2106 में रोल ओवर)
  - समाप्ति (2 बाइट, बड़ा एंडियन) (प्रकाशित टाइमस्टैम्प से सेकंड में ऑफ़सेट, अधिकतम 18.2 घंटे)
  - झंडे (2 बाइट)
    बिट ऑर्डर: 15 14 ... 3 2 1 0
    बिट 0: यदि 0, कोई ऑफ़लाइन कुंजियां नहीं; यदि 1, ऑफ़लाइन कुंजियां
    बिट 1: यदि 0, एक मानक प्रकाशित लीज़सेट।
           यदि 1, एक अप्रकाशित लीज़सेट। इसे बाढ़, प्रकाशित, या
           क्वेरी के जवाब में नहीं भेजना चाहिए। यदि यह लीज़सेट समाप्त हो जाता है, तो नए के लिए नेटडीबी क्वेरी न करें,
           जब तक बिट 2 सेट नहीं है।
    बिट 2: यदि 0, एक मानक प्रकाशित लीज़सेट।
           यदि 1, यह एन्क्रिप्टेड लीज़सेट प्रकाशित करने पर ब्लाइंड और एन्क्रिप्टेड होगा।
           यदि यह लीज़सेट समाप्त हो जाता है, तो नए के लिए नेटडीबी में ब्लाइंड स्थान क्वेरी करें।
           यदि यह बिट 1 पर सेट है, तो बिट 1 को भी 1 पर सेट करें।
           रिलीज 0.9.42 से।
    बिट्स 3-15: भविष्य के उपयोग के साथ संगतता के लिए 0 पर सेट करें
  - यदि झंडा ऑफ़लाइन कुंजियों को इंगित करता है, तो ऑफ़लाइन हस्ताक्षर खंड:
    समाप्ति टाइमस्टैम्प (4 बाइट, बड़ा एंडियन, एपॉक से सेकंड, 2106 में रोल ओवर)
    अस्थायी हस्ताक्षर प्रकार (2 बाइट, बड़ा एंडियन)
    अस्थायी हस्ताक्षर सार्वजनिक कुंजी (लंबाई हस्ताक्षर प्रकार द्वारा निहित है)
    समाप्ति टाइमस्टैम्प, अस्थायी हस्ताक्षर प्रकार, और सार्वजनिक कुंजी का हस्ताक्षर,
    गंतव्य सार्वजनिक कुंजी द्वारा,
    लंबाई गंतव्य सार्वजनिक कुंजी हस्ताक्षर प्रकार द्वारा निहित है।
    इस खंड को ऑफ़लाइन उत्पन्न किया जा सकता है, और चाहिए।

औचित्य

• अप्रकाशित/प्रकाशित: एंड-टू-एंड डेटाबेस स्टोर भेजते समय उपयोग के लिए, भेजने वाला राउटर इंगित करना चाह सकता है कि इस लीज़सेट को दूसरों को नहीं भेजा जाना चाहिए। हम वर्तमान में इस स्थिति को बनाए रखने के लिए ह्यूरिस्टिक्स का उपयोग करते हैं।

• प्रकाशित: लीज़सेट के ‘संस्करण’ को निर्धारित करने के लिए आवश्यक जटिल तर्क को बदलता है। वर्तमान में, संस्करण अंतिम-समाप्ति लीज़ की समाप्ति है, और एक प्रकाशन राउटर को कम से कम 1ms तक बढ़ाना होगा जब एक लीज़सेट प्रकाशित करते हैं जो केवल एक पुरानी लीज़ को हटाता है।

• समाप्ति: नेटडीबी प्रविष्टि के लिए एक समाप्ति की अनुमति देता है जो इसकी अंतिम-समाप्ति लीज़सेट से पहले हो। LS2 के लिए उपयोगी नहीं हो सकता है, जहां लीज़सेट को 11 मिनट की अधिकतम समाप्ति के साथ रहने की उम्मीद है, लेकिन अन्य नए प्रकारों के लिए, यह आवश्यक है (नीचे मेटा LS और सेवा रिकॉर्ड देखें)।

• ऑफ़लाइन कुंजियां वैकल्पिक हैं, प्रारंभिक/आवश्यक कार्यान्वयन जटिलता को कम करने के लिए।

मुद्दे

• टाइमस्टैम्प सटीकता को और अधिक कम किया जा सकता है (10 मिनट?) लेकिन संस्करण संख्या जोड़नी होगी। यह मल्टीहोमिंग को तोड़ सकता है, जब तक कि हमारे पास क्रम संरक्षित एन्क्रिप्शन नहीं है? शायद बिना टाइमस्टैम्प के नहीं किया जा सकता।

• वैकल्पिक: 3 बाइट टाइमस्टैम्प (एपॉक / 10 मिनट), 1-बाइट संस्करण, 2-बाइट समाप्ति

• क्या प्रकार डेटा / हस्ताक्षर में स्पष्ट या अंतर्निहित है? हस्ताक्षर के लिए “डोमेन” स्थिरांक?

टिप्पणियाँ

• राउटर को एक सेकंड से अधिक बार एक LS प्रकाशित नहीं करना चाहिए। यदि वे करते हैं, तो उन्हें पिछले प्रकाशित LS पर 1 अधिक कृत्रिम रूप से प्रकाशित टाइमस्टैम्प बढ़ाना चाहिए।

• राउटर कार्यान्वयन अस्थायी कुंजियों और हस्ताक्षर को कैश कर सकते हैं ताकि हर बार सत्यापन से बचा जा सके। विशेष रूप से, फ्लडफिल्स, और लंबे समय तक चलने वाले कनेक्शन के दोनों छोर पर राउटर, इससे लाभान्वित हो सकते हैं।

• ऑफ़लाइन कुंजियां और हस्ताक्षर केवल लंबे समय तक चलने वाले गंतव्यों के लिए उपयुक्त हैं, यानी सर्वर, क्लाइंट नहीं।

नए DatabaseEntry प्रकार

लीज़सेट 2

मौजूदा लीज़सेट से परिवर्तन:

• प्रकाशित टाइमस्टैम्प, समाप्ति टाइमस्टैम्प, झंडे, और गुण जोड़ें
• एन्क्रिप्शन प्रकार जोड़ें
• रद्दीकरण कुंजी हटाएं

लुकअप के साथ मानक LS झंडा (1) स्टोर के साथ मानक LS2 प्रकार (3) पर संग्रहीत करें गंतव्य का हैश इस हैश का उपयोग फिर से दैनिक “रूटिंग कुंजी” उत्पन्न करने के लिए किया जाता है, जैसा कि LS1 में सामान्य समाप्ति 10 मिनट, एक नियमित LS की तरह। द्वारा प्रकाशित गंतव्य

प्रारूप

ऊपर निर्दिष्ट मानक LS2 हेडर

  मानक LS2 प्रकार-विशिष्ट भाग
  - गुण (सामान्य संरचनाएँ विनिर्देश में निर्दिष्ट मैपिंग के रूप में, कोई नहीं होने पर 2 शून्य बाइट)
  - अनुसरण करने वाले कुंजी खंडों की संख्या (1 बाइट, अधिकतम TBD)
  - कुंजी खंड:
    - एन्क्रिप्शन प्रकार (2 बाइट, बड़ा एंडियन)
    - एन्क्रिप्शन कुंजी लंबाई (2 बाइट, बड़ा एंडियन)
      यह स्पष्ट है, ताकि फ्लडफिल्स अज्ञात एन्क्रिप्शन प्रकारों के साथ LS2 को पार्स कर सकें।
    - एन्क्रिप्शन कुंजी (निर्दिष्ट बाइट की संख्या)
  - लीज़2 की संख्या (1 बाइट)
  - लीज़2 (प्रत्येक 40 बाइट)
    ये लीज़ हैं, लेकिन 8-बाइट के बजाय 4-बाइट समाप्ति के साथ,
    एपॉक से सेकंड (2106 में रोल ओवर)

  मानक LS2 हस्ताक्षर:
  - हस्ताक्षर
    यदि झंडा ऑफ़लाइन कुंजियों को इंगित करता है, तो यह अस्थायी पब्लिककी द्वारा हस्ताक्षरित है,
    अन्यथा, गंतव्य पब्लिककी द्वारा
    लंबाई हस्ताक्षर कुंजी के हस्ताक्षर प्रकार द्वारा निहित है
    हस्ताक्षर ऊपर के सब कुछ का है।

औचित्य

• गुण: भविष्य के विस्तार और लचीलापन। शेष डेटा के पार्स करने के लिए आवश्यक होने की स्थिति में पहले रखा गया।

• एक नए एन्क्रिप्शन प्रकार में संक्रमण को आसान बनाने के लिए एकाधिक एन्क्रिप्शन प्रकार/सार्वजनिक कुंजी जोड़े हैं। इसे करने का दूसरा तरीका है कई लीज़सेट प्रकाशित करना, संभवतः समान टनल का उपयोग करके, जैसा कि हम अब DSA और EdDSA गंतव्यों के लिए करते हैं। टनल पर आने वाले एन्क्रिप्शन प्रकार की पहचान मौजूदा सत्र टैग तंत्र के साथ की जा सकती है, और/या प्रत्येक कुंजी का प्रयास डिक्रिप्शन करके। आने वाले संदेशों की लंबाई भी एक संकेत दे सकती है।

चर्चा

यह प्रस्ताव अंत-से-अंत एन्क्रिप्शन कुंजी के लिए लीज़सेट में सार्वजनिक कुंजी का उपयोग जारी रखता है, और गंतव्य में सार्वजनिक कुंजी फ़ील्ड को अब की तरह अनुपयोग में छोड़ देता है। एन्क्रिप्शन प्रकार गंतव्य कुंजी प्रमाणपत्र में निर्दिष्ट नहीं है, यह 0 रहेगा।

एक अस्वीकृत वैकल्पिक विकल्प गंतव्य कुंजी प्रमाणपत्र में एन्क्रिप्शन प्रकार निर्दिष्ट करना है, गंतव्य में सार्वजनिक कुंजी का उपयोग करना, और लीज़सेट में सार्वजनिक कुंजी का उपयोग नहीं करना। हम ऐसा करने की योजना नहीं बना रहे हैं।

LS2 के लाभ:

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

LS2 के नुकसान:

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

नए एन्क्रिप्शन मुद्दे

इनमें से कुछ इस प्रस्ताव के लिए बाहर के क्षेत्र में हैं,
लेकिन अभी के लिए यहां नोट्स डाल रहे हैं क्योंकि हमारे पास
अभी तक एक अलग एन्क्रिप्शन प्रस्ताव नहीं है।
ECIES प्रस्ताव 144 और 145 भी देखें।

• एन्क्रिप्शन प्रकार संयोजन का प्रतिनिधित्व करता है
  वक्र, कुंजी लंबाई, और एंड-टू-एंड योजना,
  KDF और MAC सहित, यदि कोई है।

• हमने एक कुंजी लंबाई फ़ील्ड शामिल किया है, ताकि LS2
  अज्ञात एन्क्रिप्शन प्रकारों के लिए भी फ्लडफिल द्वारा पार्स करने योग्य और सत्यापित करने योग्य हो।

• प्रस्तावित किया जाने वाला पहला नया एन्क्रिप्शन प्रकार
  शायद ECIES/X25519 होगा। यह कैसे उपयोग किया जाता है एंड-टू-एंड
  (या तो ElGamal/AES+SessionTag का थोड़ा संशोधित संस्करण
  या कुछ पूरी तरह से नया, उदाहरण के लिए, ChaCha/Poly) एक या अधिक अलग प्रस्तावों में निर्दिष्ट किया जाएगा।
  ECIES प्रस्ताव 144 और 145 भी देखें।

टिप्पणियाँ

• लीज़ में 8-बाइट समाप्ति 4 बाइट में बदल गई है।

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

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

एन्क्रिप्टेड LS2

लक्ष्य:

• ब्लाइंडिंग जोड़ें
• एकाधिक हस्ताक्षर प्रकारों की अनुमति दें
• कोई नया क्रिप्टो प्राथमिक आवश्यक नहीं
• वैकल्पिक रूप से प्रत्येक प्राप्तकर्ता के लिए एन्क्रिप्ट करें, रद्द करने योग्य
• केवल मानक LS2 और मेटा LS2 के एन्क्रिप्शन का समर्थन करें

एन्क्रिप्टेड LS2 को कभी भी एंड-टू-एंड गर्लिक संदेश में नहीं भेजा जाता है। ऊपर की तरह मानक LS2 का उपयोग करें।

मौजूदा एन्क्रिप्टेड लीज़सेट से परिवर्तन:

• सुरक्षा के लिए पूरी चीज को एन्क्रिप्ट करें
• केवल AES के साथ नहीं, सुरक्षित रूप से एन्क्रिप्ट करें
• प्रत्येक प्राप्तकर्ता के लिए एन्क्रिप्ट करें

लुकअप के साथ मानक LS झंडा (1) स्टोर के साथ एन्क्रिप्टेड LS2 प्रकार (5) पर संग्रहीत करें ब्लाइंडेड हस्ताक्षर प्रकार और ब्लाइंडेड सार्वजनिक कुंजी का हैश दो बाइट हस्ताक्षर प्रकार (बड़ा एंडियन, उदाहरण के लिए 0x000b) || ब्लाइंडेड सार्वजनिक कुंजी इस हैश का उपयोग फिर से दैनिक “रूटिंग कुंजी” उत्पन्न करने के लिए किया जाता है, जैसा कि LS1 में सामान्य समाप्ति 10 मिनट, एक नियमित LS की तरह, या घंटे, एक मेटा LS की तरह। द्वारा प्रकाशित गंतव्य

परिभाषाएँ

हम एन्क्रिप्टेड LS2 के लिए उपयोग किए जाने वाले क्रिप्टोग्राफिक बिल्डिंग ब्लॉक्स के अनुरूप निम्नलिखित फ़ंक्शन परिभाषित करते हैं:

CSRNG(n) एक क्रिप्टोग्राफिक-सुरक्षित यादृच्छिक संख्या जनरेटर से n-बाइट आउटपुट।

CSRNG के क्रिप्टोग्राफिक-सुरक्षित होने की आवश्यकता के अलावा (और इसलिए कुंजी सामग्री उत्पन्न करने के लिए उपयुक्त), यह सुरक्षित होना चाहिए कि कुछ n-बाइट आउटपुट का उपयोग कुंजी सामग्री के लिए किया जाए जब तुरंत पहले और बाद के बाइट अनुक्रम नेटवर्क पर उजागर हों (जैसे नमक में, या एन्क्रिप्टेड पैडिंग में)। अविश्वसनीय स्रोत पर निर्भर करने वाले कार्यान्वयन को नेटवर्क पर उजागर किए जाने वाले किसी भी आउटपुट को हैश करना चाहिए। [PRNG संदर्भ](http://projectbullrun.org/dual-ec/ext-rand.html) और [टॉर डेव चर्चा](https://lists.torproject.org/pipermail/tor-dev/2015-November/009954.html) देखें।

H(p, d) वैयक्तिकरण स्ट्रिंग p और डेटा d लेने वाला SHA-256 हैश फ़ंक्शन, और 32 बाइट का आउटपुट उत्पन्न करना।

SHA-256 का उपयोग निम्नलिखित तरीके से करें::

    H(p, d) := SHA-256(p || d)

STREAM RFC 7539 अनुभाग 2.4 में निर्दिष्ट चाचा20 स्ट्रीम सिफर, प्रारंभिक काउंटर के साथ 1 पर सेट। S_KEY_LEN = 32 और S_IV_LEN = 12।

ENCRYPT(k, iv, plaintext)
    सिफर कुंजी k और नोन्स iv का उपयोग करके प्लेनटेक्स्ट को एन्क्रिप्ट करता है जो कुंजी k के लिए अद्वितीय होना चाहिए। प्लेनटेक्स्ट के समान आकार का एक साइफरटेक्स्ट लौटाता है।

    पूरे साइफरटेक्स्ट को यादृच्छिक के समान अभेद्य होना चाहिए यदि कुंजी गुप्त है।

DECRYPT(k, iv, ciphertext)
    सिफर कुंजी k और नोन्स iv का उपयोग करके साइफरटेक्स्ट को डिक्रिप्ट करता है। प्लेनटेक्स्ट लौटाता है।

SIG RedDSA हस्ताक्षर योजना (हस्ताक्षर प्रकार 11 के अनुरूप) कुंजी ब्लाइंडिंग के साथ। इसमें निम्नलिखित फ़ंक्शन हैं:

DERIVE_PUBLIC(privkey)
    दिए गए निजी कुंजी के अनुरूप सार्वजनिक कुंजी लौटाता है।

SIGN(privkey, m)
    दिए गए संदेश m पर निजी कुंजी privkey द्वारा एक हस्ताक्षर लौटाता है।

VERIFY(pubkey, m, sig)
    सार्वजनिक कुंजी pubkey और संदेश m के खिलाफ हस्ताक्षर sig को सत्यापित करता है। हस्ताक्षर मान्य है तो सत्य लौटाता है, अन्यथा गलत।

यह निम्नलिखित कुंजी ब्लाइंडिंग संचालन का समर्थन करना चाहिए:

GENERATE_ALPHA(data, secret)
    उन लोगों के लिए अल्फा उत्पन्न करता है जो डेटा और एक वैकल्पिक गुप्त जानते हैं। परिणाम निजी कुंजियों के रूप में समान रूप से वितरित होना चाहिए।

BLIND_PRIVKEY(privkey, alpha)
    एक गुप्त अल्फा का उपयोग करके एक निजी कुंजी को ब्लाइंड करता है।

BLIND_PUBKEY(pubkey, alpha)
    एक गुप्त अल्फा का उपयोग करके एक सार्वजनिक कुंजी को ब्लाइंड करता है। एक दिए गए कुंजी जोड़ी (privkey, pubkey) के लिए निम्नलिखित संबंध होता है::

        BLIND_PUBKEY(pubkey, alpha) ==
        DERIVE_PUBLIC(BLIND_PRIVKEY(privkey, alpha))

DH X25519 सार्वजनिक कुंजी समझौता प्रणाली। 32 बाइट की निजी कुंजियां, 32 बाइट की सार्वजनिक कुंजियां, 32 बाइट के आउटपुट उत्पन्न करता है। इसमें निम्नलिखित फ़ंक्शन हैं:

GENERATE_PRIVATE()
    एक नई निजी कुंजी उत्पन्न करता है।

DERIVE_PUBLIC(privkey)
    दिए गए निजी कुंजी के अनुरूप सार्वजनिक कुंजी लौटाता है।

DH(privkey, pubkey)
    दिए गए निजी और सार्वजनिक कुंजियों से एक साझा गुप्त उत्पन्न करता है।

HKDF(salt, ikm, info, n) एक क्रिप्टोग्राफिक कुंजी व्युत्पन्न फ़ंक्शन जो कुछ इनपुट कुंजी सामग्री ikm (जिसमें अच्छी एंट्रॉपी होनी चाहिए लेकिन एक समान यादृच्छिक स्ट्रिंग होने की आवश्यकता नहीं है), 32