स्थिति
2025-04-15 को समीक्षा में स्वीकृत। विशेषताओं में परिवर्तन समाहित किए गए। Java I2P में लागू किया गया API 0.9.66 के अनुसार। स्थिति के लिए कार्यान्वयन दस्तावेज़ीकरण की जांच करें।
अवलोकन
Prop123 से एक अलग प्रस्ताव के रूप में खींचा गया।
ऑफलाइन हस्ताक्षर सत्यापित नहीं किए जा सकते हैं प्रत्युत्तर योग्य डाटाग्राम प्रसंस्करण में। ऑफलाइन हस्ताक्षरित संकेत करने के लिए एक ध्वज की आवश्यकता है लेकिन ध्वज रखने के लिए कोई जगह नहीं है।
इसके लिए एक पूरी तरह से नया I2CP प्रोटोकॉल नंबर और प्रारूप की आवश्यकता होगी, जिसे DATAGRAMS विशेषता में जोड़ा जाएगा। इसे “डाटाग्राम2” कहते हैं।
लक्ष्य
- ऑफलाइन हस्ताक्षरों के लिए समर्थन जोड़ें
- प्रत्युत्तरण प्रतिरोध जोड़ें
- बिना हस्ताक्षरों के फ्लेवर जोड़ें
- विस्तारशीलता के लिए ध्वज और विकल्प क्षेत्र जोड़ें
गैर-लक्ष्य
संपूर्ण प्रोटोकॉल सपोर्ट जैसे अधिक भीड़ नियंत्रण आदि। यह डाटाग्राम2 के ऊपर निर्माण होगा, या इसका विकल्प होगा, जो एक निम्न-स्तरीय प्रोटोकॉल है। यह केवल डाटाग्राम2 के शीर्ष पर एक उच्च-प्रदर्शन प्रोटोकॉल डिजाइन करने का कोई मतलब नहीं होगा, क्योंकि से प्रेषक फ़ील्ड और हस्ताक्षर का भार। ऐसे किसी भी प्रोटोकॉल को डाटाग्राम2 के साथ एक प्रारंभिक हैंडशेक करना चाहिए और फिर कच्चे डाटाग्राम्स पर स्विच करना चाहिए।
प्रेरणा
2019 में अन्यथा पूर्ण हो चुके LS2 कार्य से बचा हुआ।
डाटाग्राम2 का उपयोग करने वाला पहला अनुप्रयोग बिटटोरेंट UDP घोषणाएं होने की उम्मीद है, जैसा कि i2psnark और zzzot में लागू किया गया है, देखें Prop160।
प्रत्युत्तर योग्य डाटाग्राम विशेषता
संदर्भ के लिए, नीचे प्रत्युत्तर योग्य डाटाग्राम्स के विशिष्ट अवलोकन की समीक्षा है, जो Datagrams से कॉपी की गई है। प्रत्युत्तर योग्य डाटाग्राम के लिए मानक I2CP प्रोटोकॉल संख्या PROTO_DATAGRAM (17) है।
+----+----+----+----+----+----+----+----+
| from |
+ +
| |
~ ~
~ ~
| |
+ +
| |
| |
+----+----+----+----+----+----+----+----+
| signature |
+ +
| |
+ +
| |
+ +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
| payload...
+----+----+----+----//
from :: एक `Destination`
लंबाई: 387+ बाइट्स
डाटाग्राम का उत्प्रेषक और हस्ताक्षरक
signature :: एक `Signature`
हस्ताक्षर प्रकार को $from के हस्ताक्षरकारी सार्वजनिक कुंजी प्रकार से मेल खाना चाहिए
लंबाई: 40+ बाइट्स, जैसा कि हस्ताक्षर प्रकार द्वारा संकेतित।
डिफ़ॉल्ट DSA_SHA1 कुंजी प्रकार के लिए:
पेलोड के SHA-256 हैश का DSA `Signature`।
अन्य कुंजी प्रकारों के लिए:
पेलोड का `Signature`।
हस्ताक्षर को $from की हस्ताक्षरकारी सार्वजनिक कुंजी द्वारा सत्यापित किया जा सकता है
payload :: डेटा
लंबाई: 0 से लगभग 31.5 KB (नोट्स देखें)
कुल लंबाई: पेलोड लंबाई + 423+
डिज़ाइन
- एक नया प्रोटोकॉल 19 परिभाषित करें - विकल्पों के साथ प्रत्युत्तर योग्य डाटाग्राम।
- एक नया प्रोटोकॉल 20 परिभाषित करें - बिना हस्ताक्षर के प्रत्युत्तर योग्य डाटाग्राम।
- ऑफलाइन हस्ताक्षरों और भविष्य के विस्तार के लिए ध्वज क्षेत्र जोड़ें
- आसान प्रसंस्करण के लिए पेलोड के बाद हस्ताक्षर को स्थानांतरित करें
- नए हस्ताक्षर विनिर्देशों को प्रत्युत्तर योग्य डाटाग्राम या स्ट्रीमिंग से भिन्न बनाएं, ताकि हस्ताक्षर सत्यापन विफल होगा यदि इसे प्रत्युत्तर योग्य डाटाग्राम या स्ट्रीमिंग के रूप में व्याख्यायित किया जाता है। यह पेलोड के बाद हस्ताक्षर को स्थानांतरित करके, और हस्ताक्षर फ़ंक्शन में गंतव्य हैश को शामिल करके पूरा किया जाता है।
- डाटाग्राम के लिए प्रत्युत्तरण रोकथाम जोड़ें, जैसा कि Prop164 में स्ट्रीमिंग के लिए किया गया था।
- मनमाने विकल्पों के लिए सेक्शन जोड़ें
- ऑफलाइन हस्ताक्षर प्रारूप को Common और Streaming से पुनः उपयोग करें।
- ऑफलाइन हस्ताक्षर सेक्शन को परिवर्तनशील लंबाई पेलोड और हस्ताक्षर अनुभागों से पहले होना चाहिए, क्योंकि यह हस्ताक्षर की लंबाई निर्दिष्ट करता है।
विनिर्देश
प्रोटोकॉल
डाटाग्राम2 के लिए नया I2CP प्रोटोकॉल नंबर 19 है। I2CP के तहत इसे PROTO_DATAGRAM2 के रूप में जोड़ें।
डाटाग्राम3 के लिए नया I2CP प्रोटोकॉल नंबर 20 है। I2CP के तहत इसे PROTO_DATAGRAM2 के रूप में जोड़ें।
डाटाग्राम2 प्रारूप
डाटाग्राम2 को DATAGRAMS में निम्नलिखित के रूप में जोड़ें:
+----+----+----+----+----+----+----+----+
| |
~ from ~
~ ~
| |
+----+----+----+----+----+----+----+----+
| flags | options (optional) |
+----+----+ +
~ ~
~ ~
+----+----+----+----+----+----+----+----+
| |
~ offline_signature (optional) ~
~ expires, sigtype, pubkey, offsig ~
| |
+----+----+----+----+----+----+----+----+
| |
~ payload ~
~ ~
| |
+----+----+----+----+----+----+----+----+
| |
~ signature ~
~ ~
| |
+----+----+----+----+----+----+----+----+
from :: एक `Destination`
लंबाई: 387+ बाइट्स
डाटाग्राम का उत्प्रेषक और (अधिकांश ऑफलाइन हस्ताक्षर किए गए) हस्ताक्षरक
flags :: (2 बाइट्स)
बिट क्रम: 15 14 ... 3 2 1 0
बिट्स 3-0: संस्करण: 0x02 (0 0 1 0)
बिट 4: यदि 0, कोई विकल्प नहीं है; यदि 1, विकल्प मानचित्रण शामिल किया गया है
बिट 5: यदि 0, कोई ऑफलाइन हस्ताक्षर नहीं है; यदि 1, ऑफलाइन हस्ताक्षरित
बिट्स 15-6: अप्रयुक्त, भविष्य में उपयोग के साथ संगतता के लिए 0 सेट करें
options :: (2+ बाइट्स यदि प्रस्तुत हो)
यदि ध्वज संकेत करता है कि विकल्प प्रस्तुत हैं, तो `Mapping`
जिसमें मनमाना पाठ्य विकल्प होते हैं
offline_signature ::
यदि ध्वज ऑफलाइन कुंजियों का संकेत करता है, तो ऑफलाइन हस्ताक्षर अनुभाग,
जैसा कि सामान्य संरचना विनिर्देश में निर्दिष्ट है,
निम्नलिखित 4 क्षेत्रों के साथ। लंबाई: ऑनलाइन और ऑफलाइन
हस्ताक्षर प्रकारों द्वारा विभेदित होती है, आमतौर पर 102 बाइट्स Ed25519 के लिए
इस अनुभाग को ऑफलाइन उत्पन्न किया जाना चाहिए।
expires :: समाप्ति टाइमस्टैम्प
(4 बाइट्स, बड़ा एंडियन, युग के बाद से सेकेंड्स, 2106 में खत्म होता है)
sigtype :: अस्थायी हस्ताक्षर प्रकार (2 बाइट्स, बड़ा एंडियन)
pubkey :: अस्थायी हस्ताक्षर सार्वजनिक कुंजी (हस्ताक्षर प्रकार द्वारा विभेदित लंबाई),
आमतौर पर Ed25519 हस्ताक्षर प्रकार के लिए 32 बाइट्स।
offsig :: एक `Signature`
समाप्ति टाइमस्टैम्प, अस्थायी हस्ताक्षर प्रकार,
और सार्वजनिक कुंजी का हस्ताक्षर, गंतव्य सार्वजनिक कुंजी द्वारा,
लंबाई: 40+ बाइट्स, जैसा कि हस्ताक्षर प्रकार द्वारा संकेतित, आमतौर पर
Ed25519 हस्ताक्षर प्रकार के लिए 64 बाइट्स।
payload :: डेटा
लंबाई: 0 से लगभग 61 KB (नोट्स देखें)
signature :: एक `Signature`
हस्ताक्षर प्रकार को $from की हस्ताक्षरकारी सार्वजनिक कुंजी प्रकार से मेल खाना चाहिए
(यदि कोई ऑफलाइन हस्ताक्षर नहीं है) या अस्थायी हस्ताक्षर प्रकार
(यदि ऑफलाइन हस्ताक्षरित)
लंबाई: 40+ बाइट्स, जैसा कि हस्ताक्षर प्रकार द्वारा संकेतित, आमतौर पर
Ed25519 हस्ताक्षर प्रकार के लिए 64 बाइट्स।
पेलोड और नीचे निर्दिष्ट अन्य क्षेत्रों का `Signature`।
हस्ताक्षर को $from की हस्ताक्षरकारी सार्वजनिक कुंजी द्वारा सत्यापित किया जाता है
(यदि कोई ऑफलाइन हस्ताक्षर नहीं है) या अस्थायी सार्वजनिक कुंजी
(यदि ऑफलाइन हस्ताक्षरित)
कुल लंबाई: न्यूनतम 433 + पेलोड लंबाई; X25519 भेजने वाले और बिना ऑफलाइन हस्ताक्षर के लिए सामान्य लंबाई: 457 + पेलोड लंबाई। ध्यान दें कि संदेश आमतौर पर I2CP स्तर पर gzip के साथ संपीड़ित होगा, जिससे गंतव्य की संपीड़नीयता के आधार पर महत्वपूर्ण बचत होगी।
नोट: ऑफलाइन हस्ताक्षर प्रारूप सामान्य संरचना विनिर्देश Common और Streaming के समान है।
हस्ताक्षर
हस्ताक्षर निम्नलिखित क्षेत्रों के ऊपर है।
- पूर्वभाग: लक्ष्य गंतव्य की 32-बाइट हैश (डाटाग्राम में शामिल नहीं)
- flags
- विकल्प (यदि प्रस्तुत हो)
- offline_signature (यदि प्रस्तुत हो)
- payload
डेटाग्राम के लिए, DSA_SHA1 कुंजी प्रकार के लिए, हस्ताक्षर पेलोड के SHA-256 हैश पर था, न कि स्वयं पेलोड पर; यहां, हस्ताक्षर हमेशा ऊपर के क्षेत्र पर होते हैं (हैश पर नहीं), चाहे जो भी कुंजी प्रकार हो।
टुहैश सत्यापन
स्वागतकर्ता को हस्ताक्षर (उनके गंतव्य हैश का उपयोग करके) सत्यापित करना चाहिए और प्रत्युत्तर रोकथाम के लिए डाटाग्राम को अस्वीकार करना चाहिए।
डाटाग्राम3 प्रारूप
डाटाग्राम3 को DATAGRAMS में निम्नलिखित के रूप में जोड़ें:
+----+----+----+----+----+----+----+----+
| |
~ fromhash ~
~ ~
| |
+----+----+----+----+----+----+----+----+
| flags | options (optional) |
+----+----+ +
~ ~
~ ~
+----+----+----+----+----+----+----+----+
| |
~ payload ~
~ ~
| |
+----+----+----+----+----+----+----+----+
fromhash :: एक `Hash`
लंबाई: 32 बाइट्स
डाटाग्राम का उत्प्रेषक
flags :: (2 बाइट्स)
बिट क्रम: 15 14 ... 3 2 1 0
बिट्स 3-0: संस्करण: 0x03 (0 0 1 1)
बिट 4: यदि 0, कोई विकल्प नहीं है; यदि 1, विकल्प मानचित्रण शामिल किया गया है
बिट्स 15-5: अप्रयुक्त, भविष्य में उपयोग के साथ संगतता के लिए 0 सेट करें
options :: (2+ बाइट्स यदि प्रस्तुत हो)
यदि ध्वज संकेत करता है कि विकल्प प्रस्तुत हैं, तो `Mapping`
जिसमें मनमाना पाठ्य विकल्प होते हैं
payload :: डेटा
लंबाई: 0 से लगभग 61 KB (नोट्स देखें)
कुल लंबाई: न्यूनतम 34 + पेलोड लंबाई।
SAM
SAMv3 विनिर्देश में STYLE=DATAGRAM2 और STYLE=DATAGRAM3 जोड़ें। ऑफलाइन हस्ताक्षरों की जानकारी को अपडेट करें।
ओवरहेड
यह डिज़ाइन प्रत्युत्तर योग्य डाटाग्राम्स के लिए ध्वजों के लिए 2 बाइट्स का ओवरहेड जोड़ता है। यह स्वीकार्य है।
सुरक्षा विश्लेषण
हस्ताक्षर में लक्ष्य हैश को शामिल करने से प्रत्युत्तरण हमलों को रोकने में प्रभावी होना चाहिए।
डाटाग्राम3 प्रारूप में हस्ताक्षर की कमी है, इसलिए प्रेषक को सत्यापित नहीं किया जा सकता है, और प्रत्युत्तरण हमले संभव हैं। किसी आवश्यक सत्यापन को अनुप्रयोग स्तर पर करना होगा, या रूटर द्वारा रैचट स्तर पर।
नोट्स
- व्यवहारिक लंबाई प्रोटोकॉल की निचली परतों द्वारा सीमित है - सुरंग संदेश विनिर्देश TUNMSG संदेशों को लगभग 61.2 KB तक सीमित करता है और परिवहन TRANSPORT वर्तमान में संदेशों को लगभग 64 KB तक सीमित करता है, इसलिए यहां डेटा लंबाई लगभग 61 KB तक सीमित है।
- बड़े डाटाग्राम्स की विश्वसनीयता के बारे में महत्वपूर्ण नोट्स देखें API। सर्वोत्तम परिणामों के लिए, पेलोड को लगभग 10 KB या उससे कम पर सीमित करें।
अनुकूलता
कोई नहीं। अनुप्रयोगों को प्रोटोकॉल और/या पोर्ट के आधार पर डाटाग्राम2 I2CP संदेशों को रूटर करने के लिए फिर से लिखना होगा। गलत पठित और रूपांतरित डाटाग्राम2 संदेश प्रत्युत्तर योग्य डाटाग्राम या स्ट्रीमिंग संदेशों के रूप में हस्ताक्षर, प्रारूप, या दोनों के आधार पर विफल होंगे।
संक्रमण
प्रत्येक UDP अनुप्रयोग को समर्थन का पता लगाना और स्थानांतरित करना होगा। सबसे प्रमुख UDP अनुप्रयोग बिटटोरेंट है।
बिटटोरेंट
बिटटोरेंट DHT: संभावना है कि एक्सटेंशन ध्वज की आवश्यकता होगी, उदा. i2p_dg2, BiglyBT के साथ समन्वय करें
बिटटोरेंट UDP घोषणाएं Prop160 : डिज़ाइन में प्रारंभ में समाहित करें। BiglyBT, i2psnark, zzzot के साथ समन्वय करें
अन्य
Bote: स्थानांतरित होने की संभावना नहीं है, सक्रिय रूप से बनाए नहीं जा रहा है
Streamr: कोई उपयोग नहीं कर रहा है, कोई संक्रमण योजना नहीं
SAM UDP एप्स: कोई ज्ञात नहीं