नमस्ते सभी को, फिर से हफ्ते का वही समय आ गया है

  • Index
  1. squid/www/cvs/dev.i2p पुनर्स्थापित 2) SSU परीक्षण 3) I2CP कूटलेखन 4) ???
    1. squid/www/cvs/dev.i2p restored

कई colo बॉक्स (कोलोकेशन सर्वर) पर काफी जद्दोजहद करने के बाद, पुरानी सेवाओं में से कुछ बहाल कर दी गई हैं - squid.i2p (दो डिफ़ॉल्ट outproxies (बाहरी-निकास प्रॉक्सी) में से एक), www.i2p (www.i2p.net के लिए एक सुरक्षित पॉइंटर), dev.i2p (dev.i2p.net के लिए एक सुरक्षित पॉइंटर, जहाँ मेलिंग सूची अभिलेख, cvsweb, और डिफ़ॉल्ट netDb seeds मिलते हैं), और cvs.i2p (हमारे CVS सर्वर - cvs.i2p.net:2401 - के लिए एक सुरक्षित पॉइंटर)। मेरा ब्लॉग अभी भी गायब है, लेकिन इसकी सामग्री वैसे भी खो गई थी, इसलिए देर-सवेर नई शुरुआत करनी ही पड़ेगी। अब जबकि ये सेवाएँ भरोसेमंद रूप से फिर से ऑनलाइन हैं, तो आगे बढ़ने का समय आ गया है…

    1. SSU testing

जैसा कि हर किसी के router कंसोल पर उस छोटे पीले बॉक्स में उल्लेख किया गया है, हमने SSU के लिए लाइव नेटवर्क परीक्षण के अगले दौर की शुरुआत कर दी है। ये परीक्षण सभी के लिए नहीं हैं, लेकिन यदि आप प्रयोगधर्मी हैं और कुछ मैन्युअल कॉन्फ़िगरेशन करने में सहज हैं, तो अपने router कंसोल पर दिए गए विवरण देखें (http://localhost:7657/index.jsp)। परीक्षण के कई दौर हो सकते हैं, परंतु 0.6 रिलीज़ से पहले SSU में किसी बड़े बदलाव की मुझे उम्मीद नहीं है (0.6.1 उन उपयोगकर्ताओं के लिए समर्थन जोड़ेगा जो अपने पोर्ट्स को फॉरवर्ड नहीं कर सकते या अन्यथा इनबाउंड UDP कनेक्शन प्राप्त नहीं कर सकते)।

    1. I2CP crypto

नई प्रारंभिक दस्तावेज़ों पर फिर से काम करते हुए, मुझे I2CP SDK के भीतर लागू की गई अतिरिक्त एन्क्रिप्शन परत को उचित ठहराने में थोड़ी कठिनाई हो रही है। I2CP क्रिप्टो लेयर का मूल उद्देश्य प्रेषित संदेशों के लिए एक आधारभूत एंड-टू-एंड सुरक्षा प्रदान करना था, साथ ही I2CP क्लाइंट्स (उर्फ I2PTunnel, the SAM bridge, I2Phex, azneti2p, आदि) को अविश्वसनीय routers के माध्यम से संचार करने की अनुमति देना था। हालाँकि, जैसे-जैसे कार्यान्वयन आगे बढ़ा, I2CP लेयर की एंड-टू-एंड सुरक्षा अतिरिक्त हो गई, क्योंकि सभी क्लाइंट संदेश router द्वारा garlic messages के भीतर एंड-टू-एंड एन्क्रिप्ट किए जाते हैं, जिसमें प्रेषक का leaseSet और कभी-कभी एक डिलिवरी स्टेटस संदेश भी शामिल होता है। यह garlic लेयर पहले से ही प्रेषक के router से प्राप्तकर्ता के router तक एंड-टू-एंड एन्क्रिप्शन प्रदान करती है - फर्क केवल इतना है कि यह उस router के स्वयं दुर्भावनापूर्ण होने के विरुद्ध सुरक्षा नहीं देती।

हालाँकि, संभावित उपयोग मामलों को देखते हुए, मुझे ऐसा कोई वैध परिदृश्य नहीं सूझता जिसमें स्थानीय router पर भरोसा न किया जाए। कम-से-कम, I2CP crypto केवल router से प्रेषित संदेश की सामग्री को छिपाता है - router को अभी भी यह जानना होता है कि इसे किस गंतव्य पर भेजा जाना चाहिए। आवश्यकता होने पर, हम I2CP क्लाइंट और router को अलग-अलग मशीनों पर संचालित होने देने के लिए एक SSH/SSL I2CP लिस्नर जोड़ सकते हैं, या जिन्हें ऐसी व्यवस्था की आवश्यकता हो वे मौजूदा टनलिंग टूल्स का उपयोग कर सकते हैं।

सिर्फ यह दोहराने के लिए कि अभी कौन-सी क्रिप्टो लेयरिंग उपयोग में है, हमारे पास: * I2CP का एंड-टू-एंड ElGamal/AES+SessionTag लेयर, जो प्रेषक के गंतव्य से प्राप्तकर्ता के गंतव्य तक एन्क्रिप्ट करती है। * router का एंड-टू-एंड garlic encryption लेयर (ElGamal/AES+SessionTag), जो प्रेषक के router से प्राप्तकर्ता के router तक एन्क्रिप्ट करती है।

  • inbound और outbound दोनों tunnels के लिए tunnel encryption लेयर, जो प्रत्येक के साथ वाले हॉप्स पर लागू होती है (लेकिन outbound endpoint और inbound gateway के बीच नहीं)।
  • प्रत्येक router के बीच transport encryption लेयर।

मैं उन परतों में से किसी एक को हटाने को लेकर काफ़ी सतर्क रहना चाहता हूँ, लेकिन मैं अनावश्यक काम करके हमारे संसाधनों की बर्बादी नहीं करना चाहता। मेरा प्रस्ताव यह है कि हम पहली I2CP एन्क्रिप्शन परत को हटा दें (लेकिन निश्चित रूप से I2CP सत्र स्थापना के दौरान प्रयुक्त प्रमाणीकरण, leaseSet प्राधिकरण, और प्रेषक प्रमाणीकरण को बनाए रखें)। क्या कोई ऐसा कारण बता सकता है कि हमें इसे क्यों बनाए रखना चाहिए?

    1. ???

फ़िलहाल इतना ही, लेकिन हमेशा की तरह बहुत कुछ चल रहा है। इस हफ्ते भी कोई बैठक नहीं है, पर अगर किसी के पास उठाने के लिए कोई मुद्दा हो, तो कृपया बेझिझक उसे मेलिंग सूची पर भेजें या फ़ोरम पर पोस्ट करें। साथ ही, मैं #i2p में पिछली चैट लॉग पढ़ता हूँ, लेकिन सामान्य सवाल या चिंताएँ इसके बजाय मेलिंग सूची पर भेजी जानी चाहिए ताकि अधिक लोग चर्चा में भाग ले सकें।

=jr