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