हाय सब लोग, मंगलवार फिर से आ गया

  • Index
  1. नेटवर्क स्थिति 2) _PRE नेटवर्क प्रगति 3) I2Phex 0.1.1.37 4) ???
    1. Net status

पिछले सप्ताह के दौरान लाइव नेटवर्क में कोई महत्वपूर्ण बदलाव नहीं हुए हैं, इसलिए लाइव नेटवर्क की स्थिति में भी ज्यादा बदलाव नहीं आया है। दूसरी ओर…

    1. _PRE net progress

पिछले सप्ताह मैंने 0.6.1.10 रिलीज़ के लिए पिछले संस्करणों के साथ असंगत कोड को CVS में एक अलग ब्रांच (i2p_0_6_1_10_PRE) पर कमिट करना शुरू किया, और स्वयंसेवकों के एक समूह ने इसे टेस्ट करने में मदद की। यह नया _PRE नेटवर्क लाइव नेट से संचार नहीं कर सकता, और इसमें कोई सार्थक गुमनामी नहीं है (क्योंकि इसमें 10 से कम पीयर्स हैं)। उन routers से pen register logs (Pen Register लॉग—कनेक्शन/मेटाडेटा के रिकॉर्ड) के साथ, नए और पुराने दोनों कोड में कुछ बड़े बगों का पता लगाकर उन्हें ठीक कर दिया गया है, हालांकि आगे का परीक्षण और सुधार जारी है।

नई tunnel निर्माण क्रिप्टोग्राफी का एक पहलू यह है कि निर्माता को प्रत्येक hop (मध्यवर्ती चरण) के लिए पहले से ही भारी असममित एन्क्रिप्शन करना पड़ता है, जबकि पुराने tunnel निर्माण में एन्क्रिप्शन तभी किया जाता था जब पिछला hop tunnel में भाग लेने के लिए सहमत होता था। यह एन्क्रिप्शन स्थानीय CPU प्रदर्शन और tunnel की लंबाई दोनों पर निर्भर करते हुए 400-1000ms या उससे अधिक समय ले सकता है (यह प्रत्येक hop के लिए पूर्ण ElGamal एन्क्रिप्शन करता है)। वर्तमान में _PRE net पर उपयोग में एक ऑप्टिमाइज़ेशन छोटा घातांक [1] का उपयोग है - ElGamal कुंजी के रूप में 2048bit ‘x’ का उपयोग करने के बजाय, हम 228bit ‘x’ का उपयोग करते हैं, जो विच्छिन्न लघुगणक समस्या के कम्प्यूटेशनल प्रयास से मेल खाने के लिए सुझाई गई लंबाई है। इससे प्रति-hop एन्क्रिप्शन समय एक परिमाण-क्रम तक घट गया है, हालांकि डिक्रिप्शन समय पर इसका प्रभाव नहीं पड़ता।

छोटे घातांकों के उपयोग को लेकर कई परस्पर-विरोधी विचार हैं, और सामान्य स्थिति में यह सुरक्षित नहीं है, लेकिन जितना मैं समझ पाया हूँ, चूँकि हम एक स्थिर safe prime (Oakley group 14 [2]) का उपयोग करते हैं, इसलिए q का आदेश ठीक होना चाहिए। फिर भी, यदि किसी के पास इस दिशा में और विचार हों, तो उन्हें सुनकर मुझे खुशी होगी।

एक बड़ा विकल्प 1024-बिट एन्क्रिप्शन पर स्विच करना है (जिसमें हम संभवतः 160-बिट का छोटा घातांक इस्तेमाल कर सकते हैं)। यह किसी भी स्थिति में उपयुक्त हो सकता है, और यदि _PRE net पर 2048-बिट एन्क्रिप्शन के साथ चीज़ें बहुत कठिन हो जाती हैं, तो हम _PRE net के भीतर ही यह स्विच कर सकते हैं। अन्यथा, हम 0.6.1.10 रिलीज़ तक प्रतीक्षा कर सकते हैं, जब नए क्रिप्टो का व्यापक परिनियोजन होगा, ताकि देख सकें कि यह आवश्यक है या नहीं। यदि ऐसा स्विच संभावित लगता है तो बहुत अधिक जानकारी उपलब्ध कराई जाएगी।

[1] “छोटे घातांकों के साथ Diffie-Hellman Key Agreement पर” - van Oorschot, Weiner EuroCrypt 96 में. मिरर यहाँ उपलब्ध http://dev.i2p.net/~jrandom/Euro96-DH.ps [2] http://www.ietf.org/rfc/rfc3526.txt

किसी भी स्थिति में, _PRE net पर काफी प्रगति हुई है, और इसके बारे में अधिकांश संचार irc2p पर #i2p_pre चैनल के भीतर किया जा रहा है।

    1. I2Phex 0.1.1.37

Complication ने नवीनतम I2Phex कोड को मर्ज और पैच कर gwebcaches का समर्थन जोड़ दिया है, जो Rawn के pycache port के साथ संगत है। इसका मतलब है कि उपयोगकर्ता I2Phex डाउनलोड कर सकते हैं, इसे इंस्टॉल करें, “Connect to the network” क्लिक करें, और एक-दो मिनट बाद यह मौजूदा I2Phex peers के कुछ संदर्भ ले लेगा और नेटवर्क से जुड़ जाएगा। अब i2phex.hosts फ़ाइलों को मैन्युअली मैनेज करने या कुंजियाँ मैन्युअली शेयर करने की झंझट नहीं (w00t)! डिफ़ॉल्ट रूप से दो gwebcaches होते हैं, लेकिन उन्हें बदला जा सकता है या तीसरा जोड़ा जा सकता है i2phex.cfg में i2pGWebCache0, i2pGWebCache1, या i2pGWebCache2 प्रॉपर्टीज़ को संशोधित करके।

बहुत बढ़िया काम, Complication और Rawn!

    1. ???

फिलहाल बस इतना ही, और यह अच्छी बात भी है, क्योंकि मैं पहले से ही बैठक के लिए देर से हूँ :) जल्द ही #i2p पर आप सब से मिलते हैं

=jr