हाय दोस्तों, हफ्ते का वही समय आ गया है,

  • Index
  1. विकास स्थिति 2) Tunnel IVs (आरंभिक वेक्टर) 3) SSU MACs (संदेश प्रमाणीकरण कोड) 4) ???
    1. Dev status

एक और हफ्ता, और एक और संदेश: “SSU ट्रांसपोर्ट पर काफ़ी प्रगति हुई है” ;) मेरे स्थानीय संशोधन स्थिर हैं और उन्हें CVS पर पुश कर दिया गया है (HEAD 0.5.0.7-9 पर है), लेकिन अभी रिलीज़ नहीं हुई है। उस मोर्चे पर जल्द ही और खबरें। इतिहास [1] में गैर-SSU संबंधित परिवर्तनों का विवरण उपलब्ध है, हालांकि फिलहाल मैं SSU से संबंधित बदलावों को उस सूची से बाहर ही रख रहा हूँ, क्योंकि SSU का उपयोग अभी किसी भी गैर-डेवलपर द्वारा नहीं किया जा रहा है (और डेवलपर्स i2p-cvs@ पढ़ते हैं :)

[1] http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD

    1. Tunnel IVs

पिछले कुछ दिनों से dvorak अलग-अलग तरीकों पर, जिनसे tunnel की क्रिप्टो पर हमला किया जा सकता है, कभी‑कभार विचार पोस्ट कर रहे हैं, और जबकि उनमें से अधिकांश पहले ही संबोधित किए जा चुके थे, हम एक ऐसा परिदृश्य निकाल पाए जो प्रतिभागियों को संदेशों की एक जोड़ी को टैग करने की अनुमति देता है ताकि यह निर्धारित किया जा सके कि वे उसी tunnel में हैं। इसका तरीका यह था कि पहले वाला peer (सहभागी नोड) किसी संदेश को अपने आगे जाने देता और बाद में उस पहले tunnel संदेश का IV और पहला डेटा ब्लॉक लेकर उन्हें एक नए संदेश में डाल देता। यह नया संदेश निश्चित रूप से दूषित होता, लेकिन वह replay (दोहराया गया संदेश/हमला) जैसा नहीं लगता, क्योंकि IV अलग होते। आगे चलकर, दूसरा peer उस संदेश को बस त्याग देता ताकि tunnel endpoint हमले का पता न लगा सके।

इसके पीछे के मूल मुद्दों में से एक यह है कि जब कोई tunnel संदेश tunnel के भीतर आगे बढ़ता है, तो उसे सत्यापित करने का कोई तरीका नहीं है, वह भी हमलों की पूरी श्रृंखला खोले बिना (देखें पहले का एक tunnel क्रिप्टो प्रस्ताव [2], जिसमें एक तरीका बताया गया है जो काफी करीब पहुँचता है, लेकिन उसकी संभावनाएँ काफी संदिग्ध हैं और वह tunnels पर कुछ कृत्रिम सीमाएँ थोपता है)।

[2] http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel.html?rev=HEAD

फिर भी, बताए गए इस विशेष हमले से निपटने का एक बहुत सरल तरीका है - IV को अकेले इस्तेमाल करने के बजाय xor(IV, first data block) को वह अद्वितीय पहचानकर्ता मानें जिसे bloom filter (ब्लूम फ़िल्टर) से गुजारा जाए। इस तरह, intermediate peers (पीयर्स) dup (डुप्लिकेट) को देखकर उसे दूसरे मिलीभगत वाले peer तक पहुँचने से पहले ही ड्रॉप कर देंगे। इस रक्षा को शामिल करने के लिए CVS अपडेट कर दिया गया है, हालांकि मौजूदा नेटवर्क आकार को देखते हुए मुझे बहुत, बहुत संदेह है कि यह कोई व्यावहारिक खतरा है, इसलिए मैं इसे अपने आप में एक रिलीज़ के रूप में जारी नहीं कर रहा हूँ।

