مرحباً يا جماعة، لقد حان ذلك الوقت من الأسبوع،

  • Index
  1. حالة التطوير 2) IVs الخاصة بـ Tunnel (متجهات التهيئة) 3) MACs الخاصة بـ SSU (رموز توثيق الرسائل) 4) ???
    1. Dev status

أسبوع آخر، ورسالة أخرى تقول “لقد كان هناك الكثير من التقدّم في نقل SSU” ;) التعديلات المحلية لدي مستقرة وقد تم دفعها إلى CVS (HEAD حاليًا عند 0.5.0.7-9)، لكن لا إصدار بعد. المزيد من الأخبار على ذلك الصعيد قريبًا. تفاصيل التغييرات غير المتعلقة بـ SSU موجودة في السجل [1]، مع أنني أبقي التغييرات المتعلقة بـ SSU خارج تلك القائمة حتى الآن، لأن SSU لم يُستخدم بعد من قِبل غير المطوّرين (والمطوّرون يقرؤون i2p-cvs@ :)

[1] http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD

    1. Tunnel IVs

على مدى الأيام القليلة الماضية، كان dvorak ينشر أفكارًا متفرقة حول طرق مختلفة لمهاجمة تشفير الـ tunnel، ومع أن معظمها كان قد جرى التعامل معه بالفعل، تمكّنا من التوصل إلى سيناريو واحد يسمح للمشاركين بوسم زوجٍ من الرسائل لتحديد أنهما في الـ tunnel نفسه. كانت الطريقة تعمل بحيث إن النظير الأسبق يدع رسالةً تتجاوزه ثم لاحقًا يأخذ الـ IV (متجه التهيئة) وكتلة البيانات الأولى من تلك الرسالة الأولى في الـ tunnel ويضعهما في رسالة جديدة. هذه الرسالة الجديدة ستكون بالطبع تالفة، لكنها لن تبدو كهجوم إعادة التشغيل، إذ إن الـ IVs كانت مختلفة. لاحقًا، يمكن للنظير الثاني عندئذٍ ببساطة تجاهل تلك الرسالة حتى لا تتمكن نقطة نهاية الـ tunnel من كشف الهجوم.

إحدى المشكلات الجوهرية الكامنة وراء ذلك هي أنه لا توجد طرق للتحقق من رسالة tunnel أثناء انتقالها عبر tunnel من دون فتح الباب أمام مجموعة كبيرة من الهجمات (انظر مقترحاً سابقاً لتشفير tunnel [2] للاطلاع على طريقة تقترب من ذلك، لكنه يعتمد على احتمالات غير موثوقة إلى حد كبير ويفرض بعض القيود المصطنعة على tunnels).

[2] http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel.html?rev=HEAD

مع ذلك، هناك طريقة بسيطة للغاية لتجاوز الهجوم المبيَّن: ببساطة اعتبر xor(IV, first data block) هو المُعرّف الفريد المُمرَّر عبر bloom filter (مرشّح احتمالي) بدلاً من IV وحده. بهذه الطريقة، سيلاحظ الأقران الوسطاء التكرار ويُسقطونه قبل أن يصل إلى النظير المتواطئ الثاني. تم تحديث CVS ليشمل هذا الدفاع، رغم أنني أشكّ كثيراً جداً في أنه يمثّل تهديداً عملياً نظراً لحجم الشبكة الحالي، لذا لا أعتزم طرحه كإصدار مستقل بحدّ ذاته.

هذا لا يؤثر على جدوى هجمات التوقيت أو تشكيل حركة المرور الأخرى، لكن من الأفضل معالجة الهجمات اليسيرة التعامل معها حالما نرصدها.

    1. SSU MACs

كما هو موضح في المواصفة [3]، يستخدم نقل SSU قيمة MAC لكل داتاغرام مُرسَل. يأتي هذا بالإضافة إلى تجزئة التحقق المرسلة مع كل رسالة I2NP (وكذلك تجزئات التحقق من طرف إلى طرف لرسائل العميل). حالياً، تستخدم المواصفة والكود HMAC-SHA256 مقتطعاً — حيث يتم إرسال والتحقق من أول 16 بايت فقط من الـMAC. هذا سعال يُعدّ إهداراً بعض الشيء، إذ إن HMAC يستخدم دالة التجزئة SHA256 مرتين في عمليته، وفي كل مرة يعمل بتجزئة بطول 32 بايت، وتشير تحليلات الأداء (profiling) الحديثة لنقل SSU إلى أن هذا يقترب من المسار الحرج لاستهلاك المعالج. بناءً على ذلك، قمتُ ببعض الاستكشاف لاستبدال HMAC-SHA256-128 بـ HMAC-MD5(-128) البسيط — ورغم أن MD5 أضعف بوضوح من SHA256، فإننا نقتطع SHA256 إلى نفس حجم MD5 على أي حال، لذا فإن مقدار القوة الغاشمة المطلوبة لإيجاد تصادم هو نفسه (2^64 محاولة). أنا أجرّب ذلك حالياً، والتسريع ملحوظ (الحصول على أكثر من 3 أضعاف معدل نقل HMAC على حِزم بحجم 2KB مقارنةً مع SHA256)، لذا ربما نعتمده للإنتاج بدلاً من ذلك. أو إذا استطاع أحدهم طرح سبب وجيه لعدم القيام بذلك (أو بديل أفضل)، فاستبداله بسيط بما يكفي (سطر واحد فقط من الكود).

[3] http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/udp.html?rev=HEAD

    1. ???

هذا تقريبًا كل شيء في الوقت الراهن، وكما هو الحال دائمًا، لا تترددوا في طرح آرائكم ومخاوفكم في أي وقت. أصبح CVS HEAD قابلاً للبناء مرة أخرى لمن ليس لديهم junit مُثبّت (في الوقت الحالي أزلت الاختبارات من i2p.jar، لكنها لا تزال قابلة للتشغيل عبر هدف ant المسمّى test)، وأتوقع أن يكون هناك مزيد من الأخبار حول اختبار 0.6 قريبًا جدًا (ما زلت أواجه غرائب الخادوم الموضوع في مركز الاستضافة (colo box) في الوقت الحالي - الاتصال عبر telnet بواجهات الشبكة الخاصة بي يفشل محليًا (من دون errno مفيد)، ويعمل عن بُعد، وكل ذلك من دون أي iptables أو مرشّحات أخرى. يا للروعة). لا يزال لا يوجد لدي اتصال بالإنترنت في المنزل، لذلك لن أكون متاحًا لاجتماع الليلة، ولكن ربما الأسبوع المقبل.

=jr