नोट
प्रस्ताव चरण बंद है। आधिकारिक विनिर्देश के लिए SPEC देखें। इस प्रस्ताव को अभी भी पृष्ठभूमि जानकारी के लिए संदर्भित किया जा सकता है।
अवलोकन
यह प्रस्ताव एक प्रमाणित की एग्रीमेंट प्रोटोकॉल का वर्णन करता है जो NTCP की विभिन्न प्रकार की स्वचालित पहचान और हमलों के प्रति प्रतिरोधी क्षमता को बेहतर बनाने के लिए है।
यह प्रस्ताव निम्नलिखित रूप में व्यवस्थित है: सबसे पहले सुरक्षा लक्ष्यों को प्रस्तुत किया गया है, उसके बाद मूलभूत प्रोटोकॉल की चर्चा की गई है। इसके बाद, सभी प्रोटोकॉल संदेशों का एक संपूर्ण विनिर्देश दिया गया है। अंत में, router पतों और संस्करण पहचान पर चर्चा की गई है। सामान्य padding योजनाओं पर एक सामान्य हमले पर चर्चा करने वाला एक परिशिष्ट भी शामिल है, साथ ही authenticated cipher के लिए कई उम्मीदवारों वाला एक परिशिष्ट भी है।
अन्य I2P transports की तरह, NTCP2 केवल I2NP संदेशों के point-to-point (router-to-router) transport के लिए परिभाषित है। यह एक सामान्य-उद्देश्य डेटा पाइप नहीं है।
प्रेरणा
NTCP डेटा पहले संदेश के बाद एन्क्रिप्ट किया जाता है (और पहला संदेश यादृच्छिक डेटा की तरह दिखाई देता है), इस प्रकार “payload analysis” के माध्यम से प्रोटोकॉल की पहचान को रोकता है। यह अभी भी “flow analysis” के माध्यम से प्रोटोकॉल की पहचान के लिए संवेदनशील है। ऐसा इसलिए है क्योंकि पहले 4 संदेश (यानी handshake) निश्चित लंबाई (288, 304, 448, और 48 bytes) के होते हैं।
प्रत्येक संदेश में यादृच्छिक मात्रा में यादृच्छिक डेटा जोड़कर, हम इसे काफी कठिन बना सकते हैं।
लेखक स्वीकार करते हैं कि मानक सुरक्षा प्रथाओं के अनुसार TLS जैसे मौजूदा प्रोटोकॉल का उपयोग करना चाहिए, लेकिन यह Prop104 है और इसकी अपनी समस्याएं हैं। जहां उपयुक्त हो, “भविष्य के काम” के पैराग्राफ जोड़े गए हैं ताकि गुम सुविधाओं या चर्चा के विषयों को इंगित किया जा सके।
डिज़ाइन लक्ष्य
एक ही port पर NTCP 1 और 2 दोनों को support करना, auto-detect करना, और NetDB में एक single “transport” (यानी RouterAddress) के रूप में published करना।
NetDB में केवल version 1, केवल 2, या 1+2 के लिए support को एक अलग field में publish करें, और default को केवल version 1 रखें (version support को किसी विशेष router version से bind न करें)
सुनिश्चित करें कि सभी implementations (Java/i2pd/Kovri/go) अपने स्वयं के schedules पर version 2 support जोड़ सकें (या न जोड़ें)
सभी NTCP संदेशों में यादृच्छिक पैडिंग जोड़ें जिसमें handshake और data संदेश शामिल हैं (यानी लंबाई अस्पष्टीकरण ताकि सभी संदेश 16 bytes के गुणज न हों) दोनों पक्षों के लिए न्यूनतम और अधिकतम पैडिंग और/या पैडिंग वितरण का अनुरोध करने के लिए विकल्प तंत्र प्रदान करें। पैडिंग वितरण की विशिष्टताएं implementation-dependent हैं और प्रोटोकॉल में निर्दिष्ट हो भी सकती हैं और नहीं भी।
उन संदेशों की सामग्री को अस्पष्ट करें जो एन्क्रिप्टेड नहीं हैं (1 और 2), पर्याप्त रूप से ताकि DPI बॉक्स और AV signatures उन्हें आसानी से वर्गीकृत न कर सकें। यह भी सुनिश्चित करें कि किसी एक peer या peers के समूह को जाने वाले संदेशों में bits का समान pattern न हो।
Java format के कारण DH में bits के नुकसान को ठीक करें Ticket1112, संभवतः (शायद?) X25519 पर स्विच करके।
एक वास्तविक key derivation function (KDF) पर स्विच करें बजाय DH परिणाम को as-is उपयोग करने के?
“प्रोबिंग प्रतिरोध” (जैसा कि Tor इसे कहता है) जोड़ें; इसमें रीप्ले प्रतिरोध शामिल है।
2-way authenticated key exchange (2W-AKE) बनाए रखें। 1W-AKE हमारे एप्लिकेशन के लिए पर्याप्त नहीं है।
प्रकाशित RouterIdentity signing key से variable-type, variable-length signatures का उपयोग authentication के हिस्से के रूप में जारी रखें। Authentication के दूसरे हिस्से के रूप में RouterInfo में प्रकाशित static public key पर भरोसा करें।
भविष्य की विस्तारशीलता के लिए handshake में options/version जोड़ें।
यदि संभव हो तो दुर्भावनापूर्ण MitM TCP segmentation के विरुद्ध प्रतिरोध जोड़ें।
कनेक्शन सेटअप के लिए आवश्यक CPU में महत्वपूर्ण वृद्धि न करें; यदि संभव हो तो इसे काफी कम करें।
संदेश प्रमाणीकरण (MAC) जोड़ें, संभवतः HMAC-SHA256 और Poly1305, और Adler checksum को हटा दें।
I2NP हैडर को छोटा और सरल बनाएं: SSU की तरह expiration को 4 bytes तक छोटा करें। एक-byte truncated SHA256 checksum को हटाएं।
यदि संभव हो, 4-संदेश, दो-राउंड-ट्रिप handshake को 3-संदेश, एक-राउंड-ट्रिप handshake में कम करें, जैसा कि SSU में है। इसके लिए Bob के signature को message 4 से message 2 में स्थानांतरित करना होगा। दस साल पुराने email/status/meeting archives में 4 messages के कारण पर अनुसंधान करें।
पैडिंग से पहले प्रोटोकॉल ओवरहेड को कम करें। जबकि पैडिंग जोड़ा जाएगा, और संभवतः बहुत सारा, पैडिंग से पहले का ओवरहेड अभी भी ओवरहेड है। कम-बैंडविड्थ nodes को NTCP2 का उपयोग करने में सक्षम होना चाहिए।
रीप्ले और स्क्यू डिटेक्शन के लिए टाइमस्टैम्प बनाए रखें।
टाइमस्टैम्प में वर्ष 2038 की किसी भी समस्या से बचें, कम से कम 2106 तक काम करना चाहिए।
अधिकतम संदेश आकार को 16K से बढ़ाकर 32K या 64K करें।
कोई भी नया क्रिप्टोग्राफिक primitive Java (1.7), C++, और Go router implementations में उपयोग के लिए libraries में आसानी से उपलब्ध होना चाहिए।
डिज़ाइन में Java, C++, और Go router डेवलपर्स के प्रतिनिधियों को शामिल करें।
परिवर्तनों को न्यूनतम करें (लेकिन फिर भी बहुत सारे होंगे)।
एक सामान्य कोड सेट में दोनों संस्करणों का समर्थन करें (यह संभव नहीं हो सकता है और किसी भी स्थिति में implementation-dependent है)।
Non-Goals
बुलेट-प्रूफ DPI प्रतिरोध… वह होगा pluggable transports, Prop109।
एक TLS-आधारित (या HTTPS-जैसा) transport… जो Prop104 होगा।
सिमेट्रिक स्ट्रीम क्रिप्टोग्राफी को बदलना ठीक है।
टाइमिंग-आधारित DPI प्रतिरोध (inter-message timing/delays कार्यान्वयन-निर्भर हो सकते हैं; intra-message delays किसी भी बिंदु पर शुरू किए जा सकते हैं, जिसमें random padding भेजने से पहले भी शामिल है, उदाहरण के लिए)। कृत्रिम विलंब (जिसे obfs4 में IAT या inter-arrival time कहा जाता है) प्रोटोकॉल से स्वतंत्र होते हैं।
एक सत्र में भाग लेने की इनकारी (वहाँ signatures हैं)।
गैर-लक्ष्य जिन पर आंशिक रूप से पुनर्विचार किया जा सकता है या चर्चा की जा सकती है:
Deep Packet Inspection (DPI) के विरुद्ध सुरक्षा की मात्रा
Post-Quantum (PQ) सुरक्षा
इनकार योग्यता
Related Goals
- एक NTCP 1/2 परीक्षण सेटअप को लागू करें
Security Goals
हम तीन पक्षों पर विचार करते हैं:
- Alice, जो एक नया session स्थापित करना चाहती है।
- Bob, जिसके साथ Alice एक session स्थापित करना चाहती है।
- Mallory, Alice और Bob के बीच “man in the middle”।
अधिकतम दो प्रतिभागी सक्रिय हमलों में शामिल हो सकते हैं।
Alice और Bob दोनों के पास एक static key pair है, जो उनकी RouterIdentity में निहित है।
प्रस्तावित प्रोटोकॉल Alice और Bob को निम्नलिखित आवश्यकताओं के तहत एक साझा गुप्त key (K) पर सहमत होने की अनुमति देने का प्रयास करता है:
Private key सुरक्षा: न तो Bob और न ही Mallory को Alice की static private key के बारे में कुछ भी पता चलता है। समान रूप से, Alice को Bob की static private key के बारे में कुछ भी पता नहीं चलता है।
session key K केवल Alice और Bob को ही पता है।
Perfect forward secrecy: सहमत session key भविष्य में गुप्त रहती है, तब भी जब Alice और/या Bob की static private keys बाद में उजागर हो जाती हैं जब key पर सहमति हो चुकी होती है।
द्विदिशीय प्रमाणीकरण: Alice निश्चित है कि उसने Bob के साथ एक session स्थापित किया है, और इसके विपरीत भी।
ऑनलाइन DPI के विरुद्ध सुरक्षा: यह सुनिश्चित करें कि केवल सीधी deep packet inspection (DPI) तकनीकों का उपयोग करके यह पता लगाना तुच्छ नहीं है कि Alice और Bob प्रोटोकॉल में संलग्न हैं। नीचे देखें।
सीमित इनकारी क्षमता: न तो Alice और न ही Bob protocol में भागीदारी से इनकार कर सकते हैं, लेकिन यदि कोई भी shared key को leak करता है तो दूसरा पक्ष transmitted data की सामग्री की प्रामाणिकता से इनकार कर सकता है।
प्रस्तुत प्रस्ताव Station-To-Station (STS) प्रोटोकॉल के आधार पर सभी पांच आवश्यकताओं को प्रदान करने का प्रयास करता है। ध्यान दें कि यह प्रोटोकॉल SSU प्रोटोकॉल का भी आधार है।
Additional DPI Discussion
हम दो DPI घटकों को मानते हैं:
1) Online DPI
ऑनलाइन DPI सभी flows को real-time में inspect करता है। Connections को block किया जा सकता है या अन्यथा छेड़छाड़ की जा सकती है। Connection data या metadata को identify और offline analysis के लिए store किया जा सकता है। ऑनलाइन DPI के पास I2P network database तक पहुँच नहीं है। ऑनलाइन DPI के पास केवल सीमित real-time computational capability है, जिसमें length calculation, field inspection, और simple calculations जैसे XOR शामिल हैं। ऑनलाइन DPI के पास fast real-time cryptographic functions जैसे AES, AEAD, और hashing की capability है, लेकिन ये अधिकांश या सभी flows पर लागू करने के लिए बहुत महंगे होंगे। इन cryptographic operations का कोई भी application केवल उन flows पर लागू होगा जो IP/Port combinations पर offline analysis द्वारा पहले से identify किए गए हों। ऑनलाइन DPI के पास high-overhead cryptographic functions जैसे DH या elligator2 की capability नहीं है। ऑनलाइन DPI विशेष रूप से I2P को detect करने के लिए designed नहीं है, हालांकि इस उद्देश्य के लिए इसके पास सीमित classification rules हो सकते हैं।
यह एक online DPI द्वारा protocol की पहचान को रोकने का लक्ष्य है।
ऑनलाइन या “straightforward” DPI की अवधारणा में यहाँ निम्नलिखित विरोधी क्षमताएं शामिल हैं:
लक्ष्य द्वारा भेजे या प्राप्त किए गए सभी डेटा का निरीक्षण करने की क्षमता।
देखे गए डेटा पर ऑपरेशन करने की क्षमता, जैसे कि block ciphers या hash functions लगाना।
पहले भेजे गए संदेशों को संग्रहीत करने और उनके साथ तुलना करने की क्षमता।
पैकेट्स को संशोधित, विलंबित या खंडित करने की क्षमता।
हालांकि, ऑनलाइन DPI में निम्नलिखित प्रतिबंध होने की अपेक्षा की जाती है:
IP addresses को router hashes के साथ map करने की असमर्थता। जबकि यह network database तक real-time पहुंच के साथ तुच्छ है, इसके लिए I2P को विशेष रूप से target करने के लिए डिज़ाइन किए गए DPI system की आवश्यकता होगी।
प्रोटोकॉल का पता लगाने के लिए timing information का उपयोग करने में असमर्थता।
सामान्यतः, ऑनलाइन DPI टूलबॉक्स में कोई भी बिल्ट-इन टूल नहीं होते जो विशेष रूप से I2P detection के लिए डिज़ाइन किए गए हों। इसमें “honeypots” बनाना भी शामिल है, जिसमें उदाहरण के लिए उनके messages में nonrandom padding शामिल होगी। ध्यान दें कि यह machine learning systems या अत्यधिक configurable DPI tools को बाहर नहीं करता जब तक वे अन्य आवश्यकताओं को पूरा करते हैं।
payload analysis का मुकाबला करने के लिए, यह सुनिश्चित किया जाता है कि सभी messages random से अप्रभेद्य हों। इसके लिए उनकी length का भी random होना आवश्यक है, जो कि केवल random padding जोड़ने से कहीं अधिक जटिल है। वास्तव में, Appendix A में, लेखक तर्क देते हैं कि एक naive (यानी uniform) padding scheme इस समस्या का समाधान नहीं करती। इसलिए Appendix A प्रस्तावित करता है कि या तो random delays शामिल किए जाएं या एक वैकल्पिक padding scheme विकसित की जाए जो प्रस्तावित attack के लिए उचित सुरक्षा प्रदान कर सके।
उपरोक्त छठी प्रविष्टि से सुरक्षा के लिए, implementations में protocol में random delays शामिल करने चाहिए। इस प्रकार की तकनीकें इस proposal में शामिल नहीं हैं, लेकिन वे padding length की समस्याओं का समाधान भी कर सकती हैं। सारांश में, यह proposal payload analysis के खिलाफ अच्छी सुरक्षा प्रदान करती है (जब Appendix A में दिए गए विचारों को ध्यान में रखा जाए), लेकिन flow analysis के खिलाफ केवल सीमित सुरक्षा प्रदान करती है।
2) Offline DPI
Offline DPI ऑनलाइन DPI द्वारा संग्रहीत डेटा का निरीक्षण करता है बाद के विश्लेषण के लिए। Offline DPI को विशेष रूप से I2P का पता लगाने के लिए डिज़ाइन किया जा सकता है। Offline DPI के पास I2P network database तक real-time पहुंच नहीं है। Offline DPI के पास इस और अन्य I2P specifications तक पहुंच है। Offline DPI के पास असीमित कम्प्यूटेशनल क्षमता है, जिसमें इस specification में परिभाषित सभी cryptographic functions शामिल हैं।
ऑफ़लाइन DPI के पास मौजूदा कनेक्शन को ब्लॉक करने की क्षमता नहीं है। ऑफ़लाइन DPI के पास पार्टियों के host/port पर निकट-रीयलटाइम (सेटअप के कुछ मिनटों के भीतर) भेजने की क्षमता है, उदाहरण के लिए TCP RST। ऑफ़लाइन DPI के पास “probing” या अन्य कारणों से पिछले संदेशों (संशोधित या नहीं) का निकट-रीयलटाइम (सेटअप के कुछ मिनटों के भीतर) replay करने की क्षमता है।
यह offline DPI द्वारा protocol पहचान को रोकना एक लक्ष्य नहीं है। पहले दो messages में obfuscated data की सभी decoding, जो I2P routers द्वारा implemented की जाती है, offline DPI द्वारा भी implemented हो सकती है।
यह एक लक्ष्य है कि पिछले संदेशों के replay का उपयोग करके किए गए connection के प्रयासों को अस्वीकार करना।
Future work
पैकेट्स को हमलावर द्वारा ड्रॉप या पुनः व्यवस्थित किए जाने पर प्रोटोकॉल के व्यवहार पर विचार करें। इस क्षेत्र में हाल का दिलचस्प काम IACR-1150 में पाया जा सकता है।
DPI सिस्टम का अधिक सटीक वर्गीकरण प्रदान करें, इस विषय से संबंधित मौजूदा साहित्य को ध्यान में रखते हुए।
प्रस्तावित प्रोटोकॉल की औपचारिक सुरक्षा पर चर्चा करें, आदर्श रूप से DPI attacker model को ध्यान में रखते हुए।
Noise Protocol Framework
यह प्रस्ताव Noise Protocol Framework NOISE (Revision 33, 2017-10-04) पर आधारित आवश्यकताएं प्रदान करता है। Noise में Station-To-Station protocol के समान गुण हैं, जो SSU protocol का आधार है। Noise की भाषा में, Alice initiator है, और Bob responder है।
NTCP2, Noise protocol Noise_XK_25519_ChaChaPoly_SHA256 पर आधारित है। (प्रारंभिक key derivation function के लिए वास्तविक identifier “Noise_XKaesobfse+hs2+hs3_25519_ChaChaPoly_SHA256” है जो I2P extensions को दर्शाने के लिए है - नीचे KDF 1 section देखें) यह Noise protocol निम्नलिखित primitives का उपयोग करता है:
Handshake Pattern: XK Alice अपनी key को Bob को transmit करती है (X) Alice को Bob की static key पहले से पता है (K)
DH Function: X25519 X25519 DH 32 बाइट की key length के साथ जैसा कि RFC-7748 में निर्दिष्ट है।
Cipher Function: ChaChaPoly AEAD_CHACHA20_POLY1305 जैसा कि RFC-7539 अनुभाग 2.8 में निर्दिष्ट है। 12 बाइट nonce, जिसके पहले 4 बाइट्स शून्य पर सेट हैं।
Hash Function: SHA256 मानक 32-बाइट hash, पहले से ही I2P में व्यापक रूप से उपयोग किया जा रहा है।
सुरक्षा लक्ष्य
यह प्रस्ताव Noise_XK_25519_ChaChaPoly_SHA256 में निम्नलिखित संवर्धनों को परिभाषित करता है। ये सामान्यतः NOISE धारा 13 की दिशानिर्देशों का पालन करते हैं।
Cleartext ephemeral keys को एक ज्ञात key और IV का उपयोग करके AES encryption के साथ obfuscate किया जाता है। यह elligator2 से तेज़ है।
संदेश 1 और 2 में रैंडम cleartext padding जोड़ा जाता है। cleartext padding को handshake hash (MixHash) गणना में शामिल किया जाता है। संदेश 2 और संदेश 3 भाग 1 के लिए नीचे दिए गए KDF अनुभागों को देखें। संदेश 3 और data phase संदेशों में रैंडम AEAD padding जोड़ा जाता है।
एक दो-बाइट frame length field जोड़ा जाता है, जैसा कि Noise over TCP के लिए आवश्यक है, और obfs4 की तरह। यह केवल data phase messages में उपयोग किया जाता है। Message 1 और 2 AEAD frames fixed length के होते हैं। Message 3 part 1 AEAD frame fixed length का होता है। Message 3 part 2 AEAD frame length message 1 में निर्दिष्ट होता है।
दो-बाइट frame length फील्ड को SipHash-2-4 के साथ obfuscate किया जाता है, जैसा कि obfs4 में होता है।
payload format संदेशों 1,2,3, और data phase के लिए परिभाषित है। बेशक, यह Noise में परिभाषित नहीं है।
New Cryptographic Primitives for I2P
मौजूदा I2P router implementations को निम्नलिखित मानक cryptographic primitives के लिए implementations की आवश्यकता होगी, जो वर्तमान I2P protocols के लिए आवश्यक नहीं हैं:
X25519 key generation और DH
AEAD_ChaCha20_Poly1305 (नीचे ChaChaPoly के रूप में संक्षिप्त)
SipHash-2-4
Processing overhead estimate
3 संदेशों के लिए संदेश आकार:
- 64 बाइट्स + पैडिंग (NTCP था 288 बाइट्स) 2) 64 बाइट्स + पैडिंग (NTCP था 304 बाइट्स) 3) लगभग 64 बाइट्स + Alice router की जानकारी + पैडिंग औसत router की जानकारी लगभग 750 बाइट्स होती है कुल औसत 814 बाइट्स पैडिंग से पहले (NTCP था 448 बाइट्स) 4) NTCP2 में आवश्यक नहीं (NTCP था 48 बाइट्स)
पैडिंग से पहले कुल: NTCP2: 942 bytes NTCP: 1088 bytes ध्यान दें कि यदि Alice ने अपने RouterInfo का DatabaseStore Message भेजने के उद्देश्य से Bob से कनेक्ट किया है, तो वह message आवश्यक नहीं है, जिससे लगभग 800 bytes की बचत होती है।
निम्नलिखित क्रिप्टोग्राफिक ऑपरेशन प्रत्येक पार्टी द्वारा handshake पूरा करने और डेटा चरण शुरू करने के लिए आवश्यक हैं:
- AES: 2
- SHA256: 7 (Alice), 6 (Bob) (सभी कनेक्शन के लिए पूर्व-गणना किए गए 1 Alice, 2 Bob को छोड़कर) (HMAC-SHA256 को छोड़कर)
- HMAC-SHA256: 19
- ChaChaPoly: 4
- X25519 key generation: 1
- X25519 DH: 3
- Signature verification: 1 (Bob) (Alice ने पहले अपना RI बनाते समय हस्ताक्षर किया था) संभावित रूप से Ed25519 (RI signature type पर निर्भर)
निम्नलिखित cryptographic operations प्रत्येक data phase message के लिए हर party द्वारा आवश्यक हैं:
- SipHash: 1
- ChaChaPoly: 1
Messages
सभी NTCP2 संदेश 65537 बाइट्स या उससे कम लंबाई के होते हैं। संदेश प्रारूप Noise संदेशों पर आधारित है, जिसमें framing और indistinguishability के लिए संशोधन किए गए हैं। मानक Noise libraries का उपयोग करने वाले implementations को प्राप्त संदेशों को Noise संदेश प्रारूप से/में pre-process करने की आवश्यकता हो सकती है। सभी encrypted फील्ड AEAD ciphertexts हैं।
स्थापना अनुक्रम निम्नलिखित है:
Alice Bob
SessionRequest ------------------->
<------------------- SessionCreated
SessionConfirmed ----------------->
Noise terminology का उपयोग करते हुए, establishment और data sequence निम्नलिखित है: (Payload Security Properties)
XK(s, rs): Authentication Confidentiality
<- s
...
-> e, es 0 2
<- e, ee 2 1
-> s, se 2 5
<- 2 5
एक बार session स्थापित हो जाने के बाद, Alice और Bob Data messages का आदान-प्रदान कर सकते हैं।
सभी message types (SessionRequest, SessionCreated, SessionConfirmed, Data और TimeSync) इस अनुभाग में निर्दिष्ट हैं।
कुछ संकेतन:
- RH_A = Alice के लिए Router Hash (32 bytes)
- RH_B = Bob के लिए Router Hash (32 bytes)
Authenticated Encryption
तीन अलग authenticated encryption instances (CipherStates) हैं। एक handshake phase के दौरान, और दो (transmit और receive) data phase के लिए। प्रत्येक की अपनी key एक KDF से है।
एन्क्रिप्टेड/प्रमाणीकृत डेटा को इस रूप में दर्शाया जाएगा
+----+----+----+----+----+----+----+----+
| |
+ +
| Encrypted and authenticated data |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
गैर-लक्ष्य
एन्क्रिप्टेड और प्रमाणित डेटा फॉर्मेट।
एन्क्रिप्शन/डिक्रिप्शन फ़ंक्शन्स के लिए इनपुट्स:
k :: 32 byte cipher key, as generated from KDF
nonce :: Counter-based nonce, 12 bytes.
Starts at 0 and incremented for each message.
First four bytes are always zero.
Last eight bytes are the counter, little-endian encoded.
Maximum value is 2**64 - 2.
Connection must be dropped and restarted after
it reaches that value.
The value 2**64 - 1 must never be sent.
ad :: In handshake phase:
Associated data, 32 bytes.
The SHA256 hash of all preceding data.
In data phase:
Zero bytes
data :: Plaintext data, 0 or more bytes
encryption function का आउटपुट, decryption function का इनपुट:
+----+----+----+----+----+----+----+----+
|Obfs Len | |
+----+----+ +
| ChaCha20 encrypted data |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
| Poly1305 Message Authentication Code |
+ (MAC) +
| 16 bytes |
+----+----+----+----+----+----+----+----+
Obfs Len :: Length of (encrypted data + MAC) to follow, 16 - 65535
Obfuscation using SipHash (see below)
Not used in message 1 or 2, or message 3 part 1, where the length is fixed
Not used in message 3 part 1, as the length is specified in message 1
encrypted data :: Same size as plaintext data, 0 - 65519 bytes
MAC :: Poly1305 message authentication code, 16 bytes
ChaCha20 के लिए, यहां जो वर्णित है वह RFC-7539 के अनुरूप है, जो TLS RFC-7905 में भी समान रूप से उपयोग किया जाता है।
Notes
चूंकि ChaCha20 एक stream cipher है, plaintexts को padded करने की आवश्यकता नहीं है। अतिरिक्त keystream bytes को discard कर दिया जाता है।
साइफर के लिए key (256 bits) SHA256 KDF के माध्यम से तय की जाती है। प्रत्येक message के लिए KDF के विवरण नीचे अलग sections में हैं।
संदेश 1, 2, और संदेश 3 के पहले भाग के लिए ChaChaPoly frames ज्ञात आकार के होते हैं। संदेश 3 के दूसरे भाग से शुरू करते हुए, frames परिवर्तनीय आकार के होते हैं। संदेश 3 भाग 1 का आकार संदेश 1 में निर्दिष्ट किया जाता है। डेटा चरण से शुरू करते हुए, frames के पहले दो-बाइट length जोड़ी जाती है जो obfs4 की तरह SipHash के साथ obfuscated होती है।
संदेश 1 और 2 के लिए padding प्रमाणित डेटा frame के बाहर होता है। अगले संदेश के लिए KDF में padding का उपयोग किया जाता है इसलिए छेड़छाड़ का पता चल जाएगा। संदेश 3 से शुरू करके, padding प्रमाणित डेटा frame के अंदर होता है।
संबंधित लक्ष्य
संदेशों 1, 2, और संदेश 3 के भाग 1 और 2 में, AEAD संदेश का आकार पहले से ज्ञात होता है। AEAD प्रमाणीकरण विफलता पर, प्राप्तकर्ता को आगे की संदेश प्रक्रिया रोकनी चाहिए और बिना जवाब दिए कनेक्शन बंद कर देना चाहिए। यह एक असामान्य बंद (TCP RST) होना चाहिए।
प्रोबिंग प्रतिरोध के लिए, message 1 में, एक AEAD failure के बाद, Bob को एक random timeout (range TBD) set करना चाहिए और फिर socket बंद करने से पहले एक random number of bytes (range TBD) पढ़ना चाहिए। Bob को बार-बार failures वाले IPs की blacklist maintain करनी चाहिए।
डेटा चरण में, AEAD संदेश का आकार SipHash के साथ “एन्क्रिप्टेड” (अस्पष्ट) होता है। डिक्रिप्शन ओरेकल बनाने से बचने के लिए सावधानी बरतनी चाहिए। डेटा चरण AEAD प्रमाणीकरण विफलता पर, प्राप्तकर्ता को एक यादृच्छिक टाइमआउट (सीमा TBD) सेट करना चाहिए और फिर यादृच्छिक संख्या में बाइट्स (सीमा TBD) पढ़ना चाहिए। पढ़ने के बाद, या रीड टाइमआउट पर, प्राप्तकर्ता को “AEAD failure” कारण कोड वाले टर्मिनेशन ब्लॉक के साथ एक पेलोड भेजना चाहिए, और कनेक्शन बंद कर देना चाहिए।
डेटा फेज में अमान्य length field value के लिए समान error action लें।
Key Derivation Function (KDF) (for handshake message 1)
KDF, DH परिणाम से एक handshake phase cipher key k उत्पन्न करता है, HMAC-SHA256(key, data) का उपयोग करते हुए जैसा कि RFC-2104 में परिभाषित है। ये InitializeSymmetric(), MixHash(), और MixKey() functions हैं, बिल्कुल वैसे ही जैसे Noise spec में परिभाषित हैं।
This is the "e" message pattern:
// Define protocol_name.
Set protocol_name = "Noise_XKaesobfse+hs2+hs3_25519_ChaChaPoly_SHA256"
(48 bytes, US-ASCII encoded, no NULL termination).
// Define Hash h = 32 bytes
h = SHA256(protocol_name);
Define ck = 32 byte chaining key. Copy the h data to ck.
Set ck = h
Define rs = Bob's 32-byte static key as published in the RouterInfo
// MixHash(null prologue)
h = SHA256(h);
// up until here, can all be precalculated by Alice for all outgoing connections
// Alice must validate that Bob's static key is a valid point on the curve here.
// Bob static key
// MixHash(rs)
// || below means append
h = SHA256(h || rs);
// up until here, can all be precalculated by Bob for all incoming connections
This is the "e" message pattern:
Alice generates her ephemeral DH key pair e.
// Alice ephemeral key X
// MixHash(e.pubkey)
// || below means append
h = SHA256(h || e.pubkey);
// h is used as the associated data for the AEAD in message 1
// Retain the Hash h for the message 2 KDF
End of "e" message pattern.
This is the "es" message pattern:
// DH(e, rs) == DH(s, re)
Define input_key_material = 32 byte DH result of Alice's ephemeral key and Bob's static key
Set input_key_material = X25519 DH result
// MixKey(DH())
Define temp_key = 32 bytes
Define HMAC-SHA256(key, data) as in [RFC-2104](https://tools.ietf.org/html/rfc2104)
// Generate a temp key from the chaining key and DH result
// ck is the chaining key, defined above
temp_key = HMAC-SHA256(ck, input_key_material)
// overwrite the DH result in memory, no longer needed
input_key_material = (all zeros)
// Output 1
// Set a new chaining key from the temp key
// byte() below means a single byte
ck = HMAC-SHA256(temp_key, byte(0x01)).
// Output 2
// Generate the cipher key k
Define k = 32 bytes
// || below means append
// byte() below means a single byte
k = HMAC-SHA256(temp_key, ck || byte(0x02)).
// overwrite the temp_key in memory, no longer needed
temp_key = (all zeros)
// retain the chaining key ck for message 2 KDF
End of "es" message pattern.
अतिरिक्त DPI चर्चा
Alice Bob को भेजती है।
Noise content: Alice का ephemeral key X Noise payload: 16 बाइट option block Non-noise payload: Random padding
(पेलोड सुरक्षा गुण)
XK(s, rs): Authentication Confidentiality
-> e, es 0 2
Authentication: None (0).
This payload may have been sent by any party, including an active attacker.
Confidentiality: 2.
Encryption to a known recipient, forward secrecy for sender compromise
only, vulnerable to replay. This payload is encrypted based only on DHs
involving the recipient's static key pair. If the recipient's static
private key is compromised, even at a later date, this payload can be
decrypted. This message can also be replayed, since there's no ephemeral
contribution from the recipient.
"e": Alice generates a new ephemeral key pair and stores it in the e
variable, writes the ephemeral public key as cleartext into the
message buffer, and hashes the public key along with the old h to
derive a new h.
"es": A DH is performed between the Alice's ephemeral key pair and the
Bob's static key pair. The result is hashed along with the old ck to
derive a new ck and k, and n is set to zero.
X value को payload indistinguishably और uniqueness सुनिश्चित करने के लिए encrypt किया जाता है, जो आवश्यक DPI countermeasures हैं। हम इसे प्राप्त करने के लिए AES encryption का उपयोग करते हैं, न कि elligator2 जैसे अधिक जटिल और धीमे विकल्पों का। Bob के router public key के लिए Asymmetric encryption बहुत धीमा होगा। AES encryption Bob के router hash को key के रूप में और network database में published Bob के IV का उपयोग करता है।
AES encryption केवल DPI प्रतिरोध के लिए है। Bob के router hash और IV को जानने वाला कोई भी पक्ष, जो network database में प्रकाशित हैं, इस संदेश में X मान को decrypt कर सकता है।
पैडिंग Alice द्वारा encrypted नहीं किया जाता है। Bob के लिए पैडिंग को decrypt करना आवश्यक हो सकता है, timing attacks को रोकने के लिए।
कच्ची सामग्री:
+----+----+----+----+----+----+----+----+
| |
+ obfuscated with RH_B +
| AES-CBC-256 encrypted X |
+ (32 bytes) +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
| |
+ +
| ChaChaPoly frame |
+ (32 bytes) +
| k defined in KDF for message 1 |
+ n = 0 +
| see KDF for associated data |
+----+----+----+----+----+----+----+----+
| unencrypted authenticated |
~ padding (optional) ~
| length defined in options block |
+----+----+----+----+----+----+----+----+
X :: 32 bytes, AES-256-CBC encrypted X25519 ephemeral key, little endian
key: RH_B
iv: As published in Bobs network database entry
padding :: Random data, 0 or more bytes.
Total message length must be 65535 bytes or less.
Total message length must be 287 bytes or less if
Bob is publishing his address as NTCP
(see Version Detection section below).
Alice and Bob will use the padding data in the KDF for message 2.
It is authenticated so that any tampering will cause the
next message to fail.
अनएन्क्रिप्टेड डेटा (Poly1305 प्रमाणीकरण टैग दिखाया नहीं गया):
+----+----+----+----+----+----+----+----+
| |
+ +
| X |
+ (32 bytes) +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
| options |
+ (16 bytes) +
| |
+----+----+----+----+----+----+----+----+
| unencrypted authenticated |
+ padding (optional) +
| length defined in options block |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
X :: 32 bytes, X25519 ephemeral key, little endian
options :: options block, 16 bytes, see below
padding :: Random data, 0 or more bytes.
Total message length must be 65535 bytes or less.
Total message length must be 287 bytes or less if
Bob is publishing his address as "NTCP"
(see Version Detection section below)
Alice and Bob will use the padding data in the KDF for message 2.
It is authenticated so that any tampering will cause the
next message to fail.
Options block: नोट: सभी fields big-endian हैं।
+----+----+----+----+----+----+----+----+
| id | ver| padLen | m3p2len | Rsvd(0) |
+----+----+----+----+----+----+----+----+
| tsA | Reserved (0) |
+----+----+----+----+----+----+----+----+
id :: 1 byte, the network ID (currently 2, except for test networks)
As of 0.9.42. See proposal 147.
ver :: 1 byte, protocol version (currently 2)
padLen :: 2 bytes, length of the padding, 0 or more
Min/max guidelines TBD. Random size from 0 to 31 bytes minimum?
(Distribution to be determined, see Appendix A.)
m3p2Len :: 2 bytes, length of the the second AEAD frame in SessionConfirmed
(message 3 part 2) See notes below
Rsvd :: 2 bytes, set to 0 for compatibility with future options
tsA :: 4 bytes, Unix timestamp, unsigned seconds.
Wraps around in 2106
Reserved :: 4 bytes, set to 0 for compatibility with future options
Notes
जब प्रकाशित पता “NTCP” है, तो Bob एक ही पोर्ट पर NTCP और NTCP2 दोनों को समर्थित करता है। संगतता के लिए, जब “NTCP” के रूप में प्रकाशित पते से कनेक्शन शुरू करते समय, Alice को इस संदेश के अधिकतम आकार को, padding सहित, 287 bytes या उससे कम तक सीमित करना चाहिए। यह Bob द्वारा स्वचालित प्रोटोकॉल पहचान को सुविधाजनक बनाता है। जब “NTCP2” के रूप में प्रकाशित किया जाता है, तो कोई आकार प्रतिबंध नहीं है। नीचे Published Addresses और Version Detection अनुभाग देखें।
प्रारंभिक AES block में अद्वितीय X मान यह सुनिश्चित करता है कि ciphertext प्रत्येक session के लिए अलग हो।
Bob को उन connections को reject करना होगा जहाँ timestamp value current time से बहुत अधिक अलग है। अधिकतम delta time को “D” कहते हैं। Bob को पहले से उपयोग किए गए handshake values का एक local cache maintain करना होगा और duplicates को reject करना होगा, ताकि replay attacks को रोका जा सके। Cache में values का lifetime कम से कम 2*D होना चाहिए। Cache values implementation-dependent हैं, हालांकि 32-byte X value (या इसका encrypted equivalent) का उपयोग किया जा सकता है।
Diffie-Hellman ephemeral keys का कभी भी पुन: उपयोग नहीं किया जा सकता, cryptographic attacks को रोकने के लिए, और पुन: उपयोग को replay attack के रूप में अस्वीकार कर दिया जाएगा।
“KE” और “auth” विकल्प संगत होने चाहिए, यानी साझा गुप्त K उचित आकार का होना चाहिए। यदि और “auth” विकल्प जोड़े जाते हैं, तो यह अंततः “KE” फ्लैग के अर्थ को बदलकर एक अलग KDF या एक अलग truncation size का उपयोग करने के लिए बदल सकता है।
Bob को यहाँ यह validate करना होगा कि Alice की ephemeral key curve पर एक valid point है।
Padding को एक उचित मात्रा तक सीमित होना चाहिए। Bob अत्यधिक padding वाले connections को अस्वीकार कर सकता है। Bob अपने padding options को message 2 में निर्दिष्ट करेगा। Min/max guidelines TBD। 0 से 31 bytes minimum तक random size? (Distribution निर्धारित किया जाना है, Appendix A देखें।)
किसी भी error पर, AEAD, DH, timestamp, apparent replay, या key validation failure सहित, Bob को आगे की message processing रोकनी चाहिए और बिना response दिए connection को close करना चाहिए। यह एक abnormal close (TCP RST) होना चाहिए। Probing resistance के लिए, AEAD failure के बाद, Bob को एक random timeout (range TBD) set करना चाहिए और फिर random number of bytes (range TBD) read करना चाहिए, socket को close करने से पहले।
DoS शमन: DH एक अपेक्षाकृत महंगा ऑपरेशन है। पिछले NTCP प्रोटोकॉल की तरह, router को CPU या कनेक्शन थकावट को रोकने के लिए सभी आवश्यक उपाय करने चाहिए। अधिकतम सक्रिय कनेक्शन और प्रगति में अधिकतम कनेक्शन सेटअप पर सीमा लगाएं। रीड टाइमआउट लागू करें (प्रति-रीड और “slowloris” के लिए कुल दोनों)। एक ही स्रोत से बार-बार या एकसाथ कनेक्शन को सीमित करें। बार-बार विफल होने वाले स्रोतों के लिए ब्लैकलिस्ट बनाए रखें। AEAD विफलता का जवाब न दें।
तीव्र version detection और handshaking को सुविधाजनक बनाने के लिए, implementations को यह सुनिश्चित करना चाहिए कि Alice पहले message की संपूर्ण सामग्री को buffer करे और फिर padding सहित एक साथ flush करे। इससे इस बात की संभावना बढ़ जाती है कि डेटा एक single TCP packet में समाहित हो (जब तक OS या middleboxes द्वारा segmented न हो), और Bob द्वारा एक साथ प्राप्त हो। इसके अतिरिक्त, implementations को यह सुनिश्चित करना चाहिए कि Bob दूसरे message की संपूर्ण सामग्री को buffer करे और फिर padding सहित एक साथ flush करे। और यह कि Bob तीसरे message की संपूर्ण सामग्री को buffer करे और एक साथ flush करे। यह भी efficiency के लिए और random padding की प्रभावशीलता सुनिश्चित करने के लिए है।
“ver” फील्ड: समग्र Noise protocol, extensions, और NTCP protocol जिसमें payload specifications शामिल हैं, NTCP2 का संकेत देता है। यह फील्ड भविष्य के बदलावों के लिए समर्थन का संकेत देने के लिए उपयोग किया जा सकता है।
Message 3 part 2 length: यह दूसरे AEAD frame का आकार है (16-byte MAC सहित) जिसमें Alice की Router Info और वैकल्पिक padding होती है जो SessionConfirmed message में भेजी जाएगी। चूंकि router समय-समय पर अपनी Router Info को पुनर्जनित और पुनर्प्रकाशित करते हैं, वर्तमान Router Info का आकार message 3 भेजे जाने से पहले बदल सकता है। implementations को दो रणनीतियों में से एक चुनना होगा: a) वर्तमान Router Info को save करें जो message 3 में भेजी जानी है, ताकि आकार पता हो, और वैकल्पिक रूप से padding के लिए जगह जोड़ें; b) निर्दिष्ट आकार को पर्याप्त बढ़ाएं ताकि Router Info के आकार में संभावित वृद्धि की अनुमति हो, और जब message 3 वास्तव में भेजा जाए तो हमेशा padding जोड़ें। दोनों मामलों में, message 1 में शामिल “m3p2len” length उस frame के वास्तविक आकार के बिल्कुल बराबर होना चाहिए जब वह message 3 में भेजा जाए।
Bob को कनेक्शन को fail करना चाहिए यदि message 1 को validate करने और padding को पढ़ने के बाद कोई भी incoming data बचा रहता है। Alice से कोई extra data नहीं होना चाहिए, क्योंकि Bob ने अभी तक message 2 के साथ respond नहीं किया है।
नेटवर्क ID फ़ील्ड का उपयोग क्रॉस-नेटवर्क कनेक्शन्स को तुरंत पहचानने के लिए किया जाता है। यदि यह फ़ील्ड nonzero है, और Bob के नेटवर्क ID से मैच नहीं करता, तो Bob को डिस्कनेक्ट करना चाहिए और भविष्य के कनेक्शन्स को ब्लॉक करना चाहिए। 0.9.42 के अनुसार। अधिक जानकारी के लिए proposal 147 देखें।
Key Derivation Function (KDF) (for handshake message 2 and message 3 part 1)
// take h saved from message 1 KDF
// MixHash(ciphertext)
h = SHA256(h || 32 byte encrypted payload from message 1)
// MixHash(padding)
// Only if padding length is nonzero
h = SHA256(h || random padding from message 1)
This is the "e" message pattern:
Bob generates his ephemeral DH key pair e.
// h is from KDF for handshake message 1
// Bob ephemeral key Y
// MixHash(e.pubkey)
// || below means append
h = SHA256(h || e.pubkey);
// h is used as the associated data for the AEAD in message 2
// Retain the Hash h for the message 3 KDF
End of "e" message pattern.
This is the "ee" message pattern:
// DH(e, re)
Define input_key_material = 32 byte DH result of Alice's ephemeral key and Bob's ephemeral key
Set input_key_material = X25519 DH result
// overwrite Alice's ephemeral key in memory, no longer needed
// Alice:
e(public and private) = (all zeros)
// Bob:
re = (all zeros)
// MixKey(DH())
Define temp_key = 32 bytes
Define HMAC-SHA256(key, data) as in [RFC-2104](https://tools.ietf.org/html/rfc2104)
// Generate a temp key from the chaining key and DH result
// ck is the chaining key, from the KDF for handshake message 1
temp_key = HMAC-SHA256(ck, input_key_material)
// overwrite the DH result in memory, no longer needed
input_key_material = (all zeros)
// Output 1
// Set a new chaining key from the temp key
// byte() below means a single byte
ck = HMAC-SHA256(temp_key, byte(0x01)).
// Output 2
// Generate the cipher key k
Define k = 32 bytes
// || below means append
// byte() below means a single byte
k = HMAC-SHA256(temp_key, ck || byte(0x02)).
// overwrite the temp_key in memory, no longer needed
temp_key = (all zeros)
// retain the chaining key ck for message 3 KDF
End of "ee" message pattern.
2) SessionCreated
Bob, Alice को भेजता है।
Noise content: Bob की ephemeral key Y Noise payload: 16 byte विकल्प ब्लॉक Non-noise payload: यादृच्छिक पैडिंग
(पेलोड सुरक्षा गुण)
XK(s, rs): Authentication Confidentiality
<- e, ee 2 1
Authentication: 2.
Sender authentication resistant to key-compromise impersonation (KCI).
The sender authentication is based on an ephemeral-static DH ("es" or "se")
between the sender's static key pair and the recipient's ephemeral key pair.
Assuming the corresponding private keys are secure, this authentication cannot be forged.
Confidentiality: 1.
Encryption to an ephemeral recipient.
This payload has forward secrecy, since encryption involves an ephemeral-ephemeral DH ("ee").
However, the sender has not authenticated the recipient,
so this payload might be sent to any party, including an active attacker.
"e": Bob generates a new ephemeral key pair and stores it in the e variable,
writes the ephemeral public key as cleartext into the message buffer,
and hashes the public key along with the old h to derive a new h.
"ee": A DH is performed between the Bob's ephemeral key pair and the Alice's ephemeral key pair.
The result is hashed along with the old ck to derive a new ck and k, and n is set to zero.
Y मान को payload की अविभेद्यता और विशिष्टता सुनिश्चित करने के लिए एन्क्रिप्ट किया जाता है, जो आवश्यक DPI प्रतिरोधी उपाय हैं। हम इसे प्राप्त करने के लिए AES एन्क्रिप्शन का उपयोग करते हैं, न कि elligator2 जैसे अधिक जटिल और धीमे विकल्पों का। Alice के router public key के लिए असमित्रिक एन्क्रिप्शन बहुत धीमा होगा। AES एन्क्रिप्शन Bob के router hash को key के रूप में उपयोग करता है और message 1 से AES state का उपयोग करता है (जिसे Bob के IV के साथ प्रारंभ किया गया था जैसा कि network database में प्रकाशित है)।
AES एन्क्रिप्शन केवल DPI प्रतिरोध के लिए है। कोई भी पार्टी जो Bob के router hash और IV को जानती है, जो network database में प्रकाशित हैं, और message 1 के पहले 32 bytes को कैप्चर करती है, इस message में Y value को decrypt कर सकती है।
कच्ची सामग्री:
+----+----+----+----+----+----+----+----+
| |
+ obfuscated with RH_B +
| AES-CBC-256 encrypted Y |
+ (32 bytes) +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
| ChaChaPoly frame |
+ Encrypted and authenticated data +
| 32 bytes |
+ k defined in KDF for message 2 +
| n = 0; see KDF for associated data |
+ +
| |
+----+----+----+----+----+----+----+----+
| unencrypted authenticated |
+ padding (optional) +
| length defined in options block |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
Y :: 32 bytes, AES-256-CBC encrypted X25519 ephemeral key, little endian
key: RH_B
iv: Using AES state from message 1
अनएन्क्रिप्टेड डेटा (Poly1305 auth tag दिखाया नहीं गया):
+----+----+----+----+----+----+----+----+
| |
+ +
| Y |
+ (32 bytes) +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
| options |
+ (16 bytes) +
| |
+----+----+----+----+----+----+----+----+
| unencrypted authenticated |
+ padding (optional) +
| length defined in options block |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
Y :: 32 bytes, X25519 ephemeral key, little endian
options :: options block, 16 bytes, see below
padding :: Random data, 0 or more bytes.
Total message length must be 65535 bytes or less.
Alice and Bob will use the padding data in the KDF for message 3 part 1.
It is authenticated so that any tampering will cause the
next message to fail.
Notes
Alice को यहाँ यह validate करना होगा कि Bob की ephemeral key curve पर एक valid point है।
Padding को एक उचित मात्रा तक सीमित रखना चाहिए। Alice अत्यधिक padding वाले connections को reject कर सकती है। Alice अपने padding options को message 3 में specify करेगी। Min/max guidelines TBD। 0 से 31 bytes minimum तक का random size? (Distribution निर्धारित किया जाना है, Appendix A देखें।)
किसी भी त्रुटि पर, जिसमें AEAD, DH, timestamp, स्पष्ट replay, या key validation failure शामिल है, Alice को आगे की message processing रोकनी चाहिए और बिना जवाब दिए connection बंद करना चाहिए। यह एक असामान्य बंद होना चाहिए (TCP RST)।
तीव्र handshaking को सुविधाजनक बनाने के लिए, implementations को यह सुनिश्चित करना चाहिए कि Bob पहले message की संपूर्ण सामग्री को buffer करे और फिर एक साथ flush करे, जिसमें padding भी शामिल हो। इससे इस बात की संभावना बढ़ जाती है कि data एक single TCP packet में समाहित होगा (जब तक कि OS या middleboxes द्वारा segment न किया जाए), और Alice द्वारा एक साथ प्राप्त होगा। यह efficiency के लिए भी है और random padding की प्रभावशीलता सुनिश्चित करने के लिए भी है।
Alice को कनेक्शन को fail करना चाहिए यदि message 2 को validate करने और padding को पढ़ने के बाद कोई incoming data बचा रह जाता है। Bob से कोई extra data नहीं होना चाहिए, क्योंकि Alice ने अभी तक message 3 के साथ respond नहीं किया है।
Options block: नोट: सभी फ़ील्ड big-endian हैं।
+----+----+----+----+----+----+----+----+
| Rsvd(0) | padLen | Reserved (0) |
+----+----+----+----+----+----+----+----+
| tsB | Reserved (0) |
+----+----+----+----+----+----+----+----+
Reserved :: 10 bytes total, set to 0 for compatibility with future options
padLen :: 2 bytes, big endian, length of the padding, 0 or more
Min/max guidelines TBD. Random size from 0 to 31 bytes minimum?
(Distribution to be determined, see Appendix A.)
tsB :: 4 bytes, big endian, Unix timestamp, unsigned seconds.
Wraps around in 2106
Notes
- Alice को उन connections को reject करना चाहिए जहाँ timestamp value current time से बहुत अधिक different है। maximum delta time को “D” कहते हैं। Alice को previously-used handshake values का एक local cache maintain करना चाहिए और duplicates को reject करना चाहिए, ताकि replay attacks को prevent किया जा सके। Cache में values का lifetime कम से कम 2*D होना चाहिए। Cache values implementation-dependent हैं, हालांकि 32-byte Y value (या इसका encrypted equivalent) का उपयोग किया जा सकता है।
Issues
- यहाँ min/max padding विकल्प शामिल करें?
Encryption for for handshake message 3 part 1, using message 2 KDF)
// take h saved from message 2 KDF
// MixHash(ciphertext)
h = SHA256(h || 24 byte encrypted payload from message 2)
// MixHash(padding)
// Only if padding length is nonzero
h = SHA256(h || random padding from message 2)
// h is used as the associated data for the AEAD in message 3 part 1, below
This is the "s" message pattern:
Define s = Alice's static public key, 32 bytes
// EncryptAndHash(s.publickey)
// EncryptWithAd(h, s.publickey)
// AEAD_ChaCha20_Poly1305(key, nonce, associatedData, data)
// k is from handshake message 1
// n is 1
ciphertext = AEAD_ChaCha20_Poly1305(k, n++, h, s.publickey)
// MixHash(ciphertext)
// || below means append
h = SHA256(h || ciphertext);
// h is used as the associated data for the AEAD in message 3 part 2
End of "s" message pattern.
Key Derivation Function (KDF) (for handshake message 3 part 2)
This is the "se" message pattern:
// DH(s, re) == DH(e, rs)
Define input_key_material = 32 byte DH result of Alice's static key and Bob's ephemeral key
Set input_key_material = X25519 DH result
// overwrite Bob's ephemeral key in memory, no longer needed
// Alice:
re = (all zeros)
// Bob:
e(public and private) = (all zeros)
// MixKey(DH())
Define temp_key = 32 bytes
Define HMAC-SHA256(key, data) as in [RFC-2104](https://tools.ietf.org/html/rfc2104)
// Generate a temp key from the chaining key and DH result
// ck is the chaining key, from the KDF for handshake message 1
temp_key = HMAC-SHA256(ck, input_key_material)
// overwrite the DH result in memory, no longer needed
input_key_material = (all zeros)
// Output 1
// Set a new chaining key from the temp key
// byte() below means a single byte
ck = HMAC-SHA256(temp_key, byte(0x01)).
// Output 2
// Generate the cipher key k
Define k = 32 bytes
// || below means append
// byte() below means a single byte
k = HMAC-SHA256(temp_key, ck || byte(0x02)).
// h from message 3 part 1 is used as the associated data for the AEAD in message 3 part 2
// EncryptAndHash(payload)
// EncryptWithAd(h, payload)
// AEAD_ChaCha20_Poly1305(key, nonce, associatedData, data)
// n is 0
ciphertext = AEAD_ChaCha20_Poly1305(k, n++, h, payload)
// MixHash(ciphertext)
// || below means append
h = SHA256(h || ciphertext);
// retain the chaining key ck for the data phase KDF
// retain the hash h for the data phase Additional Symmetric Key (SipHash) KDF
End of "se" message pattern.
// overwrite the temp_key in memory, no longer needed
temp_key = (all zeros)
3) SessionConfirmed
Alice, Bob को भेजती है।
Noise content: Alice की static key Noise payload: Alice का RouterInfo और random padding Non-noise payload: कोई नहीं
(पेलोड सुरक्षा गुण)
XK(s, rs): Authentication Confidentiality
-> s, se 2 5
Authentication: 2.
Sender authentication resistant to key-compromise impersonation (KCI). The
sender authentication is based on an ephemeral-static DH ("es" or "se")
between the sender's static key pair and the recipient's ephemeral key
pair. Assuming the corresponding private keys are secure, this
authentication cannot be forged.
Confidentiality: 5.
Encryption to a known recipient, strong forward secrecy. This payload is
encrypted based on an ephemeral-ephemeral DH as well as an ephemeral-static
DH with the recipient's static key pair. Assuming the ephemeral private
keys are secure, and the recipient is not being actively impersonated by an
attacker that has stolen its static private key, this payload cannot be
decrypted.
"s": Alice writes her static public key from the s variable into the
message buffer, encrypting it, and hashes the output along with the old h
to derive a new h.
"se": A DH is performed between the Alice's static key pair and the Bob's
ephemeral key pair. The result is hashed along with the old ck to derive a
new ck and k, and n is set to zero.
इसमें दो ChaChaPoly frames होते हैं। पहला Alice की encrypted static public key है। दूसरा Noise payload है: Alice का encrypted RouterInfo, वैकल्पिक options, और वैकल्पिक padding। ये अलग keys का उपयोग करते हैं, क्योंकि बीच में MixKey() function को call किया जाता है।
कच्ची सामग्री:
+----+----+----+----+----+----+----+----+
| |
+ ChaChaPoly frame (48 bytes) +
| Encrypted and authenticated |
+ Alice static key S +
| (32 bytes) |
+ +
| k defined in KDF for message 2 |
+ n = 1 +
| see KDF for associated data |
+ +
| |
+----+----+----+----+----+----+----+----+
| |
+ Length specified in message 1 +
| |
+ ChaChaPoly frame +
| Encrypted and authenticated |
+ +
| Alice RouterInfo |
+ using block format 2 +
| Alice Options (optional) |
+ using block format 1 +
| Arbitrary padding |
+ using block format 254 +
| |
+ +
| k defined in KDF for message 3 part 2 |
+ n = 0 +
| see KDF for associated data |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
S :: 32 bytes, ChaChaPoly encrypted Alice's X25519 static key, little endian
inside 48 byte ChaChaPoly frame
अनएन्क्रिप्टेड डेटा (Poly1305 auth tags नहीं दिखाए गए):
+----+----+----+----+----+----+----+----+
| |
+ +
| S |
+ Alice static key +
| (32 bytes) |
+ +
| |
+ +
+----+----+----+----+----+----+----+----+
| |
+ +
| |
+ +
| Alice RouterInfo block |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
| |
+ Optional Options block +
| |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
| |
+ Optional Padding block +
| |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
S :: 32 bytes, Alice's X25519 static key, little endian
1) ऑनलाइन DPI
Bob को सामान्य Router Info validation करना चाहिए। सुनिश्चित करें कि signature type समर्थित है, signature को verify करें, timestamp सीमा के भीतर है यह verify करें, और कोई भी अन्य आवश्यक जांच करें।
Bob को यह सत्यापित करना होगा कि पहले frame में प्राप्त Alice की static key, Router Info में static key से मेल खाती है। Bob को पहले Router Info में matching version (v) option के साथ NTCP या NTCP2 Router Address खोजना होगा। नीचे Published Router Info और Unpublished Router Info sections देखें।
यदि Bob के netdb में Alice की RouterInfo का पुराना version है, तो verify करें कि router info में static key दोनों में समान है, यदि present है, और यदि पुराना version XXX से कम पुराना है (नीचे key rotate time देखें)
Bob को यहाँ validate करना चाहिए कि Alice की static key curve पर एक valid point है।
विकल्प शामिल किए जाने चाहिए, padding parameters निर्दिष्ट करने के लिए।
किसी भी error पर, जिसमें AEAD, RI, DH, timestamp, या key validation failure शामिल है, Bob को आगे की message processing रोकनी चाहिए और बिना जवाब दिए connection बंद करना चाहिए। यह एक abnormal close (TCP RST) होना चाहिए।
तीव्र handshaking की सुविधा के लिए, implementations को यह सुनिश्चित करना चाहिए कि Alice तीसरे message की संपूर्ण contents को buffer करे और फिर एक साथ flush करे, दोनों AEAD frames सहित। इससे इस बात की संभावना बढ़ जाती है कि data एक ही TCP packet में समाहित हो (जब तक कि OS या middleboxes द्वारा segmented न हो), और Bob द्वारा एक साथ प्राप्त हो। यह efficiency के लिए भी है और random padding की प्रभावशीलता सुनिश्चित करने के लिए भी।
Message 3 part 2 frame length: इस frame की लंबाई (MAC सहित) Alice द्वारा message 1 में भेजी जाती है। padding के लिए पर्याप्त स्थान की अनुमति देने पर महत्वपूर्ण नोट्स के लिए उस message को देखें।
Message 3 part 2 frame content: इस frame का format data phase frames के format के समान है, सिवाय इसके कि frame की length Alice द्वारा message 1 में भेजी जाती है। data phase frame format के लिए नीचे देखें। Frame में निम्नलिखित क्रम में 1 से 3 blocks होने चाहिए:
- Alice’s Router Info block (आवश्यक)
- Options block (वैकल्पिक)
- Padding block (वैकल्पिक) यह frame कभी भी किसी अन्य block type को contain नहीं कर सकता।
यदि Alice संदेश 3 के अंत में एक data phase frame (जिसमें वैकल्पिक रूप से padding हो सकती है) जोड़ती है और दोनों को एक साथ भेजती है, तो Message 3 part 2 padding की आवश्यकता नहीं है, क्योंकि यह एक observer को bytes की एक बड़ी stream के रूप में दिखाई देगा। चूंकि Alice के पास आम तौर पर, लेकिन हमेशा नहीं, Bob को भेजने के लिए एक I2NP message होता है (इसीलिए वह उससे जुड़ी), यह recommended implementation है, efficiency के लिए और random padding की प्रभावशीलता सुनिश्चित करने के लिए।
दोनों Message 3 AEAD frames (part 1 और 2) की कुल लंबाई 65535 bytes है; part 1 48 bytes का है इसलिए part 2 की अधिकतम frame लंबाई 65487 है; part 2 की MAC को छोड़कर अधिकतम plaintext लंबाई 65471 है।
Key Derivation Function (KDF) (for data phase)
डेटा phase zero-length associated data input का उपयोग करता है।
KDF, chaining key ck से दो cipher keys k_ab और k_ba उत्पन्न करता है, HMAC-SHA256(key, data) का उपयोग करके जैसा कि RFC-2104 में परिभाषित है। यह Split() function है, बिल्कुल वैसे ही जैसे Noise spec में परिभाषित है।
ck = from handshake phase
// k_ab, k_ba = HKDF(ck, zerolen)
// ask_master = HKDF(ck, zerolen, info="ask")
// zerolen is a zero-length byte array
temp_key = HMAC-SHA256(ck, zerolen)
// overwrite the chaining key in memory, no longer needed
ck = (all zeros)
// Output 1
// cipher key, for Alice transmits to Bob (Noise doesn't make clear which is which, but Java code does)
k_ab = HMAC-SHA256(temp_key, byte(0x01)).
// Output 2
// cipher key, for Bob transmits to Alice (Noise doesn't make clear which is which, but Java code does)
k_ba = HMAC-SHA256(temp_key, k_ab || byte(0x02)).
KDF for SipHash for length field:
Generate an Additional Symmetric Key (ask) for SipHash
SipHash uses two 8-byte keys (big endian) and 8 byte IV for first data.
// "ask" is 3 bytes, US-ASCII, no null termination
ask_master = HMAC-SHA256(temp_key, "ask" || byte(0x01))
// sip_master = HKDF(ask_master, h || "siphash")
// "siphash" is 7 bytes, US-ASCII, no null termination
// overwrite previous temp_key in memory
// h is from KDF for message 3 part 2
temp_key = HMAC-SHA256(ask_master, h || "siphash")
// overwrite ask_master in memory, no longer needed
ask_master = (all zeros)
sip_master = HMAC-SHA256(temp_key, byte(0x01))
Alice to Bob SipHash k1, k2, IV:
// sipkeys_ab, sipkeys_ba = HKDF(sip_master, zerolen)
// overwrite previous temp_key in memory
temp_key = HMAC-SHA256(sip_master, zerolen)
// overwrite sip_master in memory, no longer needed
sip_master = (all zeros)
sipkeys_ab = HMAC-SHA256(temp_key, byte(0x01)).
sipk1_ab = sipkeys_ab[0:7], little endian
sipk2_ab = sipkeys_ab[8:15], little endian
sipiv_ab = sipkeys_ab[16:23]
Bob to Alice SipHash k1, k2, IV:
sipkeys_ba = HMAC-SHA256(temp_key, sipkeys_ab || byte(0x02)).
sipk1_ba = sipkeys_ba[0:7], little endian
sipk2_ba = sipkeys_ba[8:15], little endian
sipiv_ba = sipkeys_ba[16:23]
// overwrite the temp_key in memory, no longer needed
temp_key = (all zeros)
4) Data Phase
Noise payload: जैसा कि नीचे परिभाषित है, random padding सहित Non-noise payload: कोई नहीं
संदेश 3 के दूसरे भाग से शुरू करके, सभी संदेश एक authenticated और encrypted ChaChaPoly “frame” के अंदर होते हैं जिसमें दो-बाइट obfuscated length पहले से जुड़ी होती है। सभी padding frame के अंदर होती है। Frame के अंदर एक मानक प्रारूप होता है जिसमें शून्य या अधिक “blocks” होते हैं। प्रत्येक block में एक एक-बाइट प्रकार और दो-बाइट लंबाई होती है। प्रकारों में date/time, I2NP message, options, termination, और padding शामिल हैं।
नोट: Bob अपने RouterInfo को Alice को data phase में Alice के लिए अपने पहले संदेश के रूप में भेज सकता है, लेकिन यह आवश्यक नहीं है।
(Payload Security Properties)
XK(s, rs): Authentication Confidentiality
<- 2 5
-> 2 5
Authentication: 2.
Sender authentication resistant to key-compromise impersonation (KCI).
The sender authentication is based on an ephemeral-static DH ("es" or "se")
between the sender's static key pair and the recipient's ephemeral key pair.
Assuming the corresponding private keys are secure, this authentication cannot be forged.
Confidentiality: 5.
Encryption to a known recipient, strong forward secrecy.
This payload is encrypted based on an ephemeral-ephemeral DH as well as
an ephemeral-static DH with the recipient's static key pair.
Assuming the ephemeral private keys are secure, and the recipient is not being actively impersonated
by an attacker that has stolen its static private key, this payload cannot be decrypted.
2) ऑफलाइन DPI
दक्षता के लिए और लेंथ फील्ड की पहचान को न्यूनतम करने के लिए, implementations को सुनिश्चित करना चाहिए कि sender डेटा संदेशों की संपूर्ण सामग्री को बफर करे और फिर एक साथ flush करे, जिसमें लेंथ फील्ड और AEAD frame शामिल हो। यह इस संभावना को बढ़ाता है कि डेटा एक ही TCP packet में समाहित होगा (जब तक कि OS या middleboxes द्वारा segmented न किया जाए), और दूसरी पार्टी द्वारा एक साथ प्राप्त होगा। यह भी दक्षता के लिए है और random padding की प्रभावशीलता सुनिश्चित करने के लिए है।
राउटर AEAD त्रुटि पर सत्र को समाप्त करने का विकल्प चुन सकता है, या संचार जारी रखने का प्रयास कर सकता है। यदि जारी रख रहा है, तो राउटर को बार-बार त्रुटियों के बाद समाप्त कर देना चाहिए।
SipHash obfuscated length
संदर्भ: SipHash
जब दोनों पक्षों ने handshake पूरा कर लिया होता है, तो वे payloads को स्थानांतरित करते हैं जो फिर ChaChaPoly “frames” में एन्क्रिप्ट और authenticated किए जाते हैं।
प्रत्येक frame से पहले दो-बाइट length होती है, big endian में। यह length उन encrypted frame bytes की संख्या निर्दिष्ट करती है जो आगे आने वाले हैं, MAC सहित। stream में पहचानने योग्य length fields को transmit करने से बचने के लिए, frame length को SipHash से derived mask के साथ XOR करके obfuscate किया जाता है, जैसा कि data phase KDF से initialize किया गया है। ध्यान दें कि दोनों directions में KDF से unique SipHash keys और IVs होती हैं।
sipk1, sipk2 = The SipHash keys from the KDF. (two 8-byte long integers)
IV[0] = sipiv = The SipHash IV from the KDF. (8 bytes)
length is big endian.
For each frame:
IV[n] = SipHash-2-4(sipk1, sipk2, IV[n-1])
Mask[n] = First 2 bytes of IV[n]
obfuscatedLength = length ^ Mask[n]
The first length output will be XORed with with IV[1].
रिसीवर के पास समान SipHash keys और IV होते हैं। लेंथ को डिकोड करना mask को derive करके किया जाता है जो लेंथ को obfuscate करने के लिए उपयोग किया गया था और truncated digest को XOR करके frame की लेंथ प्राप्त की जाती है। Frame लेंथ MAC सहित encrypted frame की कुल लेंथ होती है।
भविष्य का कार्य
- यदि आप एक SipHash library function का उपयोग करते हैं जो एक unsigned long integer return करता है, तो Mask के रूप में least significant two bytes का उपयोग करें। Long integer को next IV के रूप में little endian में convert करें।
प्रमाणीकृत एन्क्रिप्शन
+----+----+----+----+----+----+----+----+
|obf size | |
+----+----+ +
| |
+ ChaChaPoly frame +
| Encrypted and authenticated |
+ key is k_ab for Alice to Bob +
| key is k_ba for Bob to Alice |
+ as defined in KDF for data phase +
| n starts at 0 and increments |
+ for each frame in that direction +
| no associated data |
+ 16 bytes minimum +
| |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
obf size :: 2 bytes length obfuscated with SipHash
when de-obfuscated: 16 - 65535
Minimum size including length field is 18 bytes.
Maximum size including length field is 65537 bytes.
Obfuscated length is 2 bytes.
Maximum ChaChaPoly frame is 65535 bytes.
ChaCha20/Poly1305
एन्क्रिप्टेड frame में शून्य या अधिक blocks होते हैं। प्रत्येक block में एक one-byte identifier, एक two-byte length, और शून्य या अधिक bytes का data होता है।
विस्तारशीलता के लिए, receivers को अज्ञात identifiers वाले blocks को अनदेखा करना चाहिए, और उन्हें padding की तरह treat करना चाहिए।
एन्क्रिप्टेड डेटा अधिकतम 65535 बाइट्स का होता है, जिसमें 16-बाइट authentication header शामिल है, इसलिए अधिकतम unencrypted डेटा 65519 बाइट्स का होता है।
(Poly1305 auth tag दिखाया नहीं गया):
+----+----+----+----+----+----+----+----+
|blk | size | data |
+----+----+----+ +
| |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
|blk | size | data |
+----+----+----+ +
| |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
~ . . . ~
blk :: 1 byte
0 for datetime
1 for options
2 for RouterInfo
3 for I2NP message
4 for termination
224-253 reserved for experimental features
254 for padding
255 reserved for future extension
size :: 2 bytes, big endian, size of data to follow, 0 - 65516
data :: the data
Maximum ChaChaPoly frame is 65535 bytes.
Poly1305 tag is 16 bytes
Maximum total block size is 65519 bytes
Maximum single block size is 65519 bytes
Block type is 1 byte
Block length is 2 bytes
Maximum single block data size is 65516 bytes.
Block Ordering Rules
handshake संदेश 3 भाग 2 में, क्रम होना चाहिए: RouterInfo, इसके बाद Options यदि मौजूद है, इसके बाद Padding यदि मौजूद है। कोई अन्य blocks की अनुमति नहीं है।
डेटा चरण में, क्रम अनिर्दिष्ट है, निम्नलिखित आवश्यकताओं को छोड़कर: Padding, यदि मौजूद है, तो अंतिम block होना चाहिए। Termination, यदि मौजूद है, तो Padding को छोड़कर अंतिम block होना चाहिए।
एक single frame में कई I2NP blocks हो सकते हैं। एक single frame में कई Padding blocks की अनुमति नहीं है। अन्य block types में शायद ही एक single frame में कई blocks होंगे, लेकिन यह प्रतिबंधित नहीं है।
AEAD एरर हैंडलिंग
समय सिंक्रोनाइज़ेशन के लिए विशेष स्थिति:
+----+----+----+----+----+----+----+
| 0 | 4 | timestamp |
+----+----+----+----+----+----+----+
blk :: 0
size :: 2 bytes, big endian, value = 4
timestamp :: Unix timestamp, unsigned seconds.
Wraps around in 2106
Key Derivation Function (KDF) (handshake संदेश 1 के लिए)
अपडेटेड विकल्प पास करें। विकल्पों में शामिल हैं: न्यूनतम और अधिकतम padding।
विकल्प ब्लॉक परिवर्तनीय लंबाई का होगा।
+----+----+----+----+----+----+----+----+
| 1 | size |tmin|tmax|rmin|rmax|tdmy|
+----+----+----+----+----+----+----+----+
|tdmy| rdmy | tdelay | rdelay | |
~----+----+----+----+----+----+----+ ~
| more_options |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
blk :: 1
size :: 2 bytes, big endian, size of options to follow, 12 bytes minimum
tmin, tmax, rmin, rmax :: requested padding limits
tmin and rmin are for desired resistance to traffic analysis.
tmax and rmax are for bandwidth limits.
tmin and tmax are the transmit limits for the router sending this options block.
rmin and rmax are the receive limits for the router sending this options block.
Each is a 4.4 fixed-point float representing 0 to 15.9375
(or think of it as an unsigned 8-bit integer divided by 16.0).
This is the ratio of padding to data. Examples:
Value of 0x00 means no padding
Value of 0x01 means add 6 percent padding
Value of 0x10 means add 100 percent padding
Value of 0x80 means add 800 percent (8x) padding
Alice and Bob will negotiate the minimum and maximum in each direction.
These are guidelines, there is no enforcement.
Sender should honor receiver's maximum.
Sender may or may not honor receiver's minimum, within bandwidth constraints.
tdmy: Max dummy traffic willing to send, 2 bytes big endian, bytes/sec average
rdmy: Requested dummy traffic, 2 bytes big endian, bytes/sec average
tdelay: Max intra-message delay willing to insert, 2 bytes big endian, msec average
rdelay: Requested intra-message delay, 2 bytes big endian, msec average
Padding distribution specified as additional parameters?
Random delay specified as additional parameters?
more_options :: Format TBD
1) SessionRequest
- Options प्रारूप TBD है।
- Options बातचीत TBD है।
RouterInfo
Alice की RouterInfo को Bob के पास भेजें। handshake message 3 part 2 में उपयोग किया जाता है। Alice की RouterInfo को Bob के पास, या Bob की को Alice के पास भेजें। data phase में वैकल्पिक रूप से उपयोग किया जाता है।
+----+----+----+----+----+----+----+----+
| 2 | size |flg | RouterInfo |
+----+----+----+----+ +
| (Alice RI in handshake msg 3 part 2) |
~ (Alice, Bob, or third-party ~
| RI in data phase) |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
blk :: 2
size :: 2 bytes, big endian, size of flag + router info to follow
flg :: 1 byte flags
bit order: 76543210
bit 0: 0 for local store, 1 for flood request
bits 7-1: Unused, set to 0 for future compatibility
routerinfo :: Alice's or Bob's RouterInfo
Notes
जब data phase में उपयोग किया जाता है, तो receiver (Alice या Bob) को यह validate करना चाहिए कि यह वही Router Hash है जो originally भेजा गया था (Alice के लिए) या भेजा गया था (Bob के लिए)। फिर, इसे एक local I2NP DatabaseStore Message के रूप में treat करें। signature को validate करें, अधिक recent timestamp को validate करें, और local netDb में store करें। यदि flag bit 0 है 1, और receiving party floodfill है, तो इसे nonzero reply token के साथ एक DatabaseStore Message के रूप में treat करें, और इसे nearest floodfills में flood करें।
Router Info को gzip के साथ compress नहीं किया जाता है (DatabaseStore Message के विपरीत, जहाँ यह compress होता है)
Flooding तब तक अनुरोध नहीं करनी चाहिए जब तक कि RouterInfo में प्रकाशित RouterAddresses न हों। प्राप्तकर्ता router को RouterInfo को flood नहीं करना चाहिए जब तक कि उसमें प्रकाशित RouterAddresses न हों।
इम्प्लीमेंटर्स को यह सुनिश्चित करना चाहिए कि जब किसी ब्लॉक को पढ़ा जा रहा हो, तो गलत तरीके से बनाया गया या दुर्भावनापूर्ण डेटा अगले ब्लॉक में पढ़ने की प्रक्रिया को ओवररन नहीं करने देगा।
यह protocol इस बात की acknowledgement प्रदान नहीं करता कि RouterInfo प्राप्त हुआ, store हुआ, या flood हुआ (handshake या data phase में से किसी में भी)। यदि acknowledgement चाहिए, और receiver floodfill है, तो sender को इसके बजाय एक standard I2NP DatabaseStoreMessage reply token के साथ भेजना चाहिए।
Issues
डेटा फेज में भी इस्तेमाल किया जा सकता है, I2NP DatabaseStoreMessage के बजाय। उदाहरण के लिए, Bob इसका उपयोग डेटा फेज शुरू करने के लिए कर सकता है।
क्या इसमें originator के अलावा अन्य routers के लिए RI को शामिल करने की अनुमति है, DatabaseStoreMessages के सामान्य प्रतिस्थापन के रूप में, जैसे कि floodfills द्वारा flooding के लिए?
Key Derivation Function (KDF) (handshake message 2 और message 3 part 1 के लिए)
एक संशोधित हेडर के साथ एकल I2NP संदेश। I2NP संदेशों को blocks या ChaChaPoly frames में विभाजित नहीं किया जा सकता।
यह मानक NTCP I2NP header से पहले 9 bytes का उपयोग करता है, और header के अंतिम 7 bytes को हटा देता है, निम्नानुसार: expiration को 8 से 4 bytes तक truncate करें, 2 byte length को हटाएं (block size - 9 का उपयोग करें), और एक-byte SHA256 checksum को हटाएं।
+----+----+----+----+----+----+----+----+
| 3 | size |type| msg id |
+----+----+----+----+----+----+----+----+
| short exp | message |
+----+----+----+----+ +
| |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
blk :: 3
size :: 2 bytes, big endian, size of type + msg id + exp + message to follow
I2NP message body size is (size - 9).
type :: 1 byte, I2NP msg type, see I2NP spec
msg id :: 4 bytes, big endian, I2NP message ID
short exp :: 4 bytes, big endian, I2NP message expiration, Unix timestamp, unsigned seconds.
Wraps around in 2106
message :: I2NP message body
Notes
- कार्यान्वयनकर्ताओं को यह सुनिश्चित करना चाहिए कि जब एक block पढ़ा जा रहा हो, तो दुर्भावनापूर्ण या गलत तरीके से बना डेटा अगले block में overrun का कारण नहीं बनेगा।
2) SessionCreated
Noise एक स्पष्ट termination संदेश की सिफारिश करता है। मूल NTCP में यह नहीं है। कनेक्शन को drop करें। यह frame में अंतिम non-padding block होना चाहिए।
+----+----+----+----+----+----+----+----+
| 4 | size | valid data frames |
+----+----+----+----+----+----+----+----+
received | rsn| addl data |
+----+----+----+----+ +
~ . . . ~
+----+----+----+----+----+----+----+----+
blk :: 4
size :: 2 bytes, big endian, value = 9 or more
valid data frames received :: The number of valid AEAD data phase frames received
(current receive nonce value)
0 if error occurs in handshake phase
8 bytes, big endian
rsn :: reason, 1 byte:
0: normal close or unspecified
1: termination received
2: idle timeout
3: router shutdown
4: data phase AEAD failure
5: incompatible options
6: incompatible signature type
7: clock skew
8: padding violation
9: AEAD framing error
10: payload format error
11: message 1 error
12: message 2 error
13: message 3 error
14: intra-frame read timeout
15: RI signature verification fail
16: s parameter missing, invalid, or mismatched in RouterInfo
17: banned
addl data :: optional, 0 or more bytes, for future expansion, debugging,
or reason text.
Format unspecified and may vary based on reason code.
Notes
सभी कारण वास्तव में उपयोग नहीं किए जा सकते हैं, यह implementation पर निर्भर करता है। Handshake failures आमतौर पर TCP RST के साथ close का परिणाम होंगे। ऊपर handshake message sections में नोट्स देखें। सूचीबद्ध अतिरिक्त कारण consistency, logging, debugging, या यदि policy changes के लिए हैं।
Padding
यह AEAD frames के अंदर padding के लिए है। Messages 1 और 2 के लिए padding AEAD frames के बाहर होती है। Message 3 और data phase के लिए सभी padding AEAD frames के अंदर होती है।
AEAD के अंदर padding को negotiated parameters का मोटे तौर पर पालन करना चाहिए। Bob ने message 2 में अपने requested tx/rx min/max parameters भेजे थे। Alice ने message 3 में अपने requested tx/rx min/max parameters भेजे थे। Data phase के दौरान updated options भेजे जा सकते हैं। ऊपर दी गई options block जानकारी देखें।
यदि उपस्थित है, तो यह frame में अंतिम block होना चाहिए।
+----+----+----+----+----+----+----+----+
|254 | size | padding |
+----+----+----+ +
| |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
blk :: 254
size :: 2 bytes, big endian, size of padding to follow
padding :: random data
Notes
- Padding रणनीतियां TBD।
- न्यूनतम padding TBD।
- केवल-padding फ्रेम की अनुमति है।
- Padding डिफ़ॉल्ट TBD।
- Padding पैरामीटर बातचीत के लिए options ब्लॉक देखें
- न्यूनतम/अधिकतम padding पैरामीटर के लिए options ब्लॉक देखें
- Noise संदेशों को 64KB तक सीमित करता है। यदि अधिक padding आवश्यक है, तो एकाधिक फ्रेम भेजें।
- बातचीत किए गए padding के उल्लंघन पर router प्रतिक्रिया कार्यान्वयन-निर्भर है।
Other block types
Implementation को forward compatibility के लिए अज्ञात block types को ignore करना चाहिए, सिवाय message 3 part 2 के, जहाँ अज्ञात blocks की अनुमति नहीं है।
Future work
- पैडिंग लंबाई का निर्णय प्रति-संदेश आधार पर और लंबाई वितरण के अनुमानों के आधार पर किया जाना है, या यादृच्छिक देरी जोड़ी जानी चाहिए। ये प्रतिरोधी उपाय DPI का विरोध करने के लिए शामिल किए जाने हैं, क्योंकि संदेश का आकार अन्यथा यह प्रकट कर देगा कि I2P ट्रैफिक transport protocol द्वारा ले जाया जा रहा है। सटीक पैडिंग स्कीम भविष्य के कार्य का क्षेत्र है, परिशिष्ट A इस विषय पर अधिक जानकारी प्रदान करता है।
5) Termination
कनेक्शन को सामान्य या असामान्य TCP socket close के माध्यम से समाप्त किया जा सकता है, या, जैसा कि Noise सुझाता है, एक स्पष्ट termination message के माध्यम से। स्पष्ट termination message को ऊपर data phase में परिभाषित किया गया है।
किसी भी सामान्य या असामान्य समाप्ति पर, router को किसी भी in-memory ephemeral डेटा को शून्य कर देना चाहिए, जिसमें handshake ephemeral keys, symmetric crypto keys और संबंधित जानकारी शामिल है।
Published Router Info
हैंडशेक संदेश 3 भाग 1 के लिए एन्क्रिप्शन, संदेश 2 KDF का उपयोग करते हुए)
प्रकाशित RouterAddress (RouterInfo का हिस्सा) में “NTCP” या “NTCP2” में से कोई एक protocol identifier होगा।
RouterAddress में “host” और “port” विकल्प होने चाहिए, जैसे कि वर्तमान NTCP प्रोटोकॉल में हैं।
RouterAddress में NTCP2 समर्थन को इंगित करने के लिए तीन विकल्प होने चाहिए:
s=(Base64 key) इस RouterAddress के लिए वर्तमान Noise static public key (s)। मानक I2P Base 64 वर्णमाला का उपयोग करके Base 64 में एन्कोड किया गया। बाइनरी में 32 bytes, Base 64 एन्कोड्ड के रूप में 44 bytes, little-endian X25519 public key।
i=(Base64 IV) इस RouterAddress के लिए संदेश 1 में X मान को एन्क्रिप्ट करने के लिए वर्तमान IV। मानक I2P Base 64 वर्णमाला का उपयोग करके Base 64 एन्कोडेड। बाइनरी में 16 बाइट्स, Base 64 एन्कोडेड के रूप में 24 बाइट्स, big-endian।
v=2 वर्तमान संस्करण (2)। जब “NTCP” के रूप में प्रकाशित किया जाता है, तो संस्करण 1 के लिए अतिरिक्त समर्थन निहित है। भविष्य के संस्करणों के लिए समर्थन कॉमा-अलग किए गए मानों के साथ होगा, उदाहरण v=2,3 Implementation को संगतता सत्यापित करनी चाहिए, यदि कॉमा मौजूद है तो एकाधिक संस्करणों सहित। कॉमा-अलग किए गए संस्करण संख्यात्मक क्रम में होने चाहिए।
Alice को NTCP2 protocol का उपयोग करके कनेक्ट करने से पहले यह सत्यापित करना होगा कि सभी तीन विकल्प उपस्थित और वैध हैं।
जब “s”, “i”, और “v” विकल्पों के साथ “NTCP” के रूप में प्रकाशित किया जाता है, तो router को उस host और port पर NTCP और NTCP2 दोनों protocols के लिए incoming connections स्वीकार करना चाहिए, और protocol version को स्वचालित रूप से detect करना चाहिए।
जब “NTCP2” के रूप में “s”, “i”, और “v” विकल्पों के साथ प्रकाशित किया जाता है, तो router उस host और port पर केवल NTCP2 protocol के लिए आने वाले connections को स्वीकार करता है।
यदि कोई router NTCP1 और NTCP2 दोनों connections को support करता है लेकिन incoming connections के लिए automatic version detection implement नहीं करता है, तो उसे “NTCP” और “NTCP2” दोनों addresses advertise करने चाहिए, और NTCP2 options को केवल “NTCP2” address में शामिल करना चाहिए। Router को “NTCP2” address में “NTCP” address की तुलना में कम cost value (उच्च priority) सेट करनी चाहिए, ताकि NTCP2 को प्राथमिकता मिले।
यदि एकाधिक NTCP2 RouterAddresses (“NTCP” या “NTCP2” के रूप में) समान RouterInfo में प्रकाशित किए गए हैं (अतिरिक्त IP addresses या ports के लिए), तो समान port निर्दिष्ट करने वाले सभी addresses में समान NTCP2 options और values होने चाहिए। विशेष रूप से, सभी में समान static key और iv होना चाहिए।
Key Derivation Function (KDF) (handshake संदेश 3 भाग 2 के लिए)
यदि Alice अपने NTCP2 address को incoming connections के लिए (“NTCP” या “NTCP2” के रूप में) publish नहीं करती है, तो उसे एक “NTCP2” router address publish करना चाहिए जिसमें केवल उसकी static key और NTCP2 version हो, ताकि Bob message 3 part 2 में Alice का RouterInfo प्राप्त करने के बाद key को validate कर सके।
s=(Base64 key) जैसा कि ऊपर प्रकाशित पतों के लिए परिभाषित किया गया है।
v=2 जैसा कि ऊपर प्रकाशित पतों के लिए परिभाषित किया गया है।
इस router address में “i”, “host” या “port” विकल्प शामिल नहीं होंगे, क्योंकि ये outbound NTCP2 connections के लिए आवश्यक नहीं हैं। इस address के लिए प्रकाशित cost का सख्त महत्व नहीं है, क्योंकि यह केवल inbound है; हालांकि, अन्य routers के लिए यह सहायक हो सकता है यदि cost को अन्य addresses की तुलना में अधिक (कम प्राथमिकता) सेट किया जाए। सुझाया गया मान 14 है।
Alice एक मौजूदा प्रकाशित “NTCP” पते में केवल “s” और “v” विकल्प भी जोड़ सकती है।
3) SessionConfirmed
RouterInfos की caching के कारण, routers को static public key या IV को rotate नहीं करना चाहिए जब तक router चालू है, चाहे वह published address में हो या न हो। Routers को इस key और IV को persistently store करना चाहिए ताकि immediate restart के बाद पुन: उपयोग हो सके, जिससे incoming connections काम करते रहें, और restart times expose न हों। Routers को last-shutdown time को persistently store करना चाहिए, या अन्यथा निर्धारित करना चाहिए, ताकि startup पर पिछले downtime की गणना की जा सके।
रीस्टार्ट समय को उजागर करने की चिंताओं के अधीन, router इस key या IV को startup पर rotate कर सकते हैं यदि router पहले कुछ समय के लिए down था (कम से कम कुछ घंटे)।
यदि router के पास कोई भी प्रकाशित NTCP2 RouterAddresses हैं (NTCP या NTCP2 के रूप में), तो rotation से पहले न्यूनतम downtime काफी लंबा होना चाहिए, उदाहरण के लिए एक महीना, जब तक कि local IP address नहीं बदला है या router “rekeys” नहीं करता।
यदि router के पास कोई भी प्रकाशित SSU RouterAddresses हैं, लेकिन NTCP2 (NTCP या NTCP2 के रूप में) नहीं है, तो रोटेशन से पहले न्यूनतम डाउनटाइम लंबा होना चाहिए, उदाहरण के लिए एक दिन, जब तक कि स्थानीय IP address नहीं बदला है या router “rekeys” नहीं करता। यह तब भी लागू होता है जब प्रकाशित SSU address में introducers हों।
यदि router के पास कोई प्रकाशित RouterAddresses (NTCP, NTCP2, या SSU) नहीं हैं, तो rotation से पहले न्यूनतम downtime दो घंटे जितना कम हो सकता है, भले ही IP address बदल जाए, जब तक कि router “rekeys” नहीं करता।
यदि router एक अलग Router Hash के लिए “rekeys” करता है, तो उसे एक नया noise key और IV भी generate करना चाहिए।
इम्प्लीमेंटेशन को इस बात से अवगत होना चाहिए कि static public key या IV को बदलने से उन routers से आने वाले NTCP2 connections रुक जाएंगे जिन्होंने पुराना RouterInfo cache किया है। RouterInfo publishing, tunnel peer selection (OBGW और IB closest hop दोनों सहित), zero-hop tunnel selection, transport selection, और अन्य implementation रणनीतियों में इस बात का ध्यान रखना होगा।
IV rotation वही नियमों के अधीन है जो key rotation के हैं, सिवाय इसके कि IVs केवल प्रकाशित RouterAddresses में मौजूद होते हैं, इसलिए छुपे हुए या firewalled routers के लिए कोई IV नहीं होता। यदि कुछ भी बदलता है (version, key, options?) तो यह अनुशंसित है कि IV भी बदल जाए।
नोट: rekeying से पहले न्यूनतम downtime को नेटवर्क स्वास्थ्य सुनिश्चित करने के लिए संशोधित किया जा सकता है, और मध्यम समय के लिए down रहे router द्वारा reseeding को रोकने के लिए।
Identity Hiding
इनकार करना कोई लक्ष्य नहीं है। ऊपर दिया गया अवलोकन देखें।
प्रत्येक pattern को properties assign की जाती हैं जो initiator की static public key को प्रदान की जाने वाली confidentiality का वर्णन करती हैं, और responder की static public key को भी। अंतर्निहित assumptions यह हैं कि ephemeral private keys secure हैं, और यदि parties को दूसरी party से कोई static public key प्राप्त होती है जिस पर वे भरोसा नहीं करते हैं तो वे handshake को abort कर देती हैं।
यह खंड केवल handshake में static public key fields के माध्यम से identity leakage पर विचार करता है। निश्चित रूप से, Noise participants की पहचान अन्य माध्यमों से भी उजागर हो सकती है, जिसमें payload fields, traffic analysis, या IP addresses जैसे metadata शामिल हैं।
Alice: (8) एक प्रमाणित पार्टी के लिए forward secrecy के साथ एन्क्रिप्टेड।
Bob: (3) प्रेषित नहीं किया गया, लेकिन एक passive attacker responder की private key के लिए candidates की जांच कर सकता है और यह निर्धारित कर सकता है कि candidate सही है या नहीं।
Bob अपनी static public key को netdb में publish करता है। Alice कर सकती है या नहीं भी कर सकती?
Issues
- यदि Bob अपनी static key बदल देता है, तो क्या “XX” pattern पर fallback हो सकता है?
Noise Protocol Framework
जब “NTCP” के रूप में प्रकाशित किया जाता है, तो router को incoming connections के लिए protocol version का स्वचालित रूप से पता लगाना चाहिए।
यह detection implementation-dependent है, लेकिन यहाँ कुछ सामान्य मार्गदर्शन है।
आने वाले NTCP connection के version का पता लगाने के लिए, Bob निम्नलिखित प्रक्रिया अपनाता है:
कम से कम 64 bytes की प्रतीक्षा करें (न्यूनतम NTCP2 संदेश 1 आकार)
यदि प्रारंभिक प्राप्त डेटा 288 या अधिक bytes है, तो आने वाला कनेक्शन version 1 है।
यदि 288 bytes से कम है, तो या तो
अधिक डेटा के लिए थोड़ा समय प्रतीक्षा करें (व्यापक NTCP2 अपनाने से पहले अच्छी रणनीति) यदि कम से कम 288 कुल प्राप्त हुआ है, तो यह NTCP 1 है।
डिकोडिंग के पहले चरणों को version 2 के रूप में आज़माएं, यदि यह असफल हो जाता है, तो अधिक डेटा के लिए थोड़ा समय प्रतीक्षा करें (व्यापक NTCP2 अपनाने के बाद अच्छी रणनीति)
- Decrypt the first 32 bytes (the X key) of the SessionRequest packet using AES-256 with key RH_B. - Verify a valid point on the curve. If it fails, wait a short time for more data for NTCP 1 - Verify the AEAD frame. If it fails, wait a short time for more data for NTCP 1
ध्यान दें कि यदि हम NTCP 1 पर सक्रिय TCP segmentation हमलों का पता लगाते हैं तो अतिरिक्त रणनीतियों या परिवर्तनों की सिफारिश की जा सकती है।
तेज़ version detection और handshaking को सुविधाजनक बनाने के लिए, implementations को यह सुनिश्चित करना चाहिए कि Alice पहले message की संपूर्ण सामग्री को buffer करे और फिर एक साथ flush करे, padding सहित। इससे इस बात की संभावना बढ़ जाती है कि data एक ही TCP packet में समाहित होगा (जब तक कि OS या middleboxes द्वारा segment न किया जाए), और Bob द्वारा एक साथ प्राप्त किया जाएगा। यह efficiency के लिए भी है और random padding की प्रभावशीलता सुनिश्चित करने के लिए भी। यह NTCP और NTCP2 दोनों handshakes पर लागू होता है।
फ्रेमवर्क में जोड़े गए
यदि Alice और Bob दोनों NTCP2 को support करते हैं, तो Alice को NTCP2 के साथ connect करना चाहिए।
यदि Alice किसी भी कारण से NTCP2 का उपयोग करके Bob से कनेक्ट करने में असफल हो जाता है, तो कनेक्शन विफल हो जाता है। Alice NTCP 1 का उपयोग करके पुनः प्रयास नहीं कर सकती।
यदि Bob अपनी keys बदलता है तो XX pattern पर fallback करना? इसके लिए एक type byte prepended की आवश्यकता होगी?
यदि Alice पुनः कनेक्ट होती है तो KK pattern पर “Fall forward” करें, यह मानते हुए कि Bob के पास अभी भी उसकी static key है? यह कोई round trips नहीं बचाता और XK के 3 की तुलना में 4 DH rounds का उपयोग करता है। शायद नहीं।
KK(s, rs):
-> s
<- s
...
-> e, es, ss
<- e, ee, se
I2P के लिए नए क्रिप्टोग्राफिक प्रिमिटिव्स
यह खंड सामान्य padding schemes पर एक हमले पर चर्चा करता है जो आक्रमणकारियों को केवल padded messages की लंबाई को देखकर unpadded messages की लंबाई के probability distribution की खोज करने की अनुमति देता है। मान लेते हैं कि N एक random variable है जो unpadded bytes की संख्या का वर्णन करता है, और P इसी तरह padding bytes की संख्या के लिए है। कुल message size तब N + P होता है।
मान लीजिए कि n के unpadded size के लिए, एक padding scheme में कम से कम P_min(n) >= 0 और अधिकतम P_max(n) >= P_min(n) bytes की padding जोड़ी जाती है। स्पष्ट scheme P लंबाई की padding का उपयोग करती है जो समान रूप से यादृच्छिक रूप से चुनी जाती है:
Pr[P = p | N = n] = 1 / (P_max(n) - P_min(n)) if P_min(n) <= p <= P_max(n),
0 otherwise.
एक सरल padding योजना केवल यह सुनिश्चित करेगी कि padded संदेश का आकार N_max से अधिक न हो:
P_max(n) = N_max - n, n <= N_max
P_min(n) = 0.
हालांकि, यह unpadded length के बारे में जानकारी लीक करता है।
एक आक्रमणकारी आसानी से Pr[x <= N + P <= y] का अनुमान लगा सकता है, उदाहरण के लिए histogram के माध्यम से।
- इससे, वह
Pr[n_1 <= N <= n_2]का अनुमान लगाने का भी प्रयास कर सकता है, वास्तव में:
Pr[N + P = m] = Σ_n Pr[N = n] Pr[P = m - n | N = n].
सरल योजना में,
Pr[N + P = m] = Σ_{n <= m} Pr[N = n] / (N_max - n).
यह काफी स्पष्ट है, जैसा कि उपरोक्त गणना करने से पहले भी था, कि यह Pr[N = n] के बारे में जानकारी लीक करता है: यदि packets की लंबाई लगभग हमेशा m से अधिक होती है, तो N + P <= m का अवलोकन लगभग कभी नहीं किया जाएगा। हालांकि यह सबसे बड़ी समस्या नहीं है, लेकिन न्यूनतम message length का अवलोकन करने में सक्षम होना अपने आप में एक समस्या माना जा सकता है।
एक बड़ी समस्या यह है कि Pr[N = n] को सटीक रूप से निर्धारित करना संभव है:
Pr[N + P = m] - Pr[N + P = m-1] = Pr[N = m] / (N_max - m),
वह है
Pr[N = n] = (N_max - n)(Pr[N + P = n] - Pr[N + P = n - 1])
NTCP2 को अलग करने के लिए, हमलावर निम्नलिखित में से किसी का भी उपयोग कर सकता है:
सकारात्मक पूर्णांक k के लिए
Pr[kB <= N <= (k + 1)B - 1]का अनुमान लगाएं। NTCP2 के लिए यह हमेशा शून्य होगा।Pr[N = kB]का अनुमान लगाएं और एक मानक I2P profile के साथ तुलना करें।
यह सरल हमला इस प्रकार padding के उद्देश्य को आंशिक रूप से नष्ट कर देता है, जो unpadded संदेशों के आकार वितरण को अस्पष्ट बनाने का प्रयास करता है। प्रोटोकॉल को पहचानने के लिए हमलावर को जितने संदेशों का अवलोकन करना पड़ता है, वह वांछित सटीकता और व्यावहारिक रूप से होने वाले न्यूनतम और अधिकतम unpadded संदेश आकारों पर निर्भर करता है। ध्यान दें कि हमलावर के लिए कई संदेश एकत्र करना आसान है, क्योंकि वह उस विशेष port से आने-जाने वाले सभी ट्रैफिक का उपयोग कर सकता है जिसका लक्ष्य उपयोग कर रहा है।
कुछ रूपों में (जैसे Pr[kB <= N <= (k + 1)B - 1] का अनुमान) इस हमले को केवल कुछ बाइट्स मेमोरी की आवश्यकता होती है (एक integer काफी है) और यह तर्क दिया जा सकता है कि ऐसा हमला कई थोड़े अधिक उन्नत लेकिन फिर भी मानक DPI फ्रेमवर्क में शामिल किया जा सकता है।
यह प्रस्ताव निम्नलिखित में से किसी एक प्रतिकारी उपाय का उपयोग करने का सुझाव देता है:
एक वैकल्पिक padding scheme विकसित करें जो N के (अनुमानित) distribution को ध्यान में रखते हुए एक non-uniform padding length distribution का उपयोग करे। एक अच्छी padding scheme के लिए संभवतः प्रति message blocks की संख्या का histogram बनाए रखना आवश्यक होगा।
संदेशों के (यादृच्छिक आकार के) fragments के बीच यादृच्छिक देरी जोड़ें।
दूसरा विकल्प आम तौर पर अधिक प्राथमिकता दिया जाता है, क्योंकि इसे flow analysis के विरुद्ध प्रतिरोधी उपाय के रूप में एक साथ उपयोग किया जा सकता है। हालांकि, ऐसी देरी NTCP2 protocol के दायरे से बाहर हो सकती है, जिसके कारण पहला विकल्प, जो कि implement करना भी आसान है, इसके बजाय प्राथमिकता दी जा सकती है।
प्रसंस्करण ओवरहेड अनुमान
टाइमिंग-आधारित DPI प्रतिरोध (संदेशों के बीच timing/delays implementation-dependent हो सकते हैं; संदेश के भीतर delays किसी भी बिंदु पर पेश किए जा सकते हैं, जैसे कि random padding भेजने से पहले, उदाहरण के लिए)। कृत्रिम delays (जिसे obfs4 में IAT या inter-arrival time कहा जाता है) protocol से स्वतंत्र होते हैं।