हालाँकि इससे अन्य टाइमिंग या शेपिंग हमलों की व्यवहार्यता पर कोई प्रभाव नहीं पड़ता, लेकिन जब हमें ऐसे आसानी से संभाले जा सकने वाले हमले दिखें, तो उन्हें निपटा देना ही बेहतर है।

    1. SSU MACs

जैसा कि स्पेक [3] में वर्णित है, SSU ट्रांसपोर्ट प्रत्येक प्रेषित डाटाग्राम के लिए एक MAC का उपयोग करता है। यह प्रत्येक I2NP संदेश के साथ भेजे गए वेरिफिकेशन हैश के अतिरिक्त है (साथ ही क्लाइंट संदेशों पर एंड-टू-एंड वेरिफिकेशन हैश भी)। अभी, स्पेक और कोड एक ट्रंकेटेड HMAC-SHA256 का उपयोग करते हैं - MAC के केवल पहले 16 बाइट ट्रांसमिट और वेरिफाई किए जाते हैं। यह cough थोड़ा अपव्ययी है, क्योंकि HMAC अपने संचालन में SHA256 हैश को दो बार उपयोग करता है, हर बार 32-बाइट हैश के साथ चलता है, और SSU ट्रांसपोर्ट की हालिया प्रोफाइलिंग से संकेत मिलता है कि यह CPU लोड के क्रिटिकल पाथ (महत्वपूर्ण मार्ग) के करीब है। इसलिए, मैंने HMAC-SHA256-128 को साधारण HMAC-MD5(-128) से बदलने के साथ थोड़ा प्रयोग किया है - हालाँकि MD5 स्पष्ट रूप से SHA256 जितना मजबूत नहीं है, हम वैसे भी SHA256 को MD5 के समान आकार तक ट्रंकेट कर रहे हैं, इसलिए कोलिज़न (टकराव) के लिए आवश्यक ब्रूट-फोर्स की मात्रा समान रहती है (2^64 प्रयास)। मैं अभी इसके साथ प्रयोग कर रहा हूँ और स्पीडअप काफ़ी महत्वपूर्ण है (2KB पैकेट पर SHA256 की तुलना में HMAC थ्रूपुट 3x से अधिक मिल रहा है), तो संभव है कि हम इसके साथ ही लाइव जाएँ। या यदि कोई इसे न अपनाने का ठोस कारण (या कोई बेहतर विकल्प) दे सके, तो इसे बदलना भी काफ़ी आसान है (सिर्फ़ एक लाइन कोड)।

[3] http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/udp.html?rev=HEAD

    1. ???

अभी के लिए बस इतना ही, और हमेशा की तरह, आप कभी भी अपने विचार और चिंताएँ पोस्ट करने के लिए स्वतंत्र हैं। CVS HEAD (CVS का नवीनतम डेवलपमेंट हेड) अब फिर से build किया जा सकता है उन लोगों के लिए जिनके सिस्टम पर junit (Java unit testing framework) इंस्टॉल नहीं है (फिलहाल मैंने टेस्ट्स को i2p.jar से निकाल दिया है, लेकिन वे test ant target के साथ अभी भी रन किए जा सकते हैं), और मुझे उम्मीद है कि 0.6 की testing के बारे में काफी जल्द और खबरें मिलेंगी (मैं अभी भी colo box (डेटा सेंटर में कोलोकेटेड सर्वर) की अजीब हरकतों से जूझ रहा हूँ - मेरे अपने interfaces पर telnetting (telnet से कनेक्ट करना) लोकली फेल हो जाती है (कोई उपयोगी errno (एरर नंबर) नहीं मिलता), दूर से काम करती है, और यह सब बिना किसी iptables (Linux फ़ायरवॉल नियम) या अन्य फ़िल्टर के. वाह)। मैं अभी भी घर पर net access नहीं रखता, इसलिए आज रात की मीटिंग के लिए मौजूद नहीं रहूँगा, लेकिन शायद अगले हफ्ते।

=jr