नोट
API संस्करण 0.9.51 के रूप में कार्यान्वित। नेटवर्क परिनियोजन और परीक्षण प्रगति में। लघु संशोधन के अधीन। अंतिम विनिर्देश के लिए I2NP और टनल-निर्माण-ECIES देखें।
अवलोकन
सारांश
वर्तमान एन्क्रिप्टेड टनल बिल्ड अनुरोध और प्रतिक्रिया रिकॉर्ड का आकार 528 है। साधारण वेरिएबल टनल बिल्ड और वेरिएबल टनल बिल्ड प्रतिक्रिया संदेशों के लिए, कुल आकार 2113 बाइट्स होता है। यह संदेश उल्टी दिशा के लिए तीन 1KB टनल संदेशों में विभाजित किया जाता है।
ECIES-X25519 राउटर के लिए 528-बाइट रिकॉर्ड प्रारूप में परिवर्तन Prop152 और टनल-निर्माण-ECIES में निर्दिष्ट किए गए हैं। एक सुरंग में ElGamal और ECIES-X25519 राउटर के मिश्रण के लिए, रिकॉर्ड का आकार 528 बाइट्स रहना चाहिए। हालांकि, अगर सुरंग में सभी राउटर ECIES-X25519 हैं, तो एक नया, छोटा बिल्ड रिकॉर्ड संभव है, क्योंकि ECIES-X25519 एन्क्रिप्शन में ElGamal की तुलना में बहुत कम ओवरहेड होता है।
छोटे संदेश बैंडविड्थ बचाएंगे। इसके अलावा, अगर संदेश एक ही टनल संदेश में फिट हो सकते हैं, तो उल्टा मार्ग तीन गुना अधिक कुशल होगा।
यह प्रस्ताव नए अनुरोध और प्रतिक्रिया रिकॉर्ड और नए बिल्ड अनुरोध और बिल्ड प्रतिक्रिया संदेशों को परिभाषित करता है।
टनल निर्माता और बनाई गई सुरंग में सभी होप्स ECIES-X25519 होना चाहिए, और कम से कम संस्करण 0.9.51 होना चाहिए। यह प्रस्ताव तब तक उपयोगी नहीं होगा जब तक नेटवर्क में राउटर की बहुसंख्यक संख्या ECIES-X25519 न हो। यह 2021 के अंत तक होने की उम्मीद है।
लक्ष्य
अधिक लक्ष्यों के लिए Prop152 और Prop156 देखें।
- छोटे रिकॉर्ड और संदेश
- भविष्य के विकल्पों के लिए पर्याप्त जगह बनाए रखें, जैसा कि Prop152 और टनल-निर्माण-ECIES में है
- उल्टी दिशा के लिए एक टनल संदेश में फिट हो
- केवल ECIES होप्स का समर्थन करें
- Prop152 और टनल-निर्माण-ECIES में कार्यान्वित सुधारों का रखरखाव करें
- वर्तमान नेटवर्क के साथ अधिकतम अनुकूलता बनाए रखें
- OBEP से आगन्तुक बिल्ड संदेशों को छुपाएं
- IBGW से बाहरी बिल्ड प्रतिक्रिया संदेशों को छुपाएं
- पूरे नेटवर्क के “फ्लैग डे” अपग्रेड की आवश्यकता नहीं है
- जोखिम को कम करने के लिए धीमी गति से रोलआउट
- मौजूदा क्रिप्टोग्राफिक प्राइमिटिव्स का पुन: उपयोग करें
गैर-लक्ष्य
अधिक गैर-लक्ष्यों के लिए Prop156 देखें।
- मिश्रित ElGamal/ECIES सुरंगों की आवश्यकता नहीं
- लेयर एन्क्रिप्शन परिवर्तन, इसके लिए Prop153 देखें
- क्रिप्टो संचालन को तेजी से नहीं करना। धारणा यह है कि उपर्युक्त मुद्दों के लिए ChaCha20 और AES समान हैं, कम से कम छोटे डेटा आकारों के लिए जो सवाल में हैं।
डिजाइन
रिकॉर्ड्स
गणनाओं के लिए परिशिष्ट देखें।
एन्क्रिप्टेड अनुरोध और प्रतिक्रिया रिकॉर्ड 218 बाइट्स होंगे, जबकि अभी 528 बाइट्स हैं।
सादे टेक्स्ट अनुरोध रिकॉर्ड 154 बाइट्स होंगे, 222 बाइट्स ElGamal रिकॉर्ड के मुकाबले, और 464 बाइट्स ECIES रिकॉर्ड Prop152 और टनल-निर्माण-ECIES के रूप में परिभाषित।
सादे टेक्स्ट प्रतिक्रिया रिकॉर्ड 202 बाइट्स होंगे, 496 बाइट्स ElGamal रिकॉर्ड के मुकाबले, और 512 बाइट्स ECIES रिकॉर्ड Prop152 और टनल-निर्माण-ECIES के रूप में परिभाषित।
प्रतिक्रिया एन्क्रिप्शन ChaCha20 होगी (ChaCha20/Poly1305 नहीं), इसलिए सादे टेक्स्ट रिकॉर्ड्स को 16 बाइट्स के गुणांक में नहीं होना चाहिए।
अनुरोध रिकॉर्ड छोटे किए जाएंगे HKDF का उपयोग करके लेयर और प्रतिक्रिया कुंजियों को बनाने के लिए, ताकि उन्हें अनुरोध में स्पष्ट रूप से सम्मिलित नहीं किया जाए।
टनल बिल्ड संदेश
दोनों एक-प्रकार के नंबर ऑफ रिकॉर्ड्स फ़ील्ड के साथ “वेरिएबल” होंगे, जैसा कि मौजूदा वेरिएबल संदेशों के साथ है।
ShortTunnelBuild: टाइप 25
साधारण लंबाई (4 रिकॉर्ड्स के साथ): 873 बाइट्स
जब इनबाउंड टनल बिल्ड्स के लिए इस्तेमाल किया जाता है, यह सिफारिश की जाती है (लेकिन जरूरी नहीं है) कि इस संदेश को उत्पत्ति द्वारा लहसुन एन्क्रिप्ट किया जाए, इनबाउंड गेटवे को संरेखित करते हुए (वितरण निर्देश ROUTER), आगन्तुक बिल्ड संदेशों को OBEP से छुपाने के लिए। IBGW संदेश को अनक्रिप्ट करता है, सही स्लॉट में जवाब डालता है, और अगली होप तक ShortTunnelBuildMessage भेजता है।
रेकॉर्ड की लंबाई का चयन किया गया है ताकि एक लहसुन एन्क्रिप्टेड STBM फिट हो सके एक एकल टनल संदेश में। नीचे परिशिष्ट देखें।
OutboundTunnelBuildReply: टाइप 26
हम एक नए OutboundTunnelBuildReply संदेश को परिभाषित करते हैं। यह केवल बाहरी टनल बिल्ड्स के लिए इस्तेमाल किया जाता है। उद्देश्य IBGW से बाहर की ओर बिल्ड प्रतिक्रिया संदेशों को छुपाना है। यह OBEP द्वारा लहसुन एन्क्रिप्ट किया जाना चाहिए, उत्पत्ति को लक्षित करते हुए (वितरण निर्देश TUNNEL)। OBEP टनल बिल्ड संदेश को अनक्रिप्ट करता है, एक OutboundTunnelBuildReply संदेश का निर्माण करता है, और जवाब को स्पष्ट टेक्स्ट फ़ील्ड में डालता है। अन्य रिकॉर्ड अन्य स्लॉट में जाते हैं। फिर वह उत्पत्ति के लिए लहसुन संदेश को एन्क्रिप्ट करता है जबसे प्राप्त सांकेतिक कीज।
नोट्स
OTBRM और STBM को लहसुन एन्क्रिप्ट करने से हम IBGW और OBEP के जोड़े हुए सुरंगों के संगतता के साथ किसी भी संभावित मुद्दे से भी बचते हैं।
संदेश प्रवाह
STBM: छोटा टनल निर्माण संदेश (टाइप 25)
OTBRM: आऊटबाउंड टनल निर्माण प्रतिक्रिया संदेश (टाइप 26)
आउंटबाउंड बिल्ड A-B-C
मौजूदा इनबाउंड D-E-F के माध्यम से उत्तर दें
नई सुरंग
STBM STBM STBM
निर्माता ------> A ------> B ------> C ---\
OBEP \
| लहसुन लपेटा हुआ
| OTBRM
| (टनल वितरण)
| OBEP से
| निर्माता को
मौजूदा सुरंग /
निर्माता <-------F---------E-------- D <--/
IBGW
इनबाउंड बिल्ड D-E-F
मौजूदा आउटबाउंड A-B-C के माध्यम से भेजा गया
मौजूदा सुरंग
निर्माता ------> A ------> B ------> C ---\
OBEP \
| लहसुन लपेटा हुआ (वैकल्पिक)
| STBM
| (राउटर वितरण)
| निर्माता से
नई सुरंग | IBGW तक
STBM STBM STBM /
निर्माता <------ F <------ E <------ D <--/
IBGW
रिकॉर्ड्स एन्क्रिप्शन
अनुरोध और प्रतिक्रिया रिकॉर्ड एन्क्रिप्शन: जैसा कि Prop152 और टनल-निर्माण-ECIES में परिभाषित है।
अन्य स्लॉट्स के लिए प्रतिक्रिया रिकॉर्ड एन्क्रिप्शन: ChaCha20।
लेयर एन्क्रिप्शन
वर्तमान में इस विशिष्टता के साथ बनाई गई सुरंगों के लिए लेयर एन्क्रिप्शन को बदलने की कोई योजना नहीं है; यह AES बना रहेगा, जैसा कि वर्तमान में सभी सुरंगों के लिए उपयोग किया जाता है।
लेयर एन्क्रिप्शन को ChaCha20 में बदलना अतिरिक्त शोध के लिए एक विषय है।
नया टनल डेटा संदेश
वर्तमान में इस विशिष्टता के साथ बनाई गई सुरंगों के लिए 1KB टनल डेटा संदेश को बदलने की कोई योजना नहीं है।
यह इस प्रस्ताव के साथ उपयोग के लिए एक नया I2NP संदेश जो कि बड़ा या वेरिएबल-साइज़ का हो, को पेश करने में उपयोगी हो सकता है, इन सुरंगों के ऊपर उपयोग के लिए। यह बड़े संदेशों के लिए ओवरहेड को कम करेगा। यह अतिरिक्त अनुसंधान के लिए एक विषय है।
विनिर्देशन
शॉर्ट अनुरोध रिकॉर्ड
शॉर्ट अनुरोध रिकॉर्ड अनक्रिप्टेड
यह ECIES-X25519 राउटर्स के लिए टनल BuildRequestRecord के प्रस्तावित विनिर्देशन है। टनल-निर्माण-ECIES से परिवर्तनों का सार:
- अनक्रिप्टेड लंबाई को 464 से बदलकर 154 बाइट्स किया गया
- एन्क्रिप्टेड लंबाई को 528 से बदलकर 218 बाइट्स किया गया
- लेयर और प्रतिक्रिया कुंजियाँ और IVs हटाएँ, वे विभाजित() और KDF से उत्पन्न होंगे
अनुरोध रिकॉर्ड में कोई ChaCha प्रतिक्रिया कुंजी नहीं होती है। वे KDF से प्राप्त की जाती हैं। नीचे देखें।
सभी फील्ड्स बिग-एंडियन हैं।
अनक्रिप्टेड आकार: 154 बाइट्स।
बाइट्स 0-3: टनल ID प्राप्त करने के लिए संदेश भेजें, शून्य नहीं
बाइट्स 4-7: अगला टनल ID, गैरशून्य
बाइट्स 8-39: अगला राउटर पहचान हैश
बाइट 40: झंडे
बाइट्स 41-42: अधिक झंडे, अज्ञात, संगतता के लिए 0 पर सेट करें
बाइट 43: लेयर एन्क्रिप्शन प्रकार
बाइट्स 44-47: अनुरोध समय (युग के बाद मिनट में, नीचे की ओर राउंड़िड)
बाइट्स 48-51: अनुरोध समाप्ति (निर्माण के बाद सेकंड में)
बाइट्स 52-55: अगला संदेश ID
बाइट्स 56-x: टनल निर्माण विकल्प (मैपिंग)
बाइट्स x-x: अन्य डेटा जो झंडों या विकल्पों द्वारा इंगित है
बाइट्स x-153: रैंडम पैडिंग (नीचे देखें)
फ्लैग्स फील्ड टनेल-निर्माण में परिभाषित के समान है और उसमें निम्नलिखित शामिल हैं::
बिट क्रम: 76543210 (बिट 7 MSB है) bit 7: अगर सेट है, तो किसी से भी संदेश की अनुमति दें bit 6: अगर सेट है, तो किसी को भी संदेश की अनुमति दें, और जवाब दिए गए अगले हॉप को एक टनल गणना प्रतिक्रिया संदेश में भेजें बिट्स 5-0: अज्ञात, भविष्य के विकल्प के साथ संगतता के लिए 0 पर सेट करना चाहिए
बिट 7 दर्शाता है कि हॉप एक इनबाउंड गेटवे (IBGW) होगा। बिट 6 दर्शाता है कि हॉप एक आउटबाउंड एंडपॉइंट (OBEP) होगा। यदि कोई भी बिट सेट नहीं है, तो हॉप एक इंटरमीडिएट प्रतिभागी होगा। दोनों को एक साथ सेट नहीं किया जा सकता।
लेयर एन्क्रिप्शन प्रकार: 0 AES के लिए (जैसा कि वर्तमान सुरंगों में है); भविष्य के लिए 1 (ChaCha?)
अनुरोध समाप्ति भविष्य की वेरिएबल टनल अवधि के लिए है। फिलहाल, केवल समर्थित मूल्य 600 (10 मिनट) है।
निर्माता की अस्थायी सार्वजनिक कुंजी एक ECIES कुंजी है, बिग-एंडियन। यह IBGW लेयर और प्रतिक्रिया कुंजियों और IVs के लिए KDF है। यह केवल एक इनबाउंड टनल बिल्ड संदेश में सादे टेक्स्ट रिकॉर्ड में शामिल है। यह आवश्यक है क्योंकि इस स्तर पर बिल्ड रिकॉर्ड के लिए कोई DH नहीं है।
टनल बिल्ड विकल्प एक मैपिंग संरचना है जैसा कि कॉमन में परिभाषित है। यह भविष्य के उपयोग के लिए है। कोई विकल्प वर्तमान में परिभाषित नहीं हैं। यदि मैपिंग संरचना खाली है, तो यह दो बाइट्स 0x00 0x00 है। मैपिंग की अधिकतम आकार (लंबाई क्षेत्र सहित) 98 बाइट्स है, और मैपिंग लंबाई क्षेत्र का अधिकतम मान 96 है।
शॉर्ट अनुरोध रिकॉर्ड एन्क्रिप्टेड
सभी फील्ड्स बिग-एंडियन हैं सिवाय अस्थायी सार्वजनिक कुंजी के जो लिटिल-एंडियन है।
एन्क्रिप्टेड आकार: 218 बाइट्स
बाइट्स 0-15: हॉप का ट्रकिकेटेड पहचान हैश
बाइट्स 16-47: प्रेषक की अस्थायी X25519 सार्वजनिक कुंजी
बाइट्स 48-201: ChaCha20 एन्क्रिप्टेड ShortBuildRequestRecord
बाइट्स 202-217: Poly1305 MAC
शॉर्ट प्रतिक्रिया रिकॉर्ड
शॉर्ट प्रतिक्रिया रिकॉर्ड अनक्रिप्टेड
यह ECIES-X25519 राउटर्स के लिए टनल ShortBuildReplyRecord के प्रस्तावित विनिर्देशन है। टनल-निर्माण-ECIES से परिवर्तनों का सार:
- अनक्रिप्टेड लंबाई को 512 से बदलकर 202 बाइट्स किया गया
- एन्क्रिप्टेड लंबाई को 528 से बदलकर 218 बाइट्स किया गया
ECIES प्रतिक्रियाओं को ChaCha20/Poly1305 के साथ एन्क्रिप्ट किया गया है।
सभी फील्ड्स बिग-एंडियन हैं।
अनक्रिप्टेड आकार: 202 बाइट्स।
बाइट्स 0-x: टनल बिल्ड प्रतिक्रिया विकल्प (मैपिंग)
बाइट्स x-x: विकल्पों द्वारा इंगित अन्य डेटा
बाइट्स x-200: रैंडम पैडिंग (नीचे देखें)
बाइट 201: प्रतिक्रिया बाइट
टनल बिल्ड प्रतिक्रिया विकल्प एक मैपिंग संरचना है जैसा कि कॉमन में परिभाषित है। यह भविष्य के उपयोग के लिए है। कोई विकल्प वर्तमान में परिभाषित नहीं हैं। यदि मैपिंग संरचना खाली है, तो यह दो बाइट्स 0x00 0x00 है। मैपिंग की अधिकतम आकार (लंबाई क्षेत्र सहित) 201 बाइट्स है, और मैपिंग लंबाई क्षेत्र का अधिकतम मान 199 है।
प्रतिक्रिया बाइट निम्नलिखित मूल्यों में से एक है टनल-निर्माण में परिभाषित करने के लिए उंगली पहचान से बचने के लिए:
- 0x00 (स्वीकार)
- 30 (टनल_अस्वीकार_बैंडविड्थ)
शॉर्ट प्रतिक्रिया रिकॉर्ड एन्क्रिप्टेड
एन्क्रिप्टेड आकार: 218 बाइट्स
बाइट्स 0-201: ChaCha20 एन्क्रिप्टेड ShortBuildReplyRecord
बाइट्स 202-217: Poly1305 MAC
KDF
नीचे KDF सेक्शन देखें।
ShortTunnelBuild
I2NP प्रकार 25
यह संदेश मिडल हॉप्स, OBEP, और IBEP (निर्माता) को भेजा जाता है। यह IBGW को नहीं भेजा जा सकता है (लहसुन लपेटे इनबाउंड टनल बिल्ड का उपयोग करें)। जब OBEP द्वारा प्राप्त किया जाता है, तो यह एक OutboundTunnelBuildReply में रूपांतरित होता है, लहसुन लपेटा हुआ, और उत्पत्ति को भेजा जाता है।
+----+----+----+----+----+----+----+----+
| num| ShortBuildRequestRecords...
+----+----+----+----+----+----+----+----+
num ::
1 बाइट `Integer`
वैध मान: 1-8
रिकॉर्ड आकार: 218 बाइट्स
कुल आकार: 1+$num*218
नोट्स
- साधारण संख्या रिकॉर्ड्स की 4 है, कुल आकार: 873।
OutboundTunnelBuildReply
I2NP प्रकार 26
इस संदेश को केवल OBEP द्वारा मौजूदा इनबाउंड टनल के माध्यम से IBEP (निर्माता) को भेजा जाता है। इसे किसी अन्य हॉप को नहीं भेजा जा सकता है। यह हमेशा लहसुन एन्क्रिप्टेड होता है।
+----+----+----+----+----+----+----+----+
| num| |
+----+ +
| ShortBuildReplyRecords... |
+----+----+----+----+----+----+----+----+
num ::
रिकॉर्ड्स की कुल संख्या,
1 बाइट `Integer`
वैध मान: 1-8
ShortBuildReplyRecords ::
एन्क्रिप्टेड रिकॉर्ड्स
लंबाई: num * 218
एन्क्रिप्टेड रिकॉर्ड आकार: 218 बाइट्स
कुल आकार: 1+$num*218
नोट्स
- साधारण संख्या रिकॉर्ड्स की 4 है, कुल आकार: 873।
- इस संदेश को लहसुन एन्क्रिप्ट किया जाना चाहिए।
KDF
हम शोर अवस्था से टनल बिल्ड रिकॉर्ड एन्क्रिप्शन/डिक्रिप्शन के बाद ck का उपयोग करते हैं निम्नलिखित कुंजियों को प्राप्त करने के लिए: प्रतिक्रिया कुंजी, AES लेयर कुंजी, AES IV कुंजी और OBEP के लिए लहसुन प्रतिक्रिया कुंजी/टैग।
प्रतिक्रिया कुंजी: लंबे रिकॉर्ड्स की तरह हम जवाबी कुंजी के लिए ck के बाएँ भाग का उपयोग नहीं कर सकते, क्योंकि यह अंतिम नहीं है और बाद में इसका उपयोग किया जाएगा। प्रतिक्रिया कुंजी का उपयोग AEAD/Chaha20/Poly1305 और अन्य रिकॉर्ड्स की प्रतिक्रिया को chaCha20 करने के लिए किया जाता है। दोनों एक ही कुंजी का उपयोग करते हैं, गिन्नतरी संदेश में रिकॉर्ड की स्थिति है 0 से आरंभ।
keydata = HKDF(ck, ZEROLEN, "SMTunnelReplyKey", 64)
replyKey = keydata[32:63]
ck = keydata[0:31]
लेयर कुंजी:
लेयर कुंजी हमेशा AES होती है, लेकिन chacha20 से ही KDF का उपयोग किया जा सकता है
keydata = HKDF(ck, ZEROLEN, "SMTunnelLayerKey", 64)
layerKey = keydata[32:63]
गैर-OBEP रिकॉर्ड के लिए IV कुंजी:
ivKey = keydata[0:31]
क्योंकि यह अंतिम है
OBEP रिकॉर्ड के लिए IV कुंजी:
ck = keydata[0:31]
keydata = HKDF(ck, ZEROLEN, "TunnelLayerIVKey", 64)
ivKey = keydata[32:63]
ck = keydata[0:31]
OBEP लहसुन प्रतिक्रिया कुंजी/टैग:
keydata = HKDF(ck, ZEROLEN, "RGarlicKeyAndTag", 64)
replyKey = keydata[32:63]
replyTag = keydata[0:7]
औचित्य
यह डिजाइन मौजूदा क्रिप्टोग्राफिक प्राइमिटिव्स, प्रोटोकॉल, और कोड के पुन: उपयोग को अधिकतम करता है।
यह डिजाइन जोखिम को कम करता है।
ChaCha20 छोटे रिकॉर्ड्स के लिए Java परीक्षण में AES की तुलना में थोड़ा तेज़ है। ChaCha20 16 के गुणज के रूप में डेटा आकार की आवश्यकता का अभाव करता है।
कार्यान्वयन नोट्स
- मौजूदा वेरिएबल टनल बिल्ड संदेश के साथ, 4 रिकॉर्ड्स से छोटे संदेश सिफारिश नहीं की जाती। साधारण डिफॉल्ट 3 हॉप्स है। आगन्तुक गेटवे को यह नहीं जानने के लिए ताकि यह अंतिम है, इनबाउंड सुरंगों को एक अतिरिक्त रिकॉर्ड के साथ बिल्ड किया जाना चाहिए ताकि अंतिम हॉप को ना पता चले कि यह अंतिम है। इसलिए मिडल होप्स यह न जानें कि कोई सुरंग इनबाउंड है या आउंटबाउंड, आउटबाउंड सुरंगों को भी 4 रिकॉर्ड्स के साथ बिल्ड किया जाना चाहिए।
मुद्दे
प्रवास
कार्यान्वयन, परीक्षण, और रॉलआउट में कई रिलीज़ और लगभग एक वर्ष का समय लगेगा। चरण इस प्रकार हैं। प्रत्येक चरण को किसी विशेष रिलीज के लिए सौंपना TBD है और विकास की गति पर निर्भर करता है।
प्रत्येक I2P कार्यान्वयन के लिए कार्यान्वयन और प्रवास का विवरण भिन्न हो सकता है।
टनल निर्माता को यह सुनिश्चित करना चाहिए कि निर्मित टनल में सभी होप्स ECIES-X25519 हैं, और कम से कम संस्करण TBD हैं। टनल निर्माता को ECIES-X25519 होने की जरूरत नहीं है; यह ElGamal हो सकता है। हालांकि, यदि निर्माता ElGamal है, तो यह निकटतम होप को बताता है कि यह निर्माता है। इसलिए, व्यवहार में, इन सुरंगों को केवल ECIES राउटर्स द्वारा ही बनाया जाना चाहिए।
यह आवश्यक नहीं होना चाहिए कि जुड़ी हुई सुरंग का OBEP या IBGW ECIES हो या किसी विशेष संस्करण का हो। नए संदेश लहसुन-लपेटे गए होते हैं और जुड़ी सुरंग के OBEP या IBGW पर दृष्टिगोचर नहीं होते।
चरण 1: कार्यान्वयन, डिफॉल्ट रूप से सक्षम नहीं किया गया
चरण 2 (अगली रिलीज): डिफॉल्ट रूप से सक्षम किया गया
इसमें कोई पिछड़ापन-संगतता मुद्दे नहीं हैं। नए संदेश केवल उन राउटर्स को भेजे जा सकते हैं जो उन्हें समर्थन देते हैं।
परिशिष्ट
लहसुन ओवरहेड के बिना गैर-लहसुन इनबाउंड STBM के लिए, अगर हम ITBM का उपयोग न करें:
वर्तमान 4-स्लॉट आकार: 4 * 528 + ओवरहेड = 3 टनल संदेश
4-स्लॉट निर्माण संदेश एक टनल संदेश में फिट हो, ECIES-केवल:
1024
- 21 खंड हेडर
----
1003
- 35 निरफ्रैगमेंटेड राउटर वितरण निर्देश
----
968
- 16 I2NP हेडर
----
952
- 1 स्लॉट की संख्या
----
951
/ 4 स्लॉट्स
----
237 नया एन्क्रिप्टेड निर्माण रिकॉर्ड आकार (वर्तमान में 528 के मुकाबले)
- 16 कटा हुआ हैश
- 32 अस्थायी कुंजी
- 16 MAC
----
173 साफ़टेक्स्ट निर्माण रिकॉर्ड अधिकतम (वर्तमान में 222 के मुकाबले)
इनबाउंड STBM के लिए ‘N’ शोर पैटर्न के लिए लहसुन ओवरहेड के साथ, यदि हम ITBM का उपयोग न करें:
वर्तमान 4-स्लॉट आकार: 4 * 528 + ओवरहेड = 3 टनल संदेश
4 स्लॉट गार्लिक-एन्क्रिप्टेड बिल्ड संदेश तक एक टनल संदेश में फिट हो, सिर्फ ECIES के लिए:
1024
- 21 खंड हेडर
----
1003
- 35 निरफ्रैगमेंटेड राउटर वितरण निर्देश
----
968
- 16 I2NP हेडर
- 4 लंबाई
----
948
- 32 बाइट अस्थायी कुंजी
----
916
- 7 बाइट DateTime ब्लॉक
----
909
- 3 बाइट गार्लिक ब्लॉक ओवरहेड
----
906
- 9 बाइट I2NP हेडर
----
897
- 1 बाइट गार्लिक LOCAL वितरण निर्देश
----
896
- 16 बाइट Poly1305 MAC
----
880
- 1 स्लॉट की संख्या
----
879
/ 4 स्लॉट्स
----
219 नया एन्क्रिप्टेड निर्माण रिकॉर्ड आकार (वर्तमान में 528 के मुकाबले)
- 16 कटा हुआ हैश
- 32 अस्थायी कुंजी
- 16 MAC
----
155 साफ़टेक्स्ट निर्माण रिकॉर्ड अधिकतम (वर्तमान में 222 के मुकाबले)
नोट्स:
वर्तमान निर्माण रिकॉर्ड्स का साफ़टेक्स्ट आकार बिना इस्तेमाल किए गए पैडिंग के पहले: 193
पूरी राउटर हैश को हटाना और कुंजियाँ/IVs उत्पन्न करना बहुत सारी जगह बचाएगा भविष्य के विकल्पों के लिए। यदि सब कुछ HKDF है, तो आवश्यक साफ़टेक्स्ट जगह लगभग 58 बाइट्स (बिना किसी विकल्पों के) होगी।
गार्लिक-लपेटा हुआ OTBRM बिना किसी गार्लिक-लपेटा हुआ STBM से थोड़ा छोटा होगा, क्योंकि वितरण निर्देश LOCAL हैं, न कि राउटर, कोई DATETIME ब्लॉक शामिल नहीं है, और यह 32 बाइट अस्थायी कुंजी की तुलना में एक 8 बाइट टैग का उपयोग करता है।