نظرة عامة
تتعلق هذه الاقتراح بإعادة تصميم نقل NTCP لتحسين مقاومته للتعرف التلقائي.
الدوافع
يتم تشفير بيانات NTCP بعد الرسالة الأولى (وتظهر الرسالة الأولى كبيانات عشوائية)، مما يمنع تحديد البروتوكول من خلال “تحليل الحمولة”. لا يزال عرضة لتحديد البروتوكول من خلال “تحليل التدفق”. وذلك لأن الرسائل الأربع الأولى (أي المصافحة) لها طول ثابت (288 و304 و448 و48 بايت).
من خلال إضافة كميات عشوائية من البيانات العشوائية لكل من الرسائل، يمكننا جعل الأمر أصعب بكثير.
التعديلات على NTCP
هذا معقد بعض الشيء ولكنه يمنع أي كشف بواسطة معدات DPI.
ستضاف البيانات التالية إلى نهاية رسالة 288 بايت:
- كتلة مشفرة بـ ElGamal ببطول 514 بايت
- تعبئة عشوائية
يتم تشفير كتلة ElG إلى المفتاح العام لبوب. عندما تُفك شفرتها إلى 222 بايت، تحتوي على:
- 214 بايت تعبئة عشوائية
- 4 بايت 0 محجوزة
- 2 بايت طول التعبئة التالية
- 2 بايت نسخة البروتوكول والأعلام
في الرسائل 2-4، ستشير الآن آخر بايتين من التعبئة إلى طول المزيد من التعبئة التالية.
لاحظ أن كتلة ElG لا تتمتع بسرية أمامية مثالية ولكن لا يوجد شيء مثير للاهتمام هناك.
يمكننا تعديل مكتبة ElG بحيث تقوم بتشفير أحجام بيانات أصغر إذا اعتقدنا أن 514 بايت كبيرة جدًا؟ هل تشفير ElG لكل إعداد NTCP كبير جدًا؟
سيتم الإعلان عن الدعم لهذا في netdb RouterAddress مع الخيار “version=2”. إذا تم استلام 288 بايت فقط في الرسالة 1، من المفترض أن تكون Alice النسخة 1 ولن تتم إضافة تعبئة في الرسائل اللاحقة. لاحظ أن الاتصال يمكن أن يتم حظره إذا قام MITM بتقسيم IP إلى 288 بايت (من غير المرجح جدًا وفقًا لبراندون).