تم إنشاء هذه الترجمة باستخدام التعلم الآلي وقد لا تكون دقيقة بنسبة 100%. عرض النسخة الإنجليزية

NTCP 2

Proposal 111
مُغلق
Author EinMByte, orignal, psi, str4d, zzz
Created 2014-02-13
Last Updated 2019-08-13
Target Version 0.9.36
Implemented In 0.9.36
Supercedes: 106

ملاحظة

مرحلة الاقتراح مغلقة. انظر المواصفات لمواصفات رسمیة. يمكن الإشارة إلى هذا الاقتراح لمعلومات الخلفية.

نظرة عامة

يصف هذا الاقتراح بروتوكول اتفاق مصادق على المفتاح لتحسين مقاومة NTCP للعديد من أشكال التعريف الآلي والهجمات.

يتم تنظيم الاقتراح على النحو التالي: يتم تقديم الأهداف الأمنية، يليها مناقشة البروتوكول الأساسي. بعد ذلك، يتم تقديم مواصفات كاملة لجميع رسائل البروتوكول. أخيرًا، يتم مناقشة عناوين الموجهات وتحديد الإصدار. كما يتم تضمين ملحق يناقش هجومًا عامًا على مخططات التعبئة الشائعة، بالإضافة إلى ملحق يحتوي على عدد من المرشحين للمصادق على الشفرة.

دوافع

بيانات NTCP مشفرة بعد الرسالة الأولى (والرسالة الأولى تبدو وكأنها بيانات عشوائية)، مما يمنع تحديد البروتوكول من خلال “تحليل الحمولة”. ومع ذلك، لا يزال معرضًا لتحديد البروتوكول من خلال “تحليل التدفق”. وذلك لأن الرسائل الأربع الأولى (أي握手) لها حجم ثابت (288 و 304 و 448 و 48 بايت).

من خلال إضافة كميات عشوائية من البيانات العشوائية إلى كل من الرسائل، يمكننا جعلها أكثر صعوبة.

أهداف التصميم

  • دعم NTCP 1 و 2 على منفذ واحد، وتحديد تلقائي، ونشره كـ “نقل” واحد (أي RouterAddress) في NetDB .

  • نشر دعم الإصدار 1 فقط، أو الإصدار 2 فقط، أو 1+2 في NetDB في حقل منفصل، والافتراض الافتراضي للإصدار 1 فقط (لا ربط دعم الإصدار بترقية معينة للموجه).

  • ضمان أن جميع التنفيذات (Java/i2pd/Kovri/go) يمكنها إضافة دعم الإصدار 2 (أو لا) وفقًا لجدولها الزمني الخاص.

  • إضافة تعبئة عشوائية إلى جميع رسائل NTCP، بما في ذلك رسائل اليد ورسائل البيانات (أي تعبئة التعتيم حتى لا تكون جميع الرسائل مضاعفًا لـ 16 بايت). تقديم آلية خيارات للطرفين لطلب الحد الأدنى والأقصى للتعبئة و/أو توزيع التعبئة. تفاصيل توزيع التعبئة تعتمد على التنفيذ وقد يتم تحديدها في البروتوكول نفسه أو لا.

أمان

نعتبر ثلاثة أطراف:

  • أليس، التي تريد إنشاء جلسة جديدة.
  • بوب، الذي تريد أليس إنشاء جلسة معه.
  • مالوري، “الرجل في الوسط” بين أليس و بوب.

إطار بروتوكول الضوضاء

يستند NTCP2 على بروتوكول Noise Noise_XK_25519_ChaChaPoly_SHA256. (المعرف الفعلي للوظيفة الأولية للمفتاح هو “Noise_XKaesobfse+hs2+hs3_25519_ChaChaPoly_SHA256” لمتد بروتوكول I2P - انظر قسم KDF 1 أدناه) يستخدم هذا بروتوكول Noise البريمитивات التالية:

رسائل

جميع رسائل NTCP2 أقل من أو تساوي 65537 بايت في الطول. تنسيق الرسالة مبني على رسائل Noise، مع تعديلات للتعطيم والتمييز.

مرحلة البيانات

تبدأ مرحلة البيانات بعد انتهاء 握手. في هذه المرحلة، يتم تبادل رسائل البيانات بين أليس و بوب.

تعبئة

تستخدم التعبئة لتعطيم رسائل البيانات.

إنهاء

يمكن إنهاء الاتصال عن طريق إغلاق عادي أو غير عادي لمحطة TCP، أو عن طريق رسالة إنهاء صريحة.

ملحق أ: مخطط التعبئة

يناقش هذا القسم هجومًا على مخططات التعبئة الشائعة التي تسمح للمهاجمين باكتشاف توزيع احتمال حجم الرسائل غير المعبأة، من خلال مراقبة حجم الرسائل المعبأة فقط.

مراجع