I2P डेवलपर बैठक - 07 फ़रवरी 2006

15:36 <jrandom> 0) हाय 15:36 <jrandom> 1) नेट की स्थिति 15:36 <jrandom> 2) _PRE net प्रगति 15:36 <jrandom> 3) I2Phex 0.1.1.37 15:36 <jrandom> 4) ??? 15:36 <jrandom> 0) हाय 15:37 * jrandom हाथ हिलाता है 15:37 <jrandom> साप्ताहिक स्टेटस नोट्स यहाँ पोस्ट किए गए हैं @ http://dev.i2p.net/pipermail/i2p/2006-February/001258.html 15:37 <bar> हैलो 15:38 <jrandom> जब तक आप लोग उस बहुत-ही-रोमांचक सामग्री को खंगालते हैं, चलिए 1) नेट की स्थिति पर चलते हैं 15:38 <jrandom> पिछले हफ्ते live net पर, I2P के नज़रिये से, ज़्यादा बदलाव नहीं हुए हैं, तो यहाँ मेरे पास जोड़ने को ज़्यादा नहीं है 15:39 <jrandom> क्या किसी के पास वर्तमान नेट स्थिति के बारे में उठाने के लिए कुछ है? 15:39 <KBlup> मैंने I2P को लंबे समय तक चलाने पर फेल होते क्लाइंट्स के भयानक स्पाइक्स देखे हैं... पता नहीं ये 1) में फिट बैठता है या नहीं 15:39 <jrandom> KBlup: क्या उसका संबंध ऊँचे CPU लोड या बैंडविड्थ खपत से है? 15:40 <KBlup> इसका परिणाम msg-delay> 10000ms में होता है :-/ 15:40 <jrandom> आह, संभवतः यही _PRE net विकसित करने के कारणों में से एक है :) 15:40 <KBlup> मेरा खयाल है तब यह नए tunnel स्थापित करने की कोशिश करता है और लगातार फेल होता है, जिसका नतीजा कभी-कभी 300+ jobs तक होता है... 15:41 <KBlup> मेरी मशीन काफ़ी मजबूत है, पर इससे ओवरलोड हो जाती है... 15:41 <jrandom> हाँ, यह सब 0.6.1.10 के लिए फिर से काम किया गया है, जब तक वह तैयार नहीं होता तब तक धैर्य रखें 15:43 <jrandom> ठीक है, 1) पर और कुछ, या हम 2) _PRE net प्रगति पर धीरे-धीरे बढ़ें? 15:43 <+Complication> 0.6.1.10 में वाकई काफ़ी बड़े बदलाव लगते हैं 15:45 <jrandom> हाँ, यहाँ काफी कुछ है। मौजूदा स्थिति ये है कि नया creation code मौजूद है और सही से काम करता दिख रहा है, लेकिन अब मैं इस मौके पर कुछ आधारभूत मसलों को और डिबग कर रहा हूँ 15:46 <+Complication> आपने पहले से काफ़ी CPU समय खर्च करने की बात कही थी 15:47 <+Complication> क्या अब यह लागत किसी भी प्रकार का tunnel बनाने से जुड़ी होगी? 15:48 <+Complication> (मतलब, निर्माण से पहले, थोड़े समय के लिए, आपको भारी क्रिप्टो का एक बैच करना होगा) 15:48 <jrandom> हाँ, सभी tunnel build अनुरोधों को k भारी क्रिप्टो ऑपरेशंस करने होंगे (जहाँ k = बनाए जा रहे tunnel में हॉप्स की संख्या) 15:49 <+Complication> मैं पूछना चाहता था... क्या अब अंतराल सिर्फ पहले से तंग हो गया है, या मात्रा भी बढ़ी है? 15:50 <jrandom> मात्रा एक तरह से बड़ी भी है, छोटी भी, और तंग भी। तंग इसलिए कि सब कुछ पहले ही कर दिया जाता है। बड़ी इसलिए कि अगर कोई पहले वाला हॉप रिजेक्ट कर दे तो हम किसी हॉप के लिए एन्क्रिप्शन को शॉर्टकट करके छोड़ नहीं सकते, और छोटी इसलिए कि शुरुआती हॉप्स अब बहुत कम फेल होते हैं 15:51 <jrandom> इसके अलावा, पहले के रिलीज़ के विपरीत, हम अब tunnel अनुरोधों के लिए ElGamal/AES+SessionTag इस्तेमाल नहीं कर रहे हैं - हम (काफी हद तक) सीधे ElGamal का उपयोग कर रहे हैं 15:52 <+Complication> ...और इसे पहले से गणना नहीं किया जा सकता, जब तक कि अंतिम सफल होने वाला सेट पता न हो? 15:52 <jrandom> इसका मतलब है कि पहले हम बिना किसी असममित ऑपरेशन के शॉर्टकट ले सकते थे, लेकिन अब हम वह शॉर्टकट नहीं लेते (क्योंकि वही शॉर्टकट हमलों के एक वर्ग को उजागर करता था) 15:53 <+Complication> (पीयरों का सेट) 15:53 <jrandom> हम्म, अगर आपको पता हो कि tunnel में किन पीयरों से पूछा जाने वाला है, तो इसे पहले से प्रीकैलकुलेट किया जा सकता है 15:54 <jrandom> नया tunnel निर्माण प्रोसेस एक अलग थ्रेड पर किया जाता है, ताकि लोड के समय मुख्य जॉब क्यू ठप्प न हो, और यह खुद को बेहतर ढंग से थ्रॉटल कर सके 15:54 <+Complication> क्या यह भी मान सकते हैं कि उपलब्ध जानकारी में बदलाव न होने पर, अगर प्रयास असफल हों, तो कुछ वही लोग/पीयर होंगे जिनसे अगली बार पूछा जाएगा? 15:54 <jrandom> हम्म, मैं पूरी तरह समझ नहीं पाया 15:55 <+Complication> या उन्हें पहले से जानना बेकार है, क्योंकि स्ट्रक्चर को शुरू से दोबारा बनाना पड़ता है? 15:56 <+Complication> (मतलब: कम से कम ElGamal को शुरू से दोबारा करना पड़ता है) 15:56 <jrandom> आह, संरचना यह है http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt-creation.html?rev=HEAD#tunnelCreate.requestRecord 15:56 <jrandom> तो, हाँ, अगर अगला हॉप बदलता है, तो ElGamal दोबारा करना होगा 15:56 <jrandom> (अगर आप प्रीकम्प्यूट करते हैं) 15:56 <+Complication> ठीक है, मैं तुरंत इस बारे में आश्वस्त नहीं था 15:57 <+Complication> अब समझ आ गया 15:57 <jrandom> दूसरी तरफ, हम वाकई अपनी बिल्ड सफलता दर बढ़ाने की कोशिश कर रहे हैं, और नया बिल्ड प्रोसेस अनावश्यक निर्माण को कम करने के लिए खुद को अनुकूल कर सकेगा 15:58 <+Complication> वास्तव में यह कैसा कर रहा है? 15:58 <jrandom> (ओह, वह स्ट्रक्चर _PRE ब्रांच पर थोड़ा बदला गया है: http://dev.i2p.net/cgi-bin/cvsweb.cgi/~checkout~/i2p/router/doc/tunnel-alt-creation.html?rev=1.1.2.1;content-type=text%2Fhtml#tunnelCreate.requestRecord ) 15:59 <+Complication> मैंने ध्यान दिया कि ElGamal एन्क्रिप्शन की गति तेज़ होने की बात थी... 15:59 <jrandom> खैर, बिल्ड सफलता दर live net की तुलना में बहुत ज़्यादा है, पर वह शायद _PRE net के छोटे आकार की वजह से हो 16:00 <jrandom> हाँ, उदाहरण के लिए, 2 hop स्ट्रक्चर बनाना औसतन 44ms लेता है (1120 रन पर), जबकि live net पर ElGamal एन्क्रिप्शन समय 542ms है (1344 रन पर) 16:02 <jrandom> (उसी मशीन पर) 16:02 <+Complication> क्या 542 में फेल होने पर रिट्राइज़ भी शामिल हैं, या सिर्फ शुद्ध बिल्डिंग? 16:02 <+Complication> अगर यह सिर्फ शुद्ध बिल्डिंग है, तो मुझे अपनी ठोड़ी ढूँढनी पड़ेगी... वह कहीं फर्श पर है। :P 16:02 <KBlup> उस घातांक में बदलाव के बारे में: इससे गुमनामी पर किस पैमाने पर असर पड़ता है? 16:02 <jrandom> नहीं, वह शुद्ध ElGamal का आँकड़ा है, क्योंकि live net नया _PRE net स्ट्रक्चर बिल्ड नहीं करता 16:04 <jrandom> KBlup: गुमनामी? कोई असर नहीं। सुरक्षा? मेरी पढ़ाई के अनुसार, 228 बिट्स 2048-बिट ElGamal के समकक्ष के लिए पर्याप्त से ज़्यादा हैं 16:04 * Complication को ElGamal के x और y के बारे में ज़्यादा जानकारी नहीं है 16:04 <+Complication> इतना नहीं जानता कि सार्थक टिप्पणी कर सकूँ 16:06 <+Complication> यदि गंभीर शोधकर्ता छोटे x को पर्याप्त कठिन मानते हैं, और वे क्रिप्टो विशेषज्ञ चीखते हुए भागे नहीं... 16:06 <@cervantes> अच्छा, सिर्फ वही नहीं, बल्कि 1024/160 पर आने के नतीजे भी 16:07 <KBlup> मुझे लगता है मुझे बाद में वह पेपर पढ़ना होगा ;) 16:07 <+Complication> cervantes: हाँ, वह उससे भी बेहतर है, निश्चित रूप से 16:08 <+Complication> इसके अलावा, वह कौन-सा प्रमुख हमला है जिसे यह साइफर रोकना चाहिए, और वह हमला कितनी देर तक व्यवहार्य रहता है? 16:09 <+Complication> क्या ऐसा कुछ है जिसका लाभ तभी है जब आप उसे जल्दी तोड़ दें, या फिर बाद में तोड़ने पर भी लाभ मिलता है? 16:11 <+Complication> यदि मैं सही समझ रहा हूँ, तो यह तुरंत जिस रहस्य की रक्षा करता है वह अगला tunnel प्रतिभागी है, सही? 16:11 <+Complication> (या अधिक सटीक कहें तो अगले-से-अगला) 16:11 <@modulus> मीटिंग चल रही है? 16:11 <+Complication> (जिसे सिर्फ अगला ही जान सकता है) 16:11 <@cervantes> modulus: ayre 16:11 <@cervantes> -r 16:11 <jrandom> एक व्यावहारिक (फिर भी असाधारण रूप से ताकतवर) विरोधी के लिए, tunnel की lifetime के दौरान इसे तोड़ना ज़रूरी होगा। उस tunnel की lifetime के बाद इसे तोड़ना तभी मदद करेगा जब आपने पूरे नेटवर्क ट्रैफ़िक को लॉग किया हो और सभी tunnels तोड़े हों (यानी, क्षणिक ट्रांसपोर्ट लेयर क्रिप्टो तोड़ने के बाद और tunnel लेयर क्रिप्टो पर काम करते हुए) 16:11 <jrandom> तो, हम यहाँ मिनटों की बात कर रहे हैं, दशकों की नहीं 16:12 <jrandom> (तो 1024bit शायद ओवरकिल भी है) 16:12 <@cervantes> क्या जोखिम को किसी सार्थक तरीके से मापा जा सकता है? 16:13 <+Complication> और, अधिक हॉप्स वाले tunnel के लिए, विरोधी को कई जगह तोड़ना पड़ेगा, सही? 16:13 <+Complication> (हालाँकि बिल्डर को भी कई बार बनाना पड़ेगा) 16:13 <@cervantes> अगर हमें 1024 बिट्स से ज़्यादा की ज़रूरत नहीं, तो क्या वाकई और ज़्यादा इस्तेमाल करना ज़रूरी है? 16:14 <@cervantes> हम हमेशा 3 साल में एक मज़बूत एल्गो इस्तेमाल कर सकते हैं, जब हमारे पास बहुत अधिक शक्तिशाली क्वांटम कंप्यूटर होंगे 16:14 <@modulus> jrandom: अगर विरोधी को पता हो कि hh:mm पर कुछ महत्वपूर्ण tunnel होने वाला है, तो क्या वे लॉगिंग करके किसी तरह उसे तोड़ पाने की संभावना रखते हैं? 16:14 <jrandom> Complication: सही, उन्हें कई जगह तोड़ना पड़ेगा (और ट्रांसपोर्ट लेयर की रक्षा कर रही DH keys को भी) 16:14 <@modulus> मेरी जानकारी में (afaik) 1024bit बहुत शक्ति के साथ break()able है 16:15 <jrandom> बहुत शक्ति और एक दशक 16:15 <jrandom> (या तीन) 16:15 <@cervantes> jrandom: क्या कमज़ोर साइफर को आज़माना मुश्किल है? 16:15 <@modulus> मेरा यह आभास था कि आजकल 1024bit के कॉम्पोज़िट्स कुछ महीनों में factorize किए जा सकते हैं। 16:15 <@cervantes> क्या हम pre net पर रोल आउट कर सकते हैं 16:15 <@cervantes> और देखें कि क्या इससे वास्तव में अधिक लाभ मिलता है 16:16 <@cervantes> modulus: हाँ, पर उन्हें कई जगह तोड़ना पड़ेगा 16:16 <@modulus> अगर यह discrete log domain और ऐसी चीज़ों पर आधारित है तो मुझे इसका कुछ पता नहीं 16:16 <@modulus> cervantes: आहा 16:16 <jrandom> cervantes: इसमें बहुत-से स्ट्रक्चर बदलने पड़ेंगे, क्योंकि अभी हम 512byte स्लॉट्स इस्तेमाल करते हैं। हालांकि, शायद परीक्षण के लिए हम पहले 256 बाइट्स को 0x00 से भर सकते हैं 16:17 <jrandom> modulus: ElGamal discrete log पर आधारित है 16:17 <@cervantes> jrandom: परीक्षण के लायक है? 16:17 <@modulus> हाँ हाँ, मैं RSA सोच रहा था 16:17 <@cervantes> या बेहतर है कि और चीज़ों पर ध्यान दें और ज़रूरत पड़े तो इस पर लौटें 16:18 <jrandom> निश्चित रूप से परीक्षण के काबिल है, हालांकि फिलहाल मैं कुछ ट्रांसपोर्ट लेयर मूल्यांकन पर हैकिंग कर रहा हूँ 16:18 <+Complication> मेरा खयाल है यह इस पर निर्भर करता है कि वास्तविक जीवन में उनकी गणना कैसे संभाली जा सकती है। 16:18 <jrandom> (और 44ms एन्क्रिप्शन समय फिलहाल काफ़ी है, हालांकि 4ms एन्क्रिप्शन समय और भी बेहतर होगा :) 16:19 <+Complication> अगर यह मौजूदा कंप्यूटरों के साथ काम चला लेता है, तो नई मशीनों के साथ बेहतर होगा। 16:19 <@modulus> खासकर अगर क्रिप्टो हार्डवेयर आए, जैसा कि कुछ जगहों पर आना शुरू हो गया है 16:19 <jrandom> लेकिन, बेशक, इस पैरामीटर को न तो हल्के में बदला जाएगा, न तुरंत। पर अगर किसी के पास इसे टालने का कोई अच्छा कारण हो, तो कृपया संपर्क करें 16:21 <jrandom> modulus: मैंने dedicated AES और RSA चिप्स के बारे में सुना है, पर DH/ElGamal पर कुछ नहीं। दूसरी तरफ, जब आप विरोधी के रूप में NSA/आदि को देखते हैं, जहाँ वे अपने खुद के बना सकते हैं, तो यह संभव है 16:22 <@cervantes> उनके पास ring sprinkled donut technology पर बनी क्रिप्टो मशीनें हैं 16:23 * Complication तैयार है Celeron 300 को Athlon 600 में अपग्रेड करने के लिए, अगर वह ring-sprinkled donuts की बाढ़ को थाम ले :D 16:23 <tethra> हाहा 16:24 <jrandom> म्मMMम्म डोनट्स 16:25 <jrandom> ठीक है, 2) _PRE net प्रगति पर किसी के पास और कुछ है? 16:25 <jrandom> यदि नहीं, तो चलिए 3) I2Phex 0.1.1.37 पर चलते हैं 16:26 <jrandom> Complication: क्या संक्षेप में हमें अपडेट दोगे? 16:26 <+Complication> अच्छा, यह काम करता दिख रहा है। :) 16:26 <+Complication> अतिरिक्त रिडंडेंसी के लिए जल्द ही और webcaches मिलने की उम्मीद है। 16:27 <jrandom> बढ़िया 16:27 <jrandom> हम्म, क्या तुम्हें लगता है कि हमें और webcaches चाहिए? क्या एक का अप होना ही काफी नहीं? बेशक ज़्यादा होने से नुकसान नहीं 16:27 <+Complication> (यदि legion अपनी पहली कोशिश को सताने वाली पहेलियाँ सुलझा लेता है) 16:27 <+Complication> वहाँ एक रहस्यमयी बग भी है, लेकिन वह ज़्यादा 'byte' नहीं करता, और मैं उसे ढूँढने की कोशिश कर रहा हूँ। 16:28 <+Complication> एक अप होना काफी है 16:28 <+Complication> ज़्यादा होने से बस यह संभावना बढ़ती है कि कम-से-कम एक अप रहे 16:28 <jrandom> कूल 16:28 <+Complication> क्योंकि मौजूदा चरण में, यह webcaches को कभी बुरा/खराब के रूप में ड्रॉप नहीं करेगा। कुल मिलाकर वे बहुत कम हैं। 16:29 <+Complication> (वह रूटीन तब सक्रिय होगा जब 10 से अधिक मौजूद हों) 16:29 <+Complication> (अगर मुझे सही याद है) 16:29 <+Complication> जहाँ तक बग की बात है: लंबे समय तक चलने के बाद, webcache सबसिस्टम कभी-कभी ठहर जाता है 16:30 <+Complication> संभवतः इसलिए कि किसी httpclient का GET अनुरोध सफलतापूर्वक एबॉर्ट नहीं हो पाता 16:31 <@modulus> तो इसे समय-समय पर मरना पड़ेगा? 16:31 <+Complication> यह सुरक्षित है, और नई जुड़ी मशीनों को कभी 'काटता' नहीं दिखता 16:31 <jrandom> हम्म, कार्यात्मक रूप से उसका मतलब क्या है? कुछ समय बाद, यह webcache के साथ रजिस्टर करना बंद कर देगा, तो नए लोगों को इनके रेफरेंसेज़ नहीं मिलेंगे? 16:31 <+Complication> अगर यह किसी पहले से अच्छी तरह इंटीग्रेटेड मशीन को 'काटे' भी, तो वह मशीन अपने पहले से जुड़े पीयरों से पर्याप्त पीयर्स ले सकती है 16:31 <+Complication> तो फिलहाल इसका प्रभाव लगभग 0 लगता है 16:31 <@modulus> कूल 16:32 <+Complication> यह बस जिज्ञासापूर्ण है 16:32 <@modulus> कब यह फेल होगा इस बारे में कोई नियम-वगैरह? 16:32 <+Complication> modulus: आम तौर पर 20 घंटे से पहले नहीं 16:33 <+Complication> और चूँकि मेरे पास इसे जबरन घटित कराने का कोई तरीका नहीं, डिबगिंग थोड़ी धीमी है 16:33 <@modulus> :_) 16:34 <+Complication> जो भी हो, अगर मैं इसे ढूँढ पाया तो ठीक कर दूँगा, और अगर नहीं मिला, तो छेड़छाड़ करने के लिए दूसरी चीज़ें ढूँढ लूँगा :) 16:34 <jrandom> :) 16:34 <jrandom> लगता है यह streaming lib / eepproxy में देखे गए कुछ बग्स का ही लक्षण है, तो उन्हें ठीक करने से इसे भी ठीक होना चाहिए 16:35 <+Complication> हो सकता है 16:38 <jrandom> ठीक है, बढ़िया, अच्छा काम Complication 16:38 <jrandom> क्या 3) I2Phex 0.1.1.37 पर किसी के पास कुछ और है, या हम सब-कुछ समेटने वाले 4) ??? पर कूदें? 16:41 <jrandom> (मान लीजिए हम कूद गए) 16:41 <jrandom> ठीक है, मीटिंग के लिए किसी के पास कुछ और है? 16:42 <tmp> या हमेशा के लिए अपनी साँस रोके रखें? 16:43 <jrandom> और हमेशा, हमेशा 16:43 * jrandom समापन करता है 16:43 * jrandom *baf*s के साथ मीटिंग बंद करता है