مرحباً يا جماعة، ها قد حل يوم الثلاثاء مجدداً

  • 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 نظراء). وبالاستعانة بسجلات pen register (سجلات حصر أرقام الاتصالات) من تلك routers، تم تتبّع بعض الأخطاء الجوهرية في كلٍ من الشفرة الجديدة والقديمة والقضاء عليها، مع استمرار الاختبار والتحسين.

أحد جوانب آلية التشفير الجديدة لإنشاء tunnel هو أن المنشئ يجب أن ينفّذ التشفير غير المتماثل المكلف حسابياً لكل قفزة مسبقاً، بينما كان إنشاء tunnel القديم يجري التشفير فقط إذا كانت القفزة السابقة قد وافقت على المشاركة في tunnel. يمكن أن يستغرق هذا التشفير 400–1000 مللي ثانية أو أكثر، وهذا يعتمد على كلٍ من أداء وحدة المعالجة المركزية (CPU) المحلي وطول tunnel (إذ يجري تشفير ElGamal كاملاً لكل قفزة). أحد أساليب التحسين المستخدمة حالياً على شبكة _PRE هو استخدام أس قصير [1] - فبدلاً من استخدام ‘x’ بطول 2048 بت كمفتاح ElGamal، نستخدم ‘x’ بطول 228 بت، وهو الطول المقترح لمعادلة عامل العمل لمسألة اللوغاريتم المتقطع. وقد خفّض هذا زمن التشفير لكل قفزة بمقدار مرتبة كاملة، على الرغم من أنه لا يؤثر في زمن فك التشفير.

هناك الكثير من الآراء المتضاربة حول استخدام الأسس القصيرة، وفي الحالة العامة فهو غير آمن، ولكن وفقاً لما تمكنت من استنتاجه، وبما أننا نستخدم عدداً أولياً آمناً ثابتاً (Oakley group 14 [2])، فإن رتبة q ينبغي أن تكون مناسبة. ومع ذلك، إذا كان لدى أي شخص أفكار إضافية في هذا السياق، فسيسرّني سماع المزيد.

البديل الكبير الوحيد هو التحول إلى تشفير 1024-بت (حيث يمكننا عندها استخدام أسّ قصير بطول 160-بت، ربما). قد يكون ذلك مناسباً على أي حال، وإذا كانت الأمور مرهقة للغاية مع تشفير 2048-بت على شبكة _PRE، فقد نجري هذا التحول ضمن شبكة _PRE. وإلا فقد ننتظر حتى الإصدار 0.6.1.10، عندما يكون هناك انتشار أوسع للتشفير الجديد لمعرفة ما إذا كان ذلك ضرورياً. سترد معلومات أكثر بكثير إذا بدا أن مثل هذا التحول مرجّح.

[1] “حول بروتوكول اتفاق المفاتيح Diffie-Hellman ذي الأسس القصيرة” - van Oorschot، Weiner في EuroCrypt 96. متاح بنسخة مرآة على http://dev.i2p.net/~jrandom/Euro96-DH.ps [2] http://www.ietf.org/rfc/rfc3526.txt

على أي حال، هناك الكثير من التقدم على _PRE net، ويتم معظم التواصل بشأنه ضمن قناة #i2p_pre على irc2p.

    1. I2Phex 0.1.1.37

قام Complication بدمج وتطبيق ترقيعات على أحدث شيفرة I2Phex لدعم gwebcaches (خوادم ويب للتخزين والاكتشاف)، وذلك بشكل متوافق مع النقل البرمجي pycache الخاص بـ Rawn. هذا يعني أن المستخدمين يمكنهم تنزيل I2Phex وتثبيته، ثم الضغط على “Connect to the network”، وبعد دقيقة أو دقيقتين سيجلب بعض المراجع إلى أقران I2Phex الموجودين وينضم إلى الشبكة. لم تعد هناك متاعب في إدارة ملفات i2phex.hosts يدوياً أو مشاركة المفاتيح يدوياً (w00t)! هناك اثنان من gwebcaches افتراضياً، لكن يمكن تغييرهما أو إضافة ثالث عبر تعديل خصائص i2pGWebCache0 أو i2pGWebCache1 أو i2pGWebCache2 في i2phex.cfg.

عمل رائع، Complication وRawn!

    1. ???

هذا كل شيء في الوقت الحالي، وهو أمر جيد أيضًا، لأنني متأخر بالفعل عن الاجتماع :) أراكم جميعًا في #i2p قريبًا

=jr