اجتماع مطوري I2P - 07 فبراير 2006

15:36 <jrandom> 0) مرحبًا 15:36 <jrandom> 1) حالة الشبكة 15:36 <jrandom> 2) تقدم شبكة _PRE 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> لم يتغيّر الكثير على الشبكة الحية خلال الأسبوع الماضي، من منظور I2P، لذا ليس لدي الكثير لأضيفه هنا 15:39 <jrandom> هل لدى أيٍّ منكم شيء يريد طرحه بخصوص حالة الشبكة الحالية؟ 15:39 <KBlup> لقد رأيت طفرات سيئة من فشل العملاء عند تشغيل I2P لفترة طويلة... لا أدري إن كان ذلك يندرج تحت 1) 15:39 <jrandom> KBlup: هل يرتبط ذلك بارتفاع حمل CPU أو استهلاك النطاق الترددي؟ 15:40 <KBlup> ينتج عنه msg-delay> 10000ms :-/ 15:40 <jrandom> آه، على الأرجح هذا أحد أسباب تطوير شبكة _PRE :) 15:40 <KBlup> أظن أنه يحاول بعدها إنشاء tunnels جديدة ويفشل باستمرار، ما ينتج عنه 300+ مهمة أحيانًا... 15:41 <KBlup> جهازي قوي إلى حدٍّ ما لكنه مُحمّل زيادة بهذا... 15:41 <jrandom> نعم، تمّت إعادة العمل على كل ذلك ضمن الإصدار 0.6.1.10، تحمّلوا قليلًا حتى يصبح جاهزًا 15:43 <jrandom> حسنًا، أي شيء آخر ضمن 1)، أم ننتقل بهدوء إلى 2) تقدم شبكة _PRE 15:43 <+Complication> يبدو أن 0.6.1.10 يحتوي بالفعل على تغييرات كبيرة 15:45 <jrandom> نعم، هناك الكثير من العمل الجوهري هنا. الوضع الحالي هو أن كود الإنشاء الجديد في مكانه ويبدو أنه يعمل بشكل صحيح، لكنني أستغل هذه الفرصة الآن لاستكشاف بعض المشكلات الأساسية بصورة أعمق 15:46 <+Complication> ذكرتَ الحاجة إلى استهلاك الكثير من وقت CPU مسبقًا 15:47 <+Complication> هل ستكون هذه الكلفة الآن مرتبطة ببناء أي نوع من ال tunnel؟ 15:48 <+Complication> (أي قبل الإنشاء، وخلال فترة وجيزة، سيكون عليك تنفيذ دفعة من التشفير الثقيل) 15:48 <jrandom> نعم، كل طلبات بناء tunnel ستحتاج إلى إجراء k عملية تشفير ثقيلة (حيث k = عدد القفزات في ال tunnel الجاري بناؤه) 15:49 <+Complication> ما أردت سؤاله... هل الفاصل الزمني أشدّ إحكامًا فقط مقارنة بالسابق، أم أن الكمية أكبر أيضًا؟ 15:50 <jrandom> الكمّية أصبحت في آنٍ واحد أكبر وأصغر وأشد إحكامًا. أشد إحكامًا لأنها تُنجَز كلها مُقدّمًا. أكبر لأننا لا نستطيع الاختصار وتجاوز التشفير لقفزة ما إذا رفضتها قفزة سابقة، وأصغر لأن القفزات المبكرة تفشل بوتيرة أقل بكثير 15:51 <jrandom> بالإضافة إلى ذلك، وعلى خلاف الإصدارات السابقة، لم نعد نستخدم ElGamal/AES+SessionTag لطلبات ال tunnel - نحن نستخدم ElGamal مباشرًا (إلى حدٍّ كبير) 15:52 <+Complication> ...ولا يمكن حسابه مسبقًا، إلا إذا عُرِفت المجموعة النهائية التي ستنجح؟ 15:52 <jrandom> هذا يعني أنه بينما كنا قادرين سابقًا على التحايل دون إجراء عملية غير متناظرة، فإننا لا نحاول التحايل بعد الآن (لأن التحايل نفسه كشف فئة من الهجمات) 15:53 <+Complication> (مجموعة الأقران) 15:53 <jrandom> هممم، يمكن بالتأكيد حسابه مسبقًا، بافتراض أنك تعرف الأقران في ال tunnel الذين سيتم طلبهم 15:54 <jrandom> تتم عملية إنشاء ال tunnel الجديدة على thread (خيط) منفصل، حتى لا تُثقِل صف المهام الرئيسي تحت الضغط، ولكي تتمكن من تنظيم نفسها بشكل أفضل 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> حسنًا، معدل نجاح البناء أعلى بكثير جدًا مما هو عليه على الشبكة الحية، لكن قد يكون ذلك فقط بسبب صِغَر حجم شبكة _PRE 16:00 <jrandom> نعم، إنشاء بنية ذات قفزتين، مثلًا، يستغرق في المتوسّط 44ms عبر 1120 تشغيلًا، مقارنة بزمن تشفير ElGamal على الشبكة الحية البالغ 542ms (عبر 1344 تشغيلًا) 16:02 <jrandom> (على نفس الجهاز) 16:02 <+Complication> هل يشمل رقم 542 هذا محاولات الإعادة عند الفشل أيضًا، أم أنه زمن البناء الصِرف فقط؟ 16:02 <+Complication> إن كان زمن البناء الصِرف، عليّ أن أبحث عن فكي السفلي... إنه على الأرض في مكانٍ ما. :P 16:02 <KBlup> بخصوص تغيير الأسّ: على أي مستوى يؤثر ذلك في الخصوصية/عدم الكشف عن الهوية؟ 16:02 <jrandom> لا، هذا إحصاء ElGamal الصِرف، إذ إن الشبكة الحية لا تبني بنية شبكة _PRE الجديدة 16:04 <jrandom> KBlup: إخفاء الهوية؟ لا شيء. الأمان؟ وفقًا لما قرأت، 228 بت أكثر من كافٍ لمعادلة ElGamal بحجم 2048 بت 16:04 * Complication لا يعرف الكثير عن قيم x و y في ElGamal 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. أما كسره بعد انتهاء عمر ال tunnel فلن يفيد إلا إذا سجّلت كل حركة مرور الشبكة وكسرت جميع ال tunnels (أي بعد كسر تشفير طبقة النقل المؤقّت والعمل على تشفير طبقة ال tunnel) 16:11 <jrandom> إذًا، نحن نتحدث هنا عن دقائق، لا عقود 16:12 <jrandom> (لذا 1024 بت ربما يكون مبالغًا فيه أصلًا) 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 التي تحمي طبقة النقل) 16:14 <@modulus> حسب علمي 1024 بت قابلة للكسر مع قدرة حوسبية كبيرة 16:15 <jrandom> قدرة كبيرة وعقدٌ من الزمن 16:15 <jrandom> (أو ثلاثة) 16:15 <@cervantes> jrandom: هل من الصعب تجربة التشفير الأضعف؟ 16:15 <@modulus> كنتُ تحت انطباع أن الأعداد المركّبة ذات 1024 بت أصبحت قابلة للتحليل لعواملها هذه الأيام خلال بضعة أشهر. 16:15 <@cervantes> هل يمكننا طرحه على شبكة pre 16:15 <@cervantes> ونرى إن كان يوفر فائدة كبيرة بالفعل 16:16 <@cervantes> modulus: نعم، لكن سيتعيّن عليهم كسر عدة طبقات 16:16 <@modulus> إن كان هذا قائمًا على مجال اللوغاريتم المتقطع وكل ذلك، فأنا لا أعرف شيئًا 16:16 <@modulus> cervantes: فهمت 16:16 <jrandom> cervantes: هذا يتطلب تغييرات في الكثير من البُنى، إذ نستخدم حاليًا خانات بحجم 512byte. ومع ذلك، ربما يمكننا فقط ملء أول 256 بايت بـ 0x00 لأغراض الاختبار 16:17 <jrandom> modulus: ElGamal قائم على اللوغاريتم المتقطع 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: سمعتُ عن شرائح مخصّصة لـ AES وRSA، لكن لا شيء بخصوص DH/ElGamal. ومن ناحية أخرى، عندما ننظر إلى NSA/وغيرها كخصم، حيث يمكنهم بناء عتادهم الخاص، فذلك ممكن 16:22 <@cervantes> لديهم آلات تشفير مبنية على تقنية الدونات المرشوشة بالحلقات 16:23 * Complication مستعد لترقية Celeron 300 إلى Athlon 600 إذا كان هذا سيصدّ موجة الدونات المرشوشة بالحلقات :D 16:23 <tethra> ههههه 16:24 <jrandom> مممممم دونات 16:25 <jrandom> حسنًا، هل لدى أحد أي شيء آخر حول 2) تقدم شبكة _PRE؟ 16:25 <jrandom> إن لم يكن، فلننتقل إلى 3) I2Phex 0.1.1.37 16:26 <jrandom> Complication: هل تود أن تعطينا الخلاصة؟ 16:26 <+Complication> حسنًا، يبدو أنه يعمل. :) 16:26 <+Complication> هناك أمل في الحصول على مزيد من مخازن الويب قريبًا لمزيد من الاعتمادية عبر التكرار. 16:27 <jrandom> تمام 16:27 <jrandom> هممم، هل تعتقد أننا بحاجة إلى مزيد من مخازن الويب؟ ألسنا بحاجة لواحد فقط يكون متاحًا؟ ليس أن المزيد يضرّ، بالطبع 16:27 <+Complication> (إذا نجح legion في حل الألغاز التي لاحقَت محاولته الأولى) 16:27 <+Complication> هناك أيضًا خطأ غامض هناك، لكنه لا يؤذي بشدة، وأنا أحاول العثور عليه. 16:28 <+Complication> وجود واحد يعمل يكفي 16:28 <+Complication> المزيد يزيد فقط من احتمال أن يكون أحدها عاملًا 16:28 <jrandom> جميل 16:28 <+Complication> لأنه في المرحلة الحالية، لن يُسقِط مخازن الويب باعتبارها سيئة. عددها قليل جدًا أصلًا. 16:29 <+Complication> (ذلك الروتين سيتفعّل إذا وُجد أكثر من 10) 16:29 <+Complication> (إذا كنت أتذكر جيدًا) 16:29 <+Complication> أما عن الخطأ: بعد مدة طويلة من التشغيل، يتوقف أحيانًا النظام الفرعي لمخزن الويب 16:30 <+Complication> على الأرجح لأن طلب GET الخاص بـ httpclient لا يمكن إجهاضه بنجاح 16:31 <@modulus> إذًا يحتاج أن يُنهى من حين لآخر؟ 16:31 <+Complication> الأمر آمن، ولا يبدو أنه يؤثر على الأجهزة المنضمّة حديثًا 16:31 <jrandom> هممم، ماذا يعني ذلك وظيفيًا؟ بعد فترة، سيتوقف عن التسجيل لدى مخزن الويب، وبالتالي لن يحصل القادمون الجدد على مراجع إليهم؟ 16:31 <+Complication> إن أثّر على جهاز مدمج جيدًا، فيمكن لذلك الجهاز الحصول على عدد كافٍ من الأقران من الأقران المتصل بهم بالفعل 16:31 <+Complication> إذًا حاليًا يبدو التأثير قريبًا من الصفر 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*