Status
0.9.57 में लागू किया गया। इस प्रस्ताव को खुला छोड़ा जा रहा है ताकि हम “भविष्य की योजना” अनुभाग में विचारों को बढ़ा सकें और चर्चा कर सकें।
अवलोकन
सारांश
ElGamal सार्वजनिक कुंजी Destinations में रिलीज़ 0.6 (2005) के बाद से अप्रयुक्त है। हालांकि हमारी विनिर्देशों में यह कहा गया है कि यह अप्रयुक्त है, वे यह नहीं कहते कि कार्यान्वयन ElGamal कुंजी जोड़ी को उत्पन्न करने से बच सकते हैं और बस फ़ील्ड को यादृच्छिक डेटा से भर सकते हैं।
हम प्रस्ताव करते हैं कि विनिर्देशों को यह कहने के लिए बदला जाए कि फ़ील्ड को अनदेखा किया जाता है और कार्यान्वयन इस फ़ील्ड को यादृच्छिक डेटा से भर सकते हैं। यह बदलाव पिछली संगतता के लिए है। ElGamal सार्वजनिक कुंजी को सत्यापित करने वाली कोई ज्ञात कार्यान्वयन नहीं है।
इसके अलावा, यह प्रस्ताव कार्यान्वायकों को मार्गदर्शन प्रदान करता है कि Destination और Router Identity padding के लिए यादृच्छिक डेटा कैसे उत्पन्न किया जाए ताकि यह संपीड़नीय हो और फिर भी सुरक्षित हो, और बिना किसी आधार 64 प्रस्तुतियों को भ्रष्ट या असुरक्षित दिखाना पड़े। यह बिना किसी विघटनकारी प्रोटोकॉल परिवर्तन के padding फ़ील्ड को हटाने के अधिकांश लाभ प्रदान करता है। संपीड़नीय Destinations स्ट्रीमिंग SYN और प्रतिफलित डेटाग्राम आकार को कम करते हैं; संपीड़नीय Router Identities Database Store Messages, SSU2 Session Confirmed संदेशों, और reseed su3 फाइलों को कम करते हैं।
अंत में, प्रस्ताव नए Destination और Router Identity स्वरूपों की संभावनाओं पर चर्चा करता है जो padding को पूरी तरह से समाप्त कर सकते हैं। यहां पर पोस्ट-क्वांटम क्रिप्टो और भविष्य की योजना पर कैसे प्रभाव डाल सकता है इसपर भी एक संक्षिप्त चर्चा है।
लक्ष्य
- Destinations के लिए ElGamal कुंजी जोड़ी उत्पन्न करने की आवश्यकता को समाप्त करना
- सर्वोत्तम प्रथाओं की सिफारिश करते हैं ताकि Destinations और Router Identities अत्यधिक संपीड़नीय हों, फिर भी Base 64 प्रस्तुतियों में स्पष्ट पैटर्न न दिखाएं।
- सभी कार्यान्वयनों द्वारा सर्वोत्तम प्रथाओं को अपनाने के लिए प्रोत्साहित करना ताकि फ़ील्ड्स को अलग नहीं किया जा सके
- स्ट्रीमिंग SYN आकार को कम करें
- प्रतिफलित डेटाग्राम आकार को कम करें
- SSU2 RI ब्लॉक आकार को कम करें
- SSU2 Session को Confirms आकार और खंडित आवृत्ति को कम करें
- Database Store Message (RI के साथ) आकार को कम करें
- पुनः प्रोग्राम फ़ाइल आकार को कम करें
- सभी प्रोटोकॉल और एपीआई में संगतता बनाए रखना
- विनिर्देशों को अद्यतन करें
- नए Destination और Router Identity स्वरूपों के लिए विकल्पों पर चर्चा करें
ElGamal कुंजियों को उत्पन्न करने की आवश्यकता को समाप्त करके, कार्यान्वयन ElGamal कोड को पूरी तरह से निकालने में सक्षम हो सकते हैं, बाकी प्रोटोकॉल के पिछली संगतता विचारों के अधीन।
डिज़ाइन
सख्ती से बोलते हुए, 32-बाइट हस्ताक्षर सार्वजनिक कुंजी अकेले (गंतव्यों और राउटर पहचान में दोनों) और 32-बाइट एन्क्रिप्शन सार्वजनिक कुंजी (केवल राउटर पहचान में) एक यादृच्छिक संख्या है जो इन संरचनाओं के SHA-256 हैश के लिए आवश्यक सभी एंट्रॉपी प्रदान करती है ताकि वे क्रिप्टोग्राफिक रूप से मजबूत और नेटवर्क डेटाबेस DHT में यादृच्छिक रूप से वितरित हों।
हालांकि, अत्यधिक सावधानी के कारण, हम ElG सार्वजनिक कुंजी फ़ील्ड और padding में न्यूनतम 32 बाइट्स का रैंडम डेटा उपयोग करने की सिफारिश करते हैं। इसके अलावा, अगर सभी फ़ील्ड्स जीरो थे, तो Base 64 गंतव्य में AAAA वर्णों की लंबी श्रृंखलाएं होतीं, जो उपयोगकर्ताओं को अलार्म या भ्रम पैदा कर सकती हैं।
Ed25519 हस्ताक्षर प्रकार और X25519 एन्क्रिप्शन प्रकार के लिए: गंतव्य में रैंडम डाटा की 11 कॉपियाँ (352 बाइट्स) होंगी। Router Identities में रैंडम डाटा की 10 कॉपियाँ (320 बाइट्स) होंगी।
अनुमानित बचत
Destinations प्रत्येक स्ट्रीमिंग SYN और प्रतिफलित डेटाग्राम में शामिल होते हैं। Router Infos (जिसमें Router Identities शामिल हैं) Database Store Messages में शामिल होती हैं और NTCP2 और SSU2 में Session Confirmed संदेशों में शामिल होती हैं।
NTCP2 Router Info को संपीड़ित नहीं करता है। Database Store Messages में SSU2 Session Confirmed संदेशों में RIs को gzip किया जाता है। Router Infos को reseed SU3 फाइलों में ज़िप किया गया है।
Database Store Messages में Destinations संपीड़ित नहीं होती हैं। Streaming SYN संदेश I2CP स्तर पर gzip किए जाते हैं।
Ed25519 हस्ताक्षर प्रकार और X25519 एन्क्रिप्शन प्रकार के लिए, अनुमानित बचत:
| डेटा प्रकार | कुल आकार | कीज़ और सर्ट | असंपीड़ित Padding | संपीड़ित Padding | आकार | बचत |
|---|---|---|---|---|---|---|
| Destination | 391 | 39 | 352 | 32 | 71 | 320 बाइट्स (82%) |
| Router Identity | 391 | 71 | 320 | 32 | 103 | 288 बाइट्स (74%) |
| Router Info | 1000 typ. | 71 | 320 | 32 | 722 typ. | 288 बाइट्स (29%) |
नोट्स: मान लें कि 7-बाइट प्रमाणपत्र असंपीड़ित है, शून्य अतिरिक्त gzip ओवरहेड। दोनों सत्य नहीं हैं, लेकिन प्रभाव छोटे होंगे। Router Info के अन्य संपीड़नीय भागों को अनदेखा करें।
विनिर्देश
हमारे वर्तमान विनिर्देशों में प्रस्तावित बदलाव नीचे दस्तावेजित हैं।
सामान्य संरचनाएं
सामान्य संरचनाओं विनिर्देश को बदलें ताकि 256-बाइट Destination सार्वजनिक कुंजी फ़ील्ड को अनदेखा करने और यादृच्छिक डेटा शामिल करने की अनुमति दे।
सामान्य संरचना विनिर्देश में एक अनुभाग जोड़ें Destination सार्वजनिक कुंजी फ़ील्ड और गंतव्य और राउटर पहचान में padding फ़ील्ड के लिए सर्वोत्तम अभ्यास की सिफारिश करने के लिए, निम्नलिखित के रूप में:
32 बाइट्स की रैंडम डेटा उत्पन्न करें, एक मजबूत क्रिप्टोग्राफिक छद्म-यादृच्छिक संख्या जनरेटर (PRNG) का उपयोग करके और सार्वजनिक कुंजी फ़ील्ड (Destination के लिए) को पूर्ण करने के लिए आवश्यकतानुसार उन 32 बाइट्स को दोहराएं और padding फ़ील्ड (Destination और Router Identities के लिए)।
Private Key File
निजी कुंजी फ़ाइल (eepPriv.dat) प्रारूप हमारे विनिर्देशों का एक आधिकारिक भाग नहीं है लेकिन यह Java I2P javadocs में दस्तावेज किया गया है और अन्य कार्यान्वयन इसे समर्थन करते हैं। यह विभिन्न कार्यान्वयनों के लिए निजी कुंजियों के पोर्टेबिलिटी की अनुमति देता है। उस जवादॉक पर एक नोट जोड़ें कि एन्क्रिप्शन सार्वजनिक कुंजी और एन्क्रिप्शन निजी कुंजी सभी शून्य या रेंडम डेटा हो सकते हैं।
SAM
SAM विनिर्देश में यह नोट करें कि एन्क्रिप्शन निजी कुंजी अप्रयुक्त है और इसे अनदेखा किया जा सकता है। कोई भी यादृच्छिक डेटा क्लाइंट द्वारा लौटाया जा सकता है। SAM ब्रिज निर्माण पर (DEST GENERATE या SESSION CREATE DESTINATION=TRANSIENT के साथ) सभी शून्य की बजाय यादृच्छिक डेटा भेज सकता है, ताकि Base 64 प्रतिनिधित्व में AAAA वर्णों की एक स्ट्रिंग न हो और टूटा न दिखे।
I2CP
I2CP में कोई बदलाव आवश्यक नहीं है। गंतव्य में एन्क्रिप्शन सार्वजनिक कुंजी के लिए निजी कुंजी राउटर को नहीं भेजी जाती है।
भविष्य की योजनाएं
प्रोटोकॉल बदलाव
प्रोटोकॉल बदलाव की लागत पर और पिछड़ी संगतता की कमी के साथ, हम हमारे प्रोटोकॉल और विनिर्देशों को बदल सकते हैं गंतव्य, राउटर पहचान, या दोनों में padding फ़ील्ड को समाप्त करें।
यह प्रस्ताव “b33” एन्क्रिप्टेड लीसेसेट प्रारूप के समानता से कुछ समानता रखता है, जिसमें केवल एक कुंजी और एक प्रकार का फ़ील्ड शामिल है।
कुछ संगतता बनाए रखने के लिए, कुछ प्रोटोकॉल परतें padding फ़ील्ड को सभी शून्यों के साथ “विस्तारित” कर सकती हैं अन्य प्रोटोकॉल परतों को प्रस्तुत करने के लिए।
गंतव्यों के लिए, हम कुंजी प्रमाणपत्र में एन्क्रिप्शन प्रकार फ़ील्ड को भी हटा सकते हैं, दो बाइट्स की बचत पर। वैकल्पिक रूप से, गंतव्य में एक नया एन्क्रिप्शन प्रकार कुंजी प्रमाणपत्र में प्राप्त कर सकते हैं, शून्य सार्वजनिक कुंजी (और padding) को इंगित करते हुए।
यदि पुराने और नए स्वरूपों के बीच संगतता परिवर्तन कुछ प्रोटोकॉल स्तर पर शामिल नहीं है, तो निम्नलिखित विनिर्देशों, एपीआई, प्रोटोकॉल, और अनुप्रयोग प्रभावित होंगे:
- सामान्य संरचनाएं विनिर्देश
- I2NP
- I2CP
- NTCP2
- SSU2
- Ratchet
- स्ट्रीमिंग
- SAM
- बिटटोरेंट
- रिसीडिंग
- निजी कुंजी फ़ाइल
- Java कोर और राउटर एपीआई
- i2pd API
- तृतीय-पक्ष SAM पुस्तकालय
- बंडल और तृतीय-पक्ष उपकरण
- कई Java प्लगइन्स
- उपयोगकर्ता इंटरफेस
- P2P अनुप्रयोग उदाहरण के लिए MuWire, बिटकॉइन, मोनेरो
- hosts.txt, पता पुस्तक, और सदस्यताएं
यदि रूपांतरण को किसी परत पर निर्दिष्ट किया गया है, तो सूची कम होगी।
इन परिवर्तनों की लागत और लाभ स्पष्ट नहीं हैं।
विशिष्ट प्रस्तावों का TBD:
पीक्यू कीज़
पोस्ट-क्वांटम (PQ) एन्क्रिप्शन सार्वजनिक कुंजियाँ, किसी भी पूर्वानुमानित एल्गोरिदम के लिए, 256 बाइट्स से बड़ी होती हैं। इससे किसी भी padding और प्रस्तावित परिवर्तनों से प्राप्त किसी भी बचत को समाप्त कर दिया जाएगा, Router Identities के लिए।
एक “हाइब्रिड” PQ दृष्टिकोण में, जैसे कि SSL कर रहा है, PQ कुंजियाँ केवल अस्थायी होंगी, और राउटर पहचान में प्रकट नहीं होंगी।
PQ हस्ताक्षर कुंजियाँ संभव नहीं हैं, और Destinations एन्क्रिप्शन सार्वजनिक कुंजियों को सम्मिलित नहीं करता है। रेटचेट के लिए स्थिर कुंजियाँ लीसे सेट में होती हैं, गंतव्य में नहीं। इसलिए हम गंतव्यों को निम्नलिखित चर्चा से समाप्त कर सकते हैं।
तो PQ केवल Router Infos को प्रभावित करता है, और केवल PQ स्थिर (अस्थायी नहीं) कुंजियों के लिए, PQ हाइब्रिड के लिए नहीं। यह एक नए एन्क्रिप्शन प्रकार के लिए है और NTCP2, SSU2, और एन्क्रिप्टेड डेटाबेस लुकअप संदेशों और जवाबों को प्रभावित करेगा। डिज़ाइन, विकास, और रोलआउट के लिए अनुमानित समय सीमा ???????????? लेकिन हाइब्रिड या रेटचेट ??????? के बाद होगी?
अधिक चर्चा के लिए देखें this topic।
मुद्दे
यह नेटवर्क को धीरे-धीरे पुनः कुंजी करने के लिए वांछनीय हो सकता है, ताकि नए राउटर के लिए कवर प्रदान किया जा सके। “पुनः कुंजीकरण” का अर्थ केवल padding को बदलना हो सकता है, वास्तव में कुंजियाँ बदलना नहीं।
विद्यमान गंतव्यों को पुनः कुंजी करना संभव नहीं है।
क्या सार्वजनिक कुंजी फ़ील्ड में padding के साथ Router Identities को एक अलग एन्क्रिप्शन प्रकार से कुंजी प्रमाणपत्र में पहचाना जाना चाहिए? यह संगतता मुद्दों का कारण बनेगा।
प्रवास
ElGamal कुंजी के साथ padding को बदलने के लिए पिछला संगतता मुद्दा नहीं है।
पुनः कुंजीकरण, यदि लागू किया गया, तो यह पिछले तीन राउटर पहचान संक्रमणों के समान होगा: DSA-SHA1 से ECDSA हस्ताक्षरों के लिए, फिर EdDSA हस्ताक्षरों के लिए, फिर X25519 एन्क्रिप्शन के लिए।
पिछली संगतता मुद्दों के अधीन, और SSU को अक्षम करने के बाद, कार्यान्वयन ElGamal कोड को पूरी तरह से निकाल सकते हैं। नेटवर्क में लगभग 14% राउटर ElGamal एन्क्रिप्शन प्रकार के हैं, जिनमें कई फ्लडफ़िल्स शामिल हैं।
Java I2P के लिए एक ड्राफ्ट मर्ज अनुरोध git.idk.i2p में है।