NTCP 2 | I2P - مشروع الإنترنت غير المرئي

ملاحظة

مرحلة الاقتراح مغلقة. راجع المواصفات للمواصفة الرسمية. قد لا يزال يُشار إلى هذا الاقتراح للحصول على معلومات أساسية.

نظرة عامة

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

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

كما هو الحال مع transports I2P الأخرى، يتم تعريف NTCP2 حصرياً لنقل رسائل I2NP من نقطة إلى نقطة (من router إلى router). إنه ليس أنبوب بيانات للاستخدام العام.

الدافع

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

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

يقر المؤلفون أن ممارسات الأمان المعيارية تقترح استخدام بروتوكول موجود مثل TLS، لكن هذا هو Prop104 وله مشاكله الخاصة. حيثما كان ذلك مناسباً، تمت إضافة فقرات “العمل المستقبلي” للإشارة إلى الميزات المفقودة أو مواضيع النقاش.

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

دعم NTCP 1 و 2 على منفذ واحد، مع الكشف التلقائي، ونشره كـ"transport" واحد (أي RouterAddress) في NetDB.
نشر الدعم للإصدار 1 فقط، أو 2 فقط، أو 1+2 في NetDB في حقل منفصل، والافتراض للإصدار 1 فقط (لا تربط دعم الإصدار بإصدار router معين)
تأكد من أن جميع التطبيقات (Java/i2pd/Kovri/go) يمكنها إضافة دعم الإصدار 2 (أو عدم إضافته) وفقاً لجدولها الزمني الخاص
إضافة حشو عشوائي لجميع رسائل NTCP بما في ذلك رسائل المصافحة ورسائل البيانات (أي إخفاء الطول بحيث لا تكون جميع الرسائل مضاعفات لـ 16 بايت) توفير آلية خيارات لكلا الجانبين لطلب الحد الأدنى والأقصى للحشو و/أو توزيع الحشو. تفاصيل توزيع الحشو تعتمد على التنفيذ وقد يتم تحديدها أو لا يتم تحديدها في البروتوكول نفسه.
إخفاء محتويات الرسائل غير المشفرة (1 و 2)، بشكل كافٍ بحيث لا تستطيع صناديق DPI وتوقيعات AV تصنيفها بسهولة. كما يجب التأكد من أن الرسائل المرسلة إلى peer واحد أو مجموعة من peers لا تحتوي على نمط متشابه من البتات.
إصلاح فقدان البتات في DH بسبب تنسيق Java Ticket1112، ربما (على الأرجح؟) عن طريق التبديل إلى X25519.
التبديل إلى دالة اشتقاق مفاتيح حقيقية (KDF) بدلاً من استخدام نتيجة DH كما هي؟
أضف “مقاومة الاستطلاع” (كما يطلق عليها Tor)؛ وهذا يشمل مقاومة إعادة التشغيل.
حافظ على تبادل المفاتيح المصادق عليه ثنائي الاتجاه (2W-AKE). تبادل المفاتيح أحادي الاتجاه (1W-AKE) غير كافٍ لتطبيقنا.
استمر في استخدام التوقيعات متغيرة النوع ومتغيرة الطول (من مفتاح التوقيع المنشور في RouterIdentity) كجزء من المصادقة. اعتمد على مفتاح عام ثابت منشور في RouterInfo كجزء آخر من المصادقة.
إضافة خيارات/إصدار في المصافحة للقابلية للتوسع المستقبلي.
أضف مقاومة لتجزئة TCP الضارة من نوع MitM إذا كان ذلك ممكناً.
لا تضيف بشكل كبير إلى المعالج المطلوب لإعداد الاتصال؛ إذا أمكن، قلل منه بشكل كبير.
إضافة مصادقة الرسائل (MAC)، وربما HMAC-SHA256 و Poly1305، وإزالة Adler checksum.
تقصير وتبسيط رأس I2NP: تقصير انتهاء الصلاحية إلى 4 بايت، كما في SSU. إزالة المجموع الاختباري SHA256 المقطوع ذو البايت الواحد.
إذا أمكن، تقليل المصافحة المكونة من 4 رسائل ورحلتين ذهاب وإياب إلى مصافحة مكونة من 3 رسائل ورحلة ذهاب وإياب واحدة، كما في SSU. هذا سيتطلب نقل توقيع Bob في الرسالة 4 إلى الرسالة 2. البحث في سبب استخدام 4 رسائل في أرشيف البريد الإلكتروني/الحالة/الاجتماعات الذي يعود لعشر سنوات.
تقليل الحمولة الإضافية للبروتوكول قبل الحشو. بينما سيتم إضافة الحشو، وربما الكثير منه، الحمولة الإضافية قبل الحشو تبقى حمولة إضافية. يجب أن تكون العقد محدودة النطاق الترددي قادرة على استخدام NTCP2.
الحفاظ على الطوابع الزمنية لاكتشاف إعادة التشغيل والانحراف.
تجنب أي مشاكل العام 2038 في timestamps، يجب أن تعمل حتى عام 2106 على الأقل.
زيادة الحد الأقصى لحجم الرسالة من 16K إلى 32K أو 64K.
أي أساسيات تشفير جديدة يجب أن تكون متاحة بسهولة في المكتبات للاستخدام في تطبيقات router في Java (1.7) و C++ و Go.
تضمين ممثلين عن مطوري router في Java و C++ و Go في التصميم.
قلل التغييرات (لكن ستظل هناك الكثير منها).
دعم كلا الإصدارين في مجموعة مشتركة من الكود (قد لا يكون هذا ممكناً وهو يعتمد على التنفيذ في أي حال).

Non-Goals

مقاومة محصنة لفحص الحزم العميق (DPI)… وهذا يعني النقل القابل للإضافة، Prop109.
نقل مبني على TLS (أو يشبه HTTPS)… والذي سيكون Prop104.
لا بأس من تغيير التشفير المتماثل للتدفق.
مقاومة DPI القائمة على التوقيت (توقيت/تأخيرات الرسائل البينية يمكن أن تكون معتمدة على التنفيذ؛ التأخيرات داخل الرسائل يمكن إدخالها في أي نقطة، بما في ذلك قبل إرسال الحشو العشوائي، على سبيل المثال). التأخيرات الاصطناعية (ما يسميه obfs4 بـ IAT أو وقت الوصول البيني) مستقلة عن البروتوكول نفسه.
إنكار المشاركة في جلسة (هناك توقيعات بداخلها).

الأهداف غير المطلوبة التي قد يتم إعادة النظر فيها أو مناقشتها جزئياً:

درجة الحماية ضد فحص الحزم العميق (DPI)
أمان ما بعد الكم (PQ)
إمكانية الإنكار

تنفيذ إعداد اختبار NTCP 1/2

Security Goals

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

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

في الحد الأقصى، يمكن لمشاركين اثنين المشاركة في الهجمات النشطة.

أليس وبوب كلاهما يمتلك زوج مفاتيح ثابت، والذي يكون محتوى في RouterIdentity الخاص بهما.

البروتوكول المقترح يحاول السماح لـ Alice و Bob بالاتفاق على مفتاح سري مشترك (K) تحت المتطلبات التالية:

١) أمان المفتاح الخاص: لا يتعلم Bob ولا Mallory أي شيء عن المفتاح الخاص الثابت لـ Alice. وبالمثل، لا تتعلم Alice أي شيء عن المفتاح الخاص الثابت لـ Bob.

مفتاح الجلسة K معروف فقط من قبل Alice و Bob.

٣) السرية التامة للأمام: يبقى مفتاح الجلسة المتفق عليه سرياً في المستقبل، حتى عند كشف المفاتيح الخاصة الثابتة لأليس و/أو بوب بعد الاتفاق على المفتاح.

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

يحاول الاقتراح الحالي توفير جميع المتطلبات الخمسة بناءً على بروتوكول Station-To-Station (STS). لاحظ أن هذا البروتوكول هو أيضاً الأساس لبروتوكول SSU.

Additional DPI Discussion

نفترض وجود مكونين للـ DPI:

1) Online DPI

فحص DPI المباشر لجميع التدفقات في الوقت الفعلي. قد يتم حظر الاتصالات أو التلاعب بها بطرق أخرى. قد يتم تحديد وتخزين بيانات الاتصال أو البيانات الوصفية للتحليل غير المباشر. لا يمكن لـ DPI المباشر الوصول إلى قاعدة بيانات شبكة I2P. يمتلك DPI المباشر قدرة حاسوبية محدودة في الوقت الفعلي، بما في ذلك حساب الطول وفحص الحقول والحسابات البسيطة مثل XOR. يمتلك DPI المباشر القدرة على تنفيذ الوظائف التشفيرية السريعة في الوقت الفعلي مثل AES وAEAD والتجمع (hashing)، لكن هذه ستكون مكلفة جداً لتطبيقها على معظم أو جميع التدفقات. أي تطبيق لهذه العمليات التشفيرية سيقتصر فقط على التدفقات الموجودة على تركيبات IP/Port المحددة مسبقاً من خلال التحليل غير المباشر. لا يمتلك DPI المباشر القدرة على تنفيذ الوظائف التشفيرية عالية التكلفة مثل DH أو elligator2. لم يتم تصميم DPI المباشر خصيصاً لاكتشاف I2P، رغم أنه قد يحتوي على قواعد تصنيف محدودة لهذا الغرض.

إنه هدف لمنع تحديد البروتوكول بواسطة DPI عبر الإنترنت.

مفهوم DPI المباشر أو “المتقدم” عبر الإنترنت يشمل هنا قدرات الخصم التالية:

القدرة على فحص جميع البيانات المُرسلة أو المُستقبلة من قبل الهدف.
القدرة على تنفيذ عمليات على البيانات المرصودة، مثل تطبيق التشفير الكتلي أو دوال التجميع (hash functions).
القدرة على تخزين ومقارنة الرسائل المرسلة مسبقاً.
القدرة على تعديل أو تأخير أو تجزئة الحزم.

ومع ذلك، يُفترض أن الـ DPI المتصل بالإنترنت له القيود التالية:

عدم القدرة على ربط عناوين IP بقيم router hashes. في حين أن هذا أمر بسيط مع الوصول المباشر إلى قاعدة بيانات الشبكة، فإنه يتطلب نظام DPI مصمم خصيصاً لاستهداف I2P.
عدم القدرة على استخدام معلومات التوقيت لاكتشاف البروتوكول.
بشكل عام، صندوق أدوات DPI المتاح عبر الإنترنت لا يحتوي على أي أدوات مدمجة مصممة خصيصاً لاكتشاف I2P. هذا يشمل إنشاء “honeypots”، والتي قد تتضمن على سبيل المثال حشو غير عشوائي في رسائلها. لاحظ أن هذا لا يستبعد أنظمة التعلم الآلي أو أدوات DPI القابلة للتكوين بشكل كبير طالما أنها تلبي المتطلبات الأخرى.

لمواجهة تحليل الحمولة، يتم التأكد من أن جميع الرسائل غير قابلة للتمييز عن العشوائية. هذا يتطلب أيضاً أن يكون طولها عشوائياً، وهو أمر أكثر تعقيداً من مجرد إضافة حشو عشوائي. في الواقع، في الملحق A، يحتج المؤلفون أن مخطط الحشو البسيط (أي الموحد) لا يحل المشكلة. لذلك يقترح الملحق A تضمين إما تأخيرات عشوائية أو تطوير مخطط حشو بديل يمكنه توفير حماية معقولة ضد الهجوم المقترح.

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

2) Offline DPI

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

إن DPI غير المتصل لا يملك القدرة على حجب الاتصالات الموجودة. DPI غير المتصل يملك القدرة على الإرسال شبه الفوري (خلال دقائق من الإعداد) إلى host/port الخاص بالأطراف، على سبيل المثال TCP RST. DPI غير المتصل يملك القدرة على إعادة التشغيل شبه الفوري (خلال دقائق من الإعداد) للرسائل السابقة (معدلة أو غير معدلة) لأغراض “التحقيق” أو أسباب أخرى.

ليس الهدف هو منع تحديد البروتوكول بواسطة الفحص العميق للحزم (DPI) غير المتصل. جميع عمليات فك تشفير البيانات المشوشة في الرسالتين الأوليين، والتي تنفذها أجهزة I2P router، يمكن أيضاً تنفيذها بواسطة الفحص العميق للحزم غير المتصل.

الهدف هو رفض محاولات الاتصال التي تستخدم إعادة تشغيل الرسائل السابقة.

Future work

ضع في الاعتبار سلوك البروتوكول عندما يتم إسقاط الحزم أو إعادة ترتيبها من قبل مهاجم. يمكن العثور على أعمال حديثة مثيرة للاهتمام في هذا المجال في IACR-1150.
توفير تصنيف أكثر دقة لأنظمة DPI، مع مراعاة الأدبيات الموجودة المتعلقة بالموضوع.
ناقش الأمان الرسمي للبروتوكول المقترح، ويفضل أن يأخذ في الاعتبار نموذج المهاجم DPI.

Noise Protocol Framework

يقدم هذا الاقتراح المتطلبات المبنية على Noise Protocol Framework NOISE (المراجعة 33، 2017-10-04). يتمتع Noise بخصائص مشابهة لبروتوكول Station-To-Station، والذي يُعد الأساس لبروتوكول SSU. في مصطلحات Noise، أليس هي المُبادِرة، وبوب هو المُجيب.

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

نمط المصافحة: XK أليس ترسل مفتاحها إلى بوب (X) أليس تعرف المفتاح الثابت لبوب مسبقاً (K)
دالة DH: X25519 X25519 DH بطول مفتاح 32 بايت كما هو محدد في RFC-7748.
دالة التشفير: ChaChaPoly AEAD_CHACHA20_POLY1305 كما هو محدد في RFC-7539 القسم 2.8. nonce بحجم 12 بايت، مع تعيين أول 4 بايتات إلى الصفر.
Hash Function: SHA256 دالة تجمع قياسية بحجم 32 بايت، مستخدمة بالفعل على نطاق واسع في I2P.

أهداف الأمان

يحدد هذا الاقتراح التحسينات التالية على Noise_XK_25519_ChaChaPoly_SHA256. هذه التحسينات تتبع بشكل عام الإرشادات الواردة في NOISE القسم 13.

يتم حجب المفاتيح المؤقتة ذات النص الواضح بتشفير AES باستخدام مفتاح و IV معروفين. هذا أسرع من elligator2.
يتم إضافة حشو نصي واضح عشوائي إلى الرسائل 1 و 2. يتم تضمين الحشو النصي الواضح في حساب hash المصافحة (MixHash). راجع أقسام KDF أدناه للرسالة 2 والجزء الأول من الرسالة 3. يتم إضافة حشو AEAD عشوائي إلى الرسالة 3 ورسائل مرحلة البيانات.
يتم إضافة حقل طول الإطار المكون من بايتين، كما هو مطلوب لـ Noise عبر TCP، وكما في obfs4. يُستخدم هذا في رسائل مرحلة البيانات فقط. إطارات AEAD للرسالة 1 و 2 ذات طول ثابت. إطار AEAD للجزء الأول من الرسالة 3 ذو طول ثابت. طول إطار AEAD للجزء الثاني من الرسالة 3 محدد في الرسالة 1.
حقل طول الإطار المكون من بايتين يتم إخفاؤه باستخدام SipHash-2-4، كما هو الحال في obfs4.
تنسيق الحمولة محدد للرسائل 1،2،3، ومرحلة البيانات. بالطبع، هذا غير محدد في Noise.

New Cryptographic Primitives for I2P

تتطلب تطبيقات router I2P الحالية تنفيذ العمليات الأساسية للتشفير المعيارية التالية، والتي ليست مطلوبة لبروتوكولات I2P الحالية:

١) توليد مفتاح X25519 و DH

AEAD_ChaCha20_Poly1305 (يُختصر إلى ChaChaPoly أدناه)
SipHash-2-4

Processing overhead estimate

أحجام الرسائل للرسائل الثلاث:

١) ٦٤ بايت + حشو (كان NTCP ٢٨٨ بايت) ٢) ٦٤ بايت + حشو (كان NTCP ٣٠٤ بايت) ٣) حوالي ٦٤ بايت + معلومات router أليس + حشو متوسط معلومات router حوالي ٧٥٠ بايت المجموع المتوسط ٨١٤ بايت قبل الحشو (كان NTCP ٤٤٨ بايت) ٤) غير مطلوب في NTCP2 (كان NTCP ٤٨ بايت)

المجموع قبل الحشو: NTCP2: 942 بايت NTCP: 1088 بايت لاحظ أنه إذا اتصلت Alice بـ Bob بغرض إرسال رسالة DatabaseStore Message لـ RouterInfo الخاص بها، فإن تلك الرسالة غير مطلوبة، مما يوفر حوالي 800 بايت.

العمليات التشفيرية التالية مطلوبة من كل طرف لإكمال المصافحة وبدء مرحلة البيانات:

AES: 2
SHA256: 7 (أليس)، 6 (بوب) (لا يشمل 1 أليس، 2 بوب محسوبة مسبقاً لجميع الاتصالات) (لا يشمل HMAC-SHA256)
HMAC-SHA256: 19
ChaChaPoly: 4
توليد مفتاح X25519: 1
X25519 DH: 3
التحقق من التوقيع: 1 (بوب) (أليس وقعت مسبقاً عند توليد RI الخاص بها) على الأرجح Ed25519 (يعتمد على نوع توقيع RI)

العمليات التشفيرية التالية مطلوبة من كل طرف لكل رسالة في مرحلة البيانات:

SipHash: 1
ChaChaPoly: 1

Messages

جميع رسائل NTCP2 يبلغ طولها 65537 بايت أو أقل. تعتمد صيغة الرسالة على رسائل Noise، مع تعديلات للتأطير وعدم القابلية للتمييز. قد تحتاج التطبيقات التي تستخدم مكتبات Noise القياسية إلى معالجة مسبقة للرسائل المستلمة من/إلى صيغة رسائل Noise. جميع الحقول المشفرة هي نصوص مشفرة AEAD.

تسلسل التأسيس كما يلي:

Alice                           Bob

  SessionRequest ------------------->
  <------------------- SessionCreated
  SessionConfirmed ----------------->

باستخدام مصطلحات Noise، تسلسل الإنشاء والبيانات كما يلي: (خصائص أمان الحمولة)

XK(s, rs):           Authentication   Confidentiality
    <- s
    ...
    -> e, es                  0                2
    <- e, ee                  2                1
    -> s, se                  2                5
    <-                        2                5

بمجرد إنشاء جلسة، يمكن لأليس وبوب تبادل رسائل البيانات.

جميع أنواع الرسائل (SessionRequest، SessionCreated، SessionConfirmed، Data و TimeSync) محددة في هذا القسم.

بعض الرموز والتدوينات:

RH_A = Router Hash لـ Alice (32 بايت)
RH_B = Router Hash لـ Bob (32 بايت)

Authenticated Encryption

هناك ثلاث حالات منفصلة للتشفير المعتمد (CipherStates). واحدة خلال مرحلة المصافحة، واثنتان (إرسال واستقبال) لمرحلة البيانات. كل منها لها مفتاحها الخاص من KDF.

سيتم تمثيل البيانات المشفرة/المصادق عليها كما يلي

+----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |   Encrypted and authenticated data    |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

الأهداف غير المطلوبة

تنسيق البيانات المشفرة والمصادق عليها.

المدخلات إلى دوال التشفير/فك التشفير:

k :: 32 byte cipher key, as generated from KDF

  nonce :: Counter-based nonce, 12 bytes.
           Starts at 0 and incremented for each message.
           First four bytes are always zero.
           Last eight bytes are the counter, little-endian encoded.
           Maximum value is 2**64 - 2.
           Connection must be dropped and restarted after
           it reaches that value.
           The value 2**64 - 1 must never be sent.

  ad :: In handshake phase:
        Associated data, 32 bytes.
        The SHA256 hash of all preceding data.
        In data phase:
        Zero bytes

  data :: Plaintext data, 0 or more bytes

مخرجات دالة التشفير، مدخلات دالة فك التشفير:

+----+----+----+----+----+----+----+----+
  |Obfs Len |                             |
  +----+----+                             +
  |       ChaCha20 encrypted data         |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+
  |  Poly1305 Message Authentication Code |
  +              (MAC)                    +
  |             16 bytes                  |
  +----+----+----+----+----+----+----+----+

  Obfs Len :: Length of (encrypted data + MAC) to follow, 16 - 65535
              Obfuscation using SipHash (see below)
              Not used in message 1 or 2, or message 3 part 1, where the length is fixed
              Not used in message 3 part 1, as the length is specified in message 1

  encrypted data :: Same size as plaintext data, 0 - 65519 bytes

  MAC :: Poly1305 message authentication code, 16 bytes

بالنسبة لـ ChaCha20، ما هو موصوف هنا يتطابق مع RFC-7539، والذي يُستخدم أيضاً بشكل مشابه في TLS RFC-7905.

Notes

نظرًا لأن ChaCha20 هو شيفرة تدفق، فإن النصوص العادية لا تحتاج إلى حشو. يتم التخلص من بايتات تدفق المفاتيح الإضافية.
يتم الاتفاق على مفتاح التشفير (256 بت) باستخدام SHA256 KDF. تفاصيل KDF لكل رسالة موجودة في أقسام منفصلة أدناه.
إطارات ChaChaPoly للرسائل 1 و 2 والجزء الأول من الرسالة 3، لها حجم معروف. بدءاً من الجزء الثاني من الرسالة 3، الإطارات لها حجم متغير. حجم الجزء الأول من الرسالة 3 محدد في الرسالة 1. بدءاً من مرحلة البيانات، الإطارات مسبوقة بطول من بايتين مموه باستخدام SipHash كما في obfs4.
الحشو خارج إطار البيانات المصادق عليها للرسائل 1 و 2. يُستخدم الحشو في KDF للرسالة التالية لذلك سيتم اكتشاف أي تلاعب. بدءاً من الرسالة 3، يكون الحشو داخل إطار البيانات المصادق عليها.

الأهداف ذات الصلة

في الرسائل 1 و 2 وأجزاء الرسالة 3 الجزء 1 و 2، حجم رسالة AEAD معروف مسبقاً. عند فشل مصادقة AEAD، يجب على المستلم إيقاف معالجة الرسائل الإضافية وإغلاق الاتصال دون الرد. يجب أن يكون هذا إغلاق غير طبيعي (TCP RST).
لمقاومة التحقق، في الرسالة 1، بعد فشل AEAD، يجب على Bob تعيين مهلة زمنية عشوائية (النطاق لم يتم تحديده بعد) ثم قراءة عدد عشوائي من البايتات (النطاق لم يتم تحديده بعد) قبل إغلاق المقبس. يجب على Bob الاحتفاظ بقائمة سوداء لعناوين IP التي بها إخفاقات متكررة.
في مرحلة البيانات، يتم “تشفير” (إخفاء) حجم رسالة AEAD باستخدام SipHash. يجب توخي الحذر لتجنب إنشاء oracle فك تشفير. عند فشل مصادقة AEAD في مرحلة البيانات، يجب على المستقبل تعيين مهلة زمنية عشوائية (النطاق TBD) ثم قراءة عدد عشوائي من البايتات (النطاق TBD). بعد القراءة، أو عند انتهاء مهلة القراءة، يجب على المستقبل إرسال حمولة تحتوي على كتلة إنهاء تتضمن رمز سبب “فشل AEAD”، وإغلاق الاتصال.
اتخاذ نفس إجراء الخطأ لقيمة حقل الطول غير الصالحة في مرحلة البيانات.

Key Derivation Function (KDF) (for handshake message 1)

ينتج KDF مفتاح تشفير مرحلة المصافحة k من نتيجة DH، باستخدام HMAC-SHA256(key, data) كما هو محدد في RFC-2104. هذه هي الدوال InitializeSymmetric()، و MixHash()، و MixKey()، تماماً كما هو محدد في مواصفات Noise.

This is the "e" message pattern:

  // Define protocol_name.
  Set protocol_name = "Noise_XKaesobfse+hs2+hs3_25519_ChaChaPoly_SHA256"
   (48 bytes, US-ASCII encoded, no NULL termination).

  // Define Hash h = 32 bytes
  h = SHA256(protocol_name);

  Define ck = 32 byte chaining key. Copy the h data to ck.
  Set ck = h

  Define rs = Bob's 32-byte static key as published in the RouterInfo

  // MixHash(null prologue)
  h = SHA256(h);

  // up until here, can all be precalculated by Alice for all outgoing connections

  // Alice must validate that Bob's static key is a valid point on the curve here.

  // Bob static key
  // MixHash(rs)
  // || below means append
  h = SHA256(h || rs);

  // up until here, can all be precalculated by Bob for all incoming connections

  This is the "e" message pattern:

  Alice generates her ephemeral DH key pair e.

  // Alice ephemeral key X
  // MixHash(e.pubkey)
  // || below means append
  h = SHA256(h || e.pubkey);

  // h is used as the associated data for the AEAD in message 1
  // Retain the Hash h for the message 2 KDF


  End of "e" message pattern.

  This is the "es" message pattern:

  // DH(e, rs) == DH(s, re)
  Define input_key_material = 32 byte DH result of Alice's ephemeral key and Bob's static key
  Set input_key_material = X25519 DH result

  // MixKey(DH())

  Define temp_key = 32 bytes
  Define HMAC-SHA256(key, data) as in [RFC-2104](https://tools.ietf.org/html/rfc2104)
  // Generate a temp key from the chaining key and DH result
  // ck is the chaining key, defined above
  temp_key = HMAC-SHA256(ck, input_key_material)
  // overwrite the DH result in memory, no longer needed
  input_key_material = (all zeros)

  // Output 1
  // Set a new chaining key from the temp key
  // byte() below means a single byte
  ck =       HMAC-SHA256(temp_key, byte(0x01)).

  // Output 2
  // Generate the cipher key k
  Define k = 32 bytes
  // || below means append
  // byte() below means a single byte
  k =        HMAC-SHA256(temp_key, ck || byte(0x02)).
  // overwrite the temp_key in memory, no longer needed
  temp_key = (all zeros)

  // retain the chaining key ck for message 2 KDF


  End of "es" message pattern.

مناقشة إضافية حول DPI

أليس ترسل إلى بوب.

محتوى Noise: مفتاح Alice المؤقت X حمولة Noise: كتلة خيار 16 بايت حمولة غير Noise: حشو عشوائي

(خصائص أمان الحمولة)

XK(s, rs):           Authentication   Confidentiality
    -> e, es                  0                2

    Authentication: None (0).
    This payload may have been sent by any party, including an active attacker.

    Confidentiality: 2.
    Encryption to a known recipient, forward secrecy for sender compromise
    only, vulnerable to replay.  This payload is encrypted based only on DHs
    involving the recipient's static key pair.  If the recipient's static
    private key is compromised, even at a later date, this payload can be
    decrypted.  This message can also be replayed, since there's no ephemeral
    contribution from the recipient.

    "e": Alice generates a new ephemeral key pair and stores it in the e
         variable, writes the ephemeral public key as cleartext into the
         message buffer, and hashes the public key along with the old h to
         derive a new h.

    "es": A DH is performed between the Alice's ephemeral key pair and the
          Bob's static key pair.  The result is hashed along with the old ck to
          derive a new ck and k, and n is set to zero.

القيمة X مشفرة لضمان عدم التمييز وفرادة الحمولة، والتي تعتبر تدابير مضادة ضرورية لـ DPI. نستخدم تشفير AES لتحقيق هذا، بدلاً من البدائل الأكثر تعقيداً وبطئاً مثل elligator2. التشفير غير المتماثل لمفتاح router العام الخاص بـ Bob سيكون بطيئاً جداً. يستخدم تشفير AES قيمة hash الخاصة بـ router Bob كمفتاح و IV الخاص بـ Bob كما هو منشور في قاعدة بيانات الشبكة.

تشفير AES مخصص لمقاومة DPI فقط. أي طرف يعرف router hash الخاص بـ Bob، وال IV، المنشورين في قاعدة بيانات الشبكة، يمكنه فك تشفير قيمة X في هذه الرسالة.

الحشو غير مشفر بواسطة Alice. قد يكون من الضروري لـ Bob فك تشفير الحشو، لمنع هجمات التوقيت.

المحتويات الخام:

+----+----+----+----+----+----+----+----+
|                                       |
+        obfuscated with RH_B           +
|       AES-CBC-256 encrypted X         |
+             (32 bytes)                +
|                                       |
+                                       +
|                                       |
+----+----+----+----+----+----+----+----+
|                                       |
+                                       +
|   ChaChaPoly frame                    |
+             (32 bytes)                +
|   k defined in KDF for message 1      |
+   n = 0                               +
|   see KDF for associated data         |
+----+----+----+----+----+----+----+----+
|     unencrypted authenticated         |
~         padding (optional)            ~
|     length defined in options block   |
+----+----+----+----+----+----+----+----+

X :: 32 bytes, AES-256-CBC encrypted X25519 ephemeral key, little endian
        key: RH_B
        iv: As published in Bobs network database entry

padding :: Random data, 0 or more bytes.
           Total message length must be 65535 bytes or less.
           Total message length must be 287 bytes or less if
           Bob is publishing his address as NTCP
           (see Version Detection section below).
           Alice and Bob will use the padding data in the KDF for message 2.
           It is authenticated so that any tampering will cause the
           next message to fail.

البيانات غير المشفرة (علامة المصادقة Poly1305 غير معروضة):

+----+----+----+----+----+----+----+----+
|                                       |
+                                       +
|                   X                   |
+              (32 bytes)               +
|                                       |
+                                       +
|                                       |
+----+----+----+----+----+----+----+----+
|               options                 |
+              (16 bytes)               +
|                                       |
+----+----+----+----+----+----+----+----+
|     unencrypted authenticated         |
+         padding (optional)            +
|     length defined in options block   |
~               .   .   .               ~
|                                       |
+----+----+----+----+----+----+----+----+

X :: 32 bytes, X25519 ephemeral key, little endian

options :: options block, 16 bytes, see below

padding :: Random data, 0 or more bytes.
           Total message length must be 65535 bytes or less.
           Total message length must be 287 bytes or less if
           Bob is publishing his address as "NTCP"
           (see Version Detection section below)
           Alice and Bob will use the padding data in the KDF for message 2.
           It is authenticated so that any tampering will cause the
           next message to fail.

كتلة الخيارات: ملاحظة: جميع الحقول بترتيب البايت الكبير (big-endian).

+----+----+----+----+----+----+----+----+
| id | ver|  padLen | m3p2len | Rsvd(0) |
+----+----+----+----+----+----+----+----+
|        tsA        |   Reserved (0)    |
+----+----+----+----+----+----+----+----+

id :: 1 byte, the network ID (currently 2, except for test networks)
      As of 0.9.42. See proposal 147.

ver :: 1 byte, protocol version (currently 2)

padLen :: 2 bytes, length of the padding, 0 or more
          Min/max guidelines TBD. Random size from 0 to 31 bytes minimum?
          (Distribution to be determined, see Appendix A.)

m3p2Len :: 2 bytes, length of the the second AEAD frame in SessionConfirmed
           (message 3 part 2) See notes below

Rsvd :: 2 bytes, set to 0 for compatibility with future options

tsA :: 4 bytes, Unix timestamp, unsigned seconds.
       Wraps around in 2106

Reserved :: 4 bytes, set to 0 for compatibility with future options

Notes

عندما يكون العنوان المنشور “NTCP”، يدعم Bob كلاً من NTCP و NTCP2 على نفس المنفذ. للتوافق، عند بدء اتصال إلى عنوان منشور كـ “NTCP”، يجب على Alice تحديد الحد الأقصى لحجم هذه الرسالة، بما في ذلك الحشو، إلى 287 بايت أو أقل. هذا يسهل التعرف التلقائي على البروتوكول من قبل Bob. عندما يُنشر كـ “NTCP2”، لا يوجد قيد على الحجم. راجع أقسام العناوين المنشورة وكشف الإصدار أدناه.
القيمة الفريدة X في كتلة AES الأولية تضمن أن النص المشفر مختلف لكل جلسة.
يجب على Bob رفض الاتصالات التي تكون فيها قيمة الطابع الزمني بعيدة جداً عن الوقت الحالي. نسمي أقصى وقت انحراف “D”. يجب على Bob الاحتفاظ بذاكرة تخزين مؤقت محلية لقيم المصافحة المستخدمة سابقاً ورفض المكررات، لمنع هجمات الإعادة. يجب أن تكون للقيم في الذاكرة المؤقتة مدة حياة لا تقل عن 2*D. قيم الذاكرة المؤقتة تعتمد على التطبيق، ولكن يمكن استخدام قيمة X البالغة 32 بايت (أو ما يعادلها المشفر).
مفاتيح Diffie-Hellman المؤقتة يجب ألا يُعاد استخدامها أبداً، لمنع الهجمات التشفيرية، وإعادة الاستخدام سيتم رفضها كهجوم إعادة تشغيل.
يجب أن تكون خيارات “KE” و “auth” متوافقة، أي أن المفتاح المشترك K يجب أن يكون بالحجم المناسب. إذا تمت إضافة المزيد من خيارات “auth”، فقد يؤدي ذلك ضمنياً إلى تغيير معنى علامة “KE” لاستخدام KDF مختلف أو حجم اقتطاع مختلف.
يجب على Bob التحقق من أن مفتاح Alice المؤقت هو نقطة صالحة على المنحنى هنا.
يجب أن يكون الحشو محدود بكمية معقولة. قد يرفض Bob الاتصالات التي تحتوي على حشو مفرط. سيحدد Bob خيارات الحشو الخاصة به في الرسالة 2. إرشادات الحد الأدنى/الأقصى لم تحدد بعد. حجم عشوائي من 0 إلى 31 بايت كحد أدنى؟ (سيتم تحديد التوزيع، انظر الملحق أ.)
عند حدوث أي خطأ، بما في ذلك AEAD أو DH أو الطابع الزمني أو إعادة التشغيل الظاهرة أو فشل التحقق من المفتاح، يجب على Bob إيقاف معالجة الرسائل الإضافية وإغلاق الاتصال دون الاستجابة. يجب أن يكون هذا إغلاقاً غير طبيعي (TCP RST). لمقاومة التحقق، بعد فشل AEAD، يجب على Bob تعيين مهلة زمنية عشوائية (النطاق قيد التحديد) ثم قراءة عدد عشوائي من البايتات (النطاق قيد التحديد)، قبل إغلاق المقبس.
التخفيف من هجمات حجب الخدمة: DH هي عملية مكلفة نسبياً. كما هو الحال مع بروتوكول NTCP السابق، يجب على أجهزة router اتخاذ جميع الإجراءات اللازمة لمنع استنزاف وحدة المعالجة المركزية أو الاتصالات. ضع حدود على الحد الأقصى للاتصالات النشطة والحد الأقصى لإعدادات الاتصال قيد التقدم. فرض مهلات زمنية للقراءة (لكل قراءة وإجمالية لـ “slowloris”). حدد الاتصالات المتكررة أو المتزامنة من نفس المصدر. احتفظ بقوائم سوداء للمصادر التي تفشل بشكل متكرر. لا تستجب لفشل AEAD.
لتسهيل الكشف السريع عن الإصدار وتبادل المصافحة، يجب على التطبيقات التأكد من أن Alice تقوم بتخزين محتويات الرسالة الأولى كاملة في المخزن المؤقت ثم تفريغها دفعة واحدة، بما في ذلك الحشو. هذا يزيد من احتمالية أن تكون البيانات موجودة في حزمة TCP واحدة (ما لم يتم تقسيمها بواسطة نظام التشغيل أو الأجهزة الوسطية)، وأن يستقبلها Bob دفعة واحدة. بالإضافة إلى ذلك، يجب على التطبيقات التأكد من أن Bob يقوم بتخزين محتويات الرسالة الثانية كاملة في المخزن المؤقت ثم تفريغها دفعة واحدة، بما في ذلك الحشو. وأن Bob يقوم بتخزين محتويات الرسالة الثالثة كاملة في المخزن المؤقت ثم تفريغها دفعة واحدة. هذا أيضاً لتحسين الكفاءة وضمان فعالية الحشو العشوائي.
حقل “ver”: بروتوكول Noise الشامل والإضافات وبروتوكول NTCP بما في ذلك مواصفات الحمولة، مما يشير إلى NTCP2. قد يُستخدم هذا الحقل للإشارة إلى الدعم للتغييرات المستقبلية.
طول الجزء الثاني من الرسالة 3: هذا هو حجم إطار AEAD الثاني (متضمناً MAC بحجم 16 بايت) الذي يحتوي على Router Info الخاصة بأليس والحشو الاختياري الذي سيتم إرساله في رسالة SessionConfirmed. نظراً لأن الموجهات تقوم دورياً بإعادة توليد ونشر Router Info الخاصة بها، فقد يتغير حجم Router Info الحالية قبل إرسال الرسالة 3. يجب على التطبيقات اختيار إحدى الاستراتيجيتين التاليتين: أ) حفظ Router Info الحالية لإرسالها في الرسالة 3، بحيث يكون الحجم معروفاً، وإضافة مساحة للحشو اختيارياً؛ ب) زيادة الحجم المحدد بما فيه الكفاية للسماح بزيادة محتملة في حجم Router Info، وإضافة الحشو دائماً عند إرسال الرسالة 3 فعلياً. في كلتا الحالتين، يجب أن يكون طول “m3p2len” المتضمن في الرسالة 1 مطابقاً تماماً لحجم ذلك الإطار عند إرساله في الرسالة 3.
يجب على Bob أن يُفشل الاتصال إذا بقيت أي بيانات واردة بعد التحقق من صحة الرسالة 1 وقراءة الحشو. يجب ألا تكون هناك بيانات إضافية من Alice، حيث أن Bob لم يرد برسالة 2 بعد.
يُستخدم حقل معرف الشبكة (network ID) للتعرف بسرعة على الاتصالات عبر الشبكات. إذا كان هذا الحقل غير صفري، ولا يتطابق مع معرف شبكة Bob، يجب على Bob قطع الاتصال وحظر الاتصالات المستقبلية. اعتباراً من الإصدار 0.9.42. راجع المقترح 147 لمزيد من المعلومات.

Key Derivation Function (KDF) (for handshake message 2 and message 3 part 1)


// take h saved from message 1 KDF
// MixHash(ciphertext)
h = SHA256(h || 32 byte encrypted payload from message 1)

// MixHash(padding)
// Only if padding length is nonzero
h = SHA256(h || random padding from message 1)

This is the "e" message pattern:

Bob generates his ephemeral DH key pair e.

// h is from KDF for handshake message 1
// Bob ephemeral key Y
// MixHash(e.pubkey)
// || below means append
h = SHA256(h || e.pubkey);

// h is used as the associated data for the AEAD in message 2
// Retain the Hash h for the message 3 KDF

End of "e" message pattern.

This is the "ee" message pattern:

// DH(e, re)
Define input_key_material = 32 byte DH result of Alice's ephemeral key and Bob's ephemeral key
Set input_key_material = X25519 DH result
// overwrite Alice's ephemeral key in memory, no longer needed
// Alice:
e(public and private) = (all zeros)
// Bob:
re = (all zeros)

// MixKey(DH())

Define temp_key = 32 bytes
Define HMAC-SHA256(key, data) as in [RFC-2104](https://tools.ietf.org/html/rfc2104)
// Generate a temp key from the chaining key and DH result
// ck is the chaining key, from the KDF for handshake message 1
temp_key = HMAC-SHA256(ck, input_key_material)
// overwrite the DH result in memory, no longer needed
input_key_material = (all zeros)

// Output 1
// Set a new chaining key from the temp key
// byte() below means a single byte
ck =       HMAC-SHA256(temp_key, byte(0x01)).

// Output 2
// Generate the cipher key k
Define k = 32 bytes
// || below means append
// byte() below means a single byte
k =        HMAC-SHA256(temp_key, ck || byte(0x02)).
// overwrite the temp_key in memory, no longer needed
temp_key = (all zeros)

// retain the chaining key ck for message 3 KDF

End of "ee" message pattern.

2) SessionCreated

بوب يرسل إلى أليس.

محتوى Noise: مفتاح Bob المؤقت Y حمولة Noise: كتلة خيارات 16 بايت حمولة غير Noise: حشو عشوائي

(خصائص أمان الحمولة)

XK(s, rs):           Authentication   Confidentiality
  <- e, ee                  2                1

  Authentication: 2.
  Sender authentication resistant to key-compromise impersonation (KCI).
  The sender authentication is based on an ephemeral-static DH ("es" or "se")
  between the sender's static key pair and the recipient's ephemeral key pair.
  Assuming the corresponding private keys are secure, this authentication cannot be forged.

  Confidentiality: 1.
  Encryption to an ephemeral recipient.
  This payload has forward secrecy, since encryption involves an ephemeral-ephemeral DH ("ee").
  However, the sender has not authenticated the recipient,
  so this payload might be sent to any party, including an active attacker.


  "e": Bob generates a new ephemeral key pair and stores it in the e variable,
  writes the ephemeral public key as cleartext into the message buffer,
  and hashes the public key along with the old h to derive a new h.

  "ee": A DH is performed between the Bob's ephemeral key pair and the Alice's ephemeral key pair.
  The result is hashed along with the old ck to derive a new ck and k, and n is set to zero.

قيمة Y مشفرة لضمان عدم القدرة على التمييز وفرادة الحمولة، وهما إجراءان ضروريان لمواجهة فحص الحزم العميق. نحن نستخدم تشفير AES لتحقيق ذلك، بدلاً من البدائل الأكثر تعقيداً وبطئاً مثل elligator2. التشفير غير المتناظر لمفتاح router العام لـ Alice سيكون بطيئاً جداً. تشفير AES يستخدم hash الخاص بـ router الخاص بـ Bob كمفتاح وحالة AES من الرسالة الأولى (التي تم تهيئتها مع IV الخاص بـ Bob كما هو منشور في قاعدة بيانات الشبكة).

تشفير AES مخصص لمقاومة DPI فقط. أي طرف يعرف router hash الخاص بـ Bob و IV، واللذان منشوران في قاعدة بيانات الشبكة، والتقط أول 32 بايت من الرسالة 1، قد يفك تشفير قيمة Y في هذه الرسالة.

المحتويات الخام:

+----+----+----+----+----+----+----+----+
|                                       |
+        obfuscated with RH_B           +
|       AES-CBC-256 encrypted Y         |
+              (32 bytes)               +
|                                       |
+                                       +
|                                       |
+----+----+----+----+----+----+----+----+
|   ChaChaPoly frame                    |
+   Encrypted and authenticated data    +
|   32 bytes                            |
+   k defined in KDF for message 2      +
|   n = 0; see KDF for associated data  |
+                                       +
|                                       |
+----+----+----+----+----+----+----+----+
|     unencrypted authenticated         |
+         padding (optional)            +
|     length defined in options block   |
~               .   .   .               ~
|                                       |
+----+----+----+----+----+----+----+----+

Y :: 32 bytes, AES-256-CBC encrypted X25519 ephemeral key, little endian
        key: RH_B
        iv: Using AES state from message 1

البيانات غير المشفرة (علامة المصادقة Poly1305 غير معروضة):

+----+----+----+----+----+----+----+----+
|                                       |
+                                       +
|                  Y                    |
+              (32 bytes)               +
|                                       |
+                                       +
|                                       |
+----+----+----+----+----+----+----+----+
|               options                 |
+              (16 bytes)               +
|                                       |
+----+----+----+----+----+----+----+----+
|     unencrypted authenticated         |
+         padding (optional)            +
|     length defined in options block   |
~               .   .   .               ~
|                                       |
+----+----+----+----+----+----+----+----+

Y :: 32 bytes, X25519 ephemeral key, little endian

options :: options block, 16 bytes, see below

padding :: Random data, 0 or more bytes.
           Total message length must be 65535 bytes or less.
           Alice and Bob will use the padding data in the KDF for message 3 part 1.
           It is authenticated so that any tampering will cause the
           next message to fail.

Notes

يجب على Alice التحقق من أن مفتاح Bob المؤقت هو نقطة صالحة على المنحنى هنا.
يجب أن تكون الحشوة محدودة بكمية معقولة. قد ترفض Alice الاتصالات ذات الحشوة المفرطة. ستحدد Alice خيارات الحشوة الخاصة بها في الرسالة 3. إرشادات الحد الأدنى/الأقصى لم تحدد بعد. حجم عشوائي من 0 إلى 31 بايت كحد أدنى؟ (التوزيع لم يحدد بعد، انظر الملحق A.)
في حالة حدوث أي خطأ، بما في ذلك AEAD أو DH أو timestamp أو replay ظاهر أو فشل التحقق من المفتاح، يجب على Alice إيقاف معالجة الرسائل الإضافية وإغلاق الاتصال دون الرد. يجب أن يكون هذا إغلاقاً غير طبيعي (TCP RST).
لتسهيل المصافحة السريعة، يجب على التطبيقات التأكد من أن Bob يخزن مؤقتاً ثم يطرد محتويات الرسالة الأولى بالكامل دفعة واحدة، بما في ذلك الحشو. هذا يزيد من احتمالية أن تكون البيانات محتواة في حزمة TCP واحدة (ما لم يتم تقسيمها بواسطة نظام التشغيل أو middleboxes)، و يتم استقبالها دفعة واحدة بواسطة Alice. هذا أيضاً من أجل الكفاءة ولضمان فعالية الحشو العشوائي.
يجب على Alice أن تُفشل الاتصال إذا بقيت أي بيانات واردة بعد التحقق من صحة الرسالة 2 وقراءة الحشو. يجب ألا تكون هناك بيانات إضافية من Bob، حيث أن Alice لم تستجب بالرسالة 3 بعد.

كتلة الخيارات: ملاحظة: جميع الحقول بنظام big-endian.


+----+----+----+----+----+----+----+----+
| Rsvd(0) | padLen  |   Reserved (0)    |
+----+----+----+----+----+----+----+----+
|        tsB        |   Reserved (0)    |
+----+----+----+----+----+----+----+----+

Reserved :: 10 bytes total, set to 0 for compatibility with future options

padLen :: 2 bytes, big endian, length of the padding, 0 or more
          Min/max guidelines TBD. Random size from 0 to 31 bytes minimum?
          (Distribution to be determined, see Appendix A.)

tsB :: 4 bytes, big endian, Unix timestamp, unsigned seconds.
       Wraps around in 2106

Notes

يجب على Alice رفض الاتصالات حيث تكون قيمة الطابع الزمني بعيدة جداً عن الوقت الحالي. نسمي الحد الأقصى لفرق الوقت “D”. يجب على Alice الاحتفاظ بذاكرة تخزين مؤقت محلية للقيم المستخدمة سابقاً في المصافحة ورفض التكرارات، لمنع هجمات الإعادة. يجب أن تكون للقيم في ذاكرة التخزين المؤقت مدة حياة لا تقل عن 2*D. قيم ذاكرة التخزين المؤقت تعتمد على التنفيذ، ولكن يمكن استخدام قيمة Y البالغة 32 بايت (أو ما يعادلها مشفراً).

Issues

هل يجب تضمين خيارات الحشو الأدنى/الأقصى هنا؟

Encryption for for handshake message 3 part 1, using message 2 KDF)


// take h saved from message 2 KDF
// MixHash(ciphertext)
h = SHA256(h || 24 byte encrypted payload from message 2)

// MixHash(padding)
// Only if padding length is nonzero
h = SHA256(h || random padding from message 2)
// h is used as the associated data for the AEAD in message 3 part 1, below

This is the "s" message pattern:

Define s = Alice's static public key, 32 bytes

// EncryptAndHash(s.publickey)
// EncryptWithAd(h, s.publickey)
// AEAD_ChaCha20_Poly1305(key, nonce, associatedData, data)
// k is from handshake message 1
// n is 1
ciphertext = AEAD_ChaCha20_Poly1305(k, n++, h, s.publickey)
// MixHash(ciphertext)
// || below means append
h = SHA256(h || ciphertext);

// h is used as the associated data for the AEAD in message 3 part 2

End of "s" message pattern.

Key Derivation Function (KDF) (for handshake message 3 part 2)


This is the "se" message pattern:

// DH(s, re) == DH(e, rs)
Define input_key_material = 32 byte DH result of Alice's static key and Bob's ephemeral key
Set input_key_material = X25519 DH result
// overwrite Bob's ephemeral key in memory, no longer needed
// Alice:
re = (all zeros)
// Bob:
e(public and private) = (all zeros)

// MixKey(DH())

Define temp_key = 32 bytes
Define HMAC-SHA256(key, data) as in [RFC-2104](https://tools.ietf.org/html/rfc2104)
// Generate a temp key from the chaining key and DH result
// ck is the chaining key, from the KDF for handshake message 1
temp_key = HMAC-SHA256(ck, input_key_material)
// overwrite the DH result in memory, no longer needed
input_key_material = (all zeros)

// Output 1
// Set a new chaining key from the temp key
// byte() below means a single byte
ck =       HMAC-SHA256(temp_key, byte(0x01)).

// Output 2
// Generate the cipher key k
Define k = 32 bytes
// || below means append
// byte() below means a single byte
k =        HMAC-SHA256(temp_key, ck || byte(0x02)).

// h from message 3 part 1 is used as the associated data for the AEAD in message 3 part 2

// EncryptAndHash(payload)
// EncryptWithAd(h, payload)
// AEAD_ChaCha20_Poly1305(key, nonce, associatedData, data)
// n is 0
ciphertext = AEAD_ChaCha20_Poly1305(k, n++, h, payload)
// MixHash(ciphertext)
// || below means append
h = SHA256(h || ciphertext);

// retain the chaining key ck for the data phase KDF
// retain the hash h for the data phase Additional Symmetric Key (SipHash) KDF

End of "se" message pattern.

// overwrite the temp_key in memory, no longer needed
temp_key = (all zeros)

3) SessionConfirmed

أليس ترسل إلى بوب.

محتوى Noise: مفتاح Alice الثابت حمولة Noise: RouterInfo الخاص بـ Alice وحشو عشوائي حمولة غير-noise: لا شيء

(خصائص أمان الحمولة)

XK(s, rs):           Authentication   Confidentiality
  -> s, se                  2                5

  Authentication: 2.
  Sender authentication resistant to key-compromise impersonation (KCI).  The
  sender authentication is based on an ephemeral-static DH ("es" or "se")
  between the sender's static key pair and the recipient's ephemeral key
  pair.  Assuming the corresponding private keys are secure, this
  authentication cannot be forged.

  Confidentiality: 5.
  Encryption to a known recipient, strong forward secrecy.  This payload is
  encrypted based on an ephemeral-ephemeral DH as well as an ephemeral-static
  DH with the recipient's static key pair.  Assuming the ephemeral private
  keys are secure, and the recipient is not being actively impersonated by an
  attacker that has stolen its static private key, this payload cannot be
  decrypted.

  "s": Alice writes her static public key from the s variable into the
  message buffer, encrypting it, and hashes the output along with the old h
  to derive a new h.

  "se": A DH is performed between the Alice's static key pair and the Bob's
  ephemeral key pair.  The result is hashed along with the old ck to derive a
  new ck and k, and n is set to zero.

يحتوي هذا على إطارين من ChaChaPoly. الأول هو مفتاح Alice العام الثابت المُشفر. والثاني هو حمولة Noise: RouterInfo المُشفر الخاص بـ Alice، والخيارات الاختيارية، والحشو الاختياري. يستخدمان مفاتيح مختلفة، لأن دالة MixKey() يتم استدعاؤها بينهما.

المحتويات الخام:

+----+----+----+----+----+----+----+----+
|                                       |
+   ChaChaPoly frame (48 bytes)         +
|   Encrypted and authenticated         |
+   Alice static key S                  +
|      (32 bytes)                       |
+                                       +
|     k defined in KDF for message 2    |
+     n = 1                             +
|     see KDF for associated data       |
+                                       +
|                                       |
+----+----+----+----+----+----+----+----+
|                                       |
+     Length specified in message 1     +
|                                       |
+   ChaChaPoly frame                    +
|   Encrypted and authenticated         |
+                                       +
|       Alice RouterInfo                |
+       using block format 2            +
|       Alice Options (optional)        |
+       using block format 1            +
|       Arbitrary padding               |
+       using block format 254          +
|                                       |
+                                       +
| k defined in KDF for message 3 part 2 |
+     n = 0                             +
|     see KDF for associated data       |
~               .   .   .               ~
|                                       |
+----+----+----+----+----+----+----+----+

S :: 32 bytes, ChaChaPoly encrypted Alice's X25519 static key, little endian
     inside 48 byte ChaChaPoly frame

البيانات غير المشفرة (علامات مصادقة Poly1305 غير معروضة):

+----+----+----+----+----+----+----+----+
|                                       |
+                                       +
|              S                        |
+       Alice static key                +
|          (32 bytes)                   |
+                                       +
|                                       |
+                                       +
+----+----+----+----+----+----+----+----+
|                                       |
+                                       +
|                                       |
+                                       +
|       Alice RouterInfo block          |
~               .   .   .               ~
|                                       |
+----+----+----+----+----+----+----+----+
|                                       |
+       Optional Options block          +
|                                       |
~               .   .   .               ~
|                                       |
+----+----+----+----+----+----+----+----+
|                                       |
+       Optional Padding block          +
|                                       |
~               .   .   .               ~
|                                       |
+----+----+----+----+----+----+----+----+

S :: 32 bytes, Alice's X25519 static key, little endian

١) فحص الحزم العميق المباشر (Online DPI)

يجب على Bob تنفيذ التحقق المعتاد من Router Info. تأكد من أن نوع التوقيع مدعوم، وتحقق من التوقيع، وتحقق من أن الطابع الزمني ضمن الحدود المقبولة، وأي فحوصات أخرى ضرورية.
يجب على Bob التحقق من أن المفتاح الثابت الخاص بـ Alice المستلم في الإطار الأول يطابق المفتاح الثابت في Router Info. يجب على Bob أولاً البحث في Router Info عن عنوان NTCP أو NTCP2 Router Address مع خيار إصدار (v) مطابق. انظر أقسام Published Router Info و Unpublished Router Info أدناه.
إذا كان لدى Bob إصدارًا أقدم من RouterInfo الخاص بـ Alice في netdb الخاص به، تحقق من أن المفتاح الثابت في معلومات الموجه router info هو نفسه في كليهما، إن وجد، وإذا كان الإصدار الأقدم أقل من XXX قدمًا (انظر وقت تدوير المفتاح أدناه)
يجب على Bob التحقق من أن المفتاح الثابت لـ Alice هو نقطة صالحة على المنحنى هنا.
يجب تضمين الخيارات، لتحديد معاملات الحشو.
في حالة حدوث أي خطأ، بما في ذلك فشل في AEAD أو RI أو DH أو timestamp أو التحقق من المفاتيح، يجب على Bob إيقاف معالجة الرسائل الإضافية وإغلاق الاتصال دون الاستجابة. يجب أن يكون هذا إغلاقاً غير طبيعي (TCP RST).
لتسهيل المصافحة السريعة، يجب على التطبيقات ضمان أن Alice تقوم بتخزين مؤقت ثم تفريغ محتويات الرسالة الثالثة بالكامل مرة واحدة، بما في ذلك كلا إطاري AEAD. هذا يزيد من احتمالية أن تكون البيانات محتواة في حزمة TCP واحدة (ما لم يتم تقسيمها بواسطة نظام التشغيل أو middleboxes)، ويتم استقبالها دفعة واحدة بواسطة Bob. هذا أيضاً للكفاءة ولضمان فعالية الحشو العشوائي.
طول إطار الجزء الثاني من الرسالة 3: يتم إرسال طول هذا الإطار (بما في ذلك MAC) بواسطة Alice في الرسالة 1. انظر تلك الرسالة للملاحظات المهمة حول ترك مساحة كافية للحشو.
محتوى إطار الجزء الثاني من الرسالة 3: تنسيق هذا الإطار هو نفس تنسيق إطارات مرحلة البيانات، باستثناء أن طول الإطار يتم إرساله من قبل Alice في الرسالة 1. انظر أدناه لتنسيق إطار مرحلة البيانات. يجب أن يحتوي الإطار على 1 إلى 3 كتل بالترتيب التالي:
1. كتلة Router Info الخاصة بـ Alice (مطلوبة)
2. كتلة الخيارات (اختيارية)
3. كتلة الحشو (اختيارية) يجب ألا يحتوي هذا الإطار أبداً على أي نوع آخر من الكتل.
حشو الجزء الثاني من الرسالة 3 غير مطلوب إذا قامت Alice بإلحاق إطار مرحلة البيانات (يحتوي اختياريًا على حشو) في نهاية الرسالة 3 وإرسال كلاهما معًا، حيث سيظهر كتدفق كبير واحد من البايتات للمراقب. نظرًا لأن Alice ستكون لديها عمومًا، ولكن ليس دائمًا، رسالة I2NP لإرسالها إلى Bob (لهذا السبب اتصلت به)، فهذا هو التنفيذ الموصى به، للكفاءة ولضمان فعالية الحشو العشوائي.
الطول الإجمالي لكلا إطاري Message 3 AEAD (الجزء 1 والجزء 2) هو 65535 بايت؛ الجزء 1 يبلغ 48 بايت لذلك الحد الأقصى لطول إطار الجزء 2 هو 65487؛ الحد الأقصى لطول النص المفكوك للجزء 2 باستثناء MAC هو 65471.

Key Derivation Function (KDF) (for data phase)

مرحلة البيانات تستخدم مدخل بيانات مرتبطة بطول صفر.

يُولد KDF مفتاحي تشفير k_ab و k_ba من مفتاح التسلسل ck، باستخدام HMAC-SHA256(key, data) كما هو محدد في RFC-2104. هذه هي دالة Split()، تماماً كما هي محددة في مواصفات Noise.


ck = from handshake phase

// k_ab, k_ba = HKDF(ck, zerolen)
// ask_master = HKDF(ck, zerolen, info="ask")

// zerolen is a zero-length byte array
temp_key = HMAC-SHA256(ck, zerolen)
// overwrite the chaining key in memory, no longer needed
ck = (all zeros)

// Output 1
// cipher key, for Alice transmits to Bob (Noise doesn't make clear which is which, but Java code does)
k_ab =   HMAC-SHA256(temp_key, byte(0x01)).

// Output 2
// cipher key, for Bob transmits to Alice (Noise doesn't make clear which is which, but Java code does)
k_ba =   HMAC-SHA256(temp_key, k_ab || byte(0x02)).


KDF for SipHash for length field:
Generate an Additional Symmetric Key (ask) for SipHash
SipHash uses two 8-byte keys (big endian) and 8 byte IV for first data.

// "ask" is 3 bytes, US-ASCII, no null termination
ask_master = HMAC-SHA256(temp_key, "ask" || byte(0x01))
// sip_master = HKDF(ask_master, h || "siphash")
// "siphash" is 7 bytes, US-ASCII, no null termination
// overwrite previous temp_key in memory
// h is from KDF for message 3 part 2
temp_key = HMAC-SHA256(ask_master, h || "siphash")
// overwrite ask_master in memory, no longer needed
ask_master = (all zeros)
sip_master = HMAC-SHA256(temp_key, byte(0x01))

Alice to Bob SipHash k1, k2, IV:
// sipkeys_ab, sipkeys_ba = HKDF(sip_master, zerolen)
// overwrite previous temp_key in memory
temp_key = HMAC-SHA256(sip_master, zerolen)
// overwrite sip_master in memory, no longer needed
sip_master = (all zeros)

sipkeys_ab = HMAC-SHA256(temp_key, byte(0x01)).
sipk1_ab = sipkeys_ab[0:7], little endian
sipk2_ab = sipkeys_ab[8:15], little endian
sipiv_ab = sipkeys_ab[16:23]

Bob to Alice SipHash k1, k2, IV:

sipkeys_ba = HMAC-SHA256(temp_key, sipkeys_ab || byte(0x02)).
sipk1_ba = sipkeys_ba[0:7], little endian
sipk2_ba = sipkeys_ba[8:15], little endian
sipiv_ba = sipkeys_ba[16:23]

// overwrite the temp_key in memory, no longer needed
temp_key = (all zeros)

4) Data Phase

حمولة Noise: كما هو محدد أدناه، بما في ذلك الحشو العشوائي حمولة غير Noise: لا يوجد

بدءاً من الجزء الثاني من الرسالة 3، تكون جميع الرسائل داخل “إطار” ChaChaPoly مُصدّق ومُشفّر مع طول مبهم مكوّن من بايتين في المقدمة. جميع الحشو موجود داخل الإطار. داخل الإطار يوجد تنسيق قياسي يحتوي على صفر أو أكثر من “الكتل”. كل كتلة لها نوع مكوّن من بايت واحد وطول مكوّن من بايتين. تشمل الأنواع التاريخ/الوقت، ورسالة I2NP، والخيارات، والإنهاء، والحشو.

ملاحظة: يمكن لـ Bob، ولكن ليس مطلوباً منه، إرسال RouterInfo الخاص به إلى Alice كرسالته الأولى إلى Alice في مرحلة البيانات.

(خصائص أمان الحمولة)

XK(s, rs):           Authentication   Confidentiality
  <-                        2                5
  ->                        2                5

  Authentication: 2.
  Sender authentication resistant to key-compromise impersonation (KCI).
  The sender authentication is based on an ephemeral-static DH ("es" or "se")
  between the sender's static key pair and the recipient's ephemeral key pair.
  Assuming the corresponding private keys are secure, this authentication cannot be forged.

  Confidentiality: 5.
  Encryption to a known recipient, strong forward secrecy.
  This payload is encrypted based on an ephemeral-ephemeral DH as well as
  an ephemeral-static DH with the recipient's static key pair.
  Assuming the ephemeral private keys are secure, and the recipient is not being actively impersonated
  by an attacker that has stolen its static private key, this payload cannot be decrypted.

٢) فحص الحزم العميق دون اتصال (Offline DPI)

لضمان الكفاءة وتقليل تحديد حقل الطول، يجب على التطبيقات التأكد من أن المُرسِل يُخزن مؤقتاً ثم يُفرغ المحتويات الكاملة لرسائل البيانات دفعة واحدة، بما في ذلك حقل الطول وإطار AEAD. هذا يزيد من احتمالية أن تكون البيانات موجودة في حزمة TCP واحدة (ما لم يتم تقسيمها من قبل نظام التشغيل أو middleboxes)، وأن يتم استقبالها كاملة من قبل الطرف الآخر. هذا أيضاً لضمان الكفاءة وفعالية الحشو العشوائي.
قد يختار الموجه إنهاء الجلسة عند حدوث خطأ AEAD، أو قد يستمر في محاولة الاتصالات. في حالة المتابعة، يجب على الموجه الإنهاء بعد تكرار الأخطاء.

SipHash obfuscated length

المرجع: SipHash

بمجرد أن يكمل كلا الطرفين المصافحة، يقومان بنقل الحمولات التي يتم تشفيرها والتحقق من صحتها في “إطارات” ChaChaPoly.

كل إطار يسبقه طول من بايتين، big endian. هذا الطول يحدد عدد بايتات الإطار المشفرة التي تليه، بما في ذلك الـ MAC. لتجنب إرسال حقول طول قابلة للتعرف عليها في التدفق، يتم إخفاء طول الإطار عن طريق عملية XOR مع قناع مشتق من SipHash، كما تم تهيئته من KDF لمرحلة البيانات. لاحظ أن الاتجاهين لديهما مفاتيح وIVs فريدة من SipHash من الـ KDF.

    sipk1, sipk2 = The SipHash keys from the KDF.  (two 8-byte long integers)
    IV[0] = sipiv = The SipHash IV from the KDF. (8 bytes)
    length is big endian.
    For each frame:
      IV[n] = SipHash-2-4(sipk1, sipk2, IV[n-1])
      Mask[n] = First 2 bytes of IV[n]
      obfuscatedLength = length ^ Mask[n]

    The first length output will be XORed with with IV[1].

يمتلك المستقبِل مفاتيح SipHash و IV المطابقة تماماً. يتم فك تشفير الطول عن طريق اشتقاق القناع المستخدم لإخفاء الطول وتطبيق عملية XOR على الخلاصة المقتطعة للحصول على طول الإطار. طول الإطار هو الطول الإجمالي للإطار المشفر بما في ذلك MAC.

العمل المستقبلي

إذا كنت تستخدم دالة مكتبة SipHash التي ترجع عددًا صحيحًا طويلاً غير موقع، استخدم البايتين الأقل أهمية كـ Mask. حول العدد الصحيح الطويل إلى IV التالي بتنسيق little endian.

التشفير المُصادق عليه

+----+----+----+----+----+----+----+----+
|obf size |                             |
+----+----+                             +
|                                       |
+   ChaChaPoly frame                    +
|   Encrypted and authenticated         |
+   key is k_ab for Alice to Bob        +
|   key is k_ba for Bob to Alice        |
+   as defined in KDF for data phase    +
|   n starts at 0 and increments        |
+   for each frame in that direction    +
|   no associated data                  |
+   16 bytes minimum                    +
|                                       |
~               .   .   .               ~
|                                       |
+----+----+----+----+----+----+----+----+

obf size :: 2 bytes length obfuscated with SipHash
            when de-obfuscated: 16 - 65535

Minimum size including length field is 18 bytes.
Maximum size including length field is 65537 bytes.
Obfuscated length is 2 bytes.
Maximum ChaChaPoly frame is 65535 bytes.

ChaCha20/Poly1305

يحتوي الإطار المشفر على صفر أو أكثر من الكتل. تحتوي كل كتلة على معرف من بايت واحد، وطول من بايتين، وصفر أو أكثر من بايتات البيانات.

للتوسعة، يجب على المستقبلات تجاهل الكتل ذات المعرفات غير المعروفة، والتعامل معها كحشو.

البيانات المشفرة 65535 بايت كحد أقصى، بما في ذلك رأس المصادقة 16 بايت، لذا الحد الأقصى للبيانات غير المشفرة هو 65519 بايت.

(علامة المصادقة Poly1305 غير معروضة):

+----+----+----+----+----+----+----+----+
|blk |  size   |       data             |
+----+----+----+                        +
|                                       |
~               .   .   .               ~
|                                       |
+----+----+----+----+----+----+----+----+
|blk |  size   |       data             |
+----+----+----+                        +
|                                       |
~               .   .   .               ~
|                                       |
+----+----+----+----+----+----+----+----+
~               .   .   .               ~

blk :: 1 byte
       0 for datetime
       1 for options
       2 for RouterInfo
       3 for I2NP message
       4 for termination
       224-253 reserved for experimental features
       254 for padding
       255 reserved for future extension
size :: 2 bytes, big endian, size of data to follow, 0 - 65516
data :: the data

Maximum ChaChaPoly frame is 65535 bytes.
Poly1305 tag is 16 bytes
Maximum total block size is 65519 bytes
Maximum single block size is 65519 bytes
Block type is 1 byte
Block length is 2 bytes
Maximum single block data size is 65516 bytes.

Block Ordering Rules

في رسالة المصافحة 3 الجزء 2، يجب أن يكون الترتيب: RouterInfo، متبوعة بـ Options إذا كانت موجودة، متبوعة بـ Padding إذا كانت موجودة. لا يُسمح بأي كتل أخرى.

في مرحلة البيانات، الترتيب غير محدد، باستثناء المتطلبات التالية: الحشو، إذا كان موجوداً، يجب أن يكون الكتلة الأخيرة. الإنهاء، إذا كان موجوداً، يجب أن يكون الكتلة الأخيرة باستثناء الحشو.

قد تحتوي الإطار الواحد على عدة كتل I2NP. لا يُسمح بوجود عدة كتل Padding في إطار واحد. أنواع الكتل الأخرى على الأرجح لن تحتوي على عدة كتل في إطار واحد، ولكن هذا غير محظور.

معالجة أخطاء AEAD

حالة خاصة لمزامنة الوقت:

+----+----+----+----+----+----+----+
| 0  |    4    |     timestamp     |
+----+----+----+----+----+----+----+

blk :: 0
size :: 2 bytes, big endian, value = 4
timestamp :: Unix timestamp, unsigned seconds.
             Wraps around in 2106

دالة اشتقاق المفاتيح (KDF) (لرسالة المصافحة 1)

تمرير الخيارات المحدثة. تشمل الخيارات: الحد الأدنى والأقصى للحشو.

كتلة الخيارات ستكون ذات طول متغير.

+----+----+----+----+----+----+----+----+
| 1  |  size   |tmin|tmax|rmin|rmax|tdmy|
+----+----+----+----+----+----+----+----+
|tdmy|  rdmy   |  tdelay |  rdelay |    |
~----+----+----+----+----+----+----+    ~
|              more_options             |
~               .   .   .               ~
|                                       |
+----+----+----+----+----+----+----+----+

blk :: 1
size :: 2 bytes, big endian, size of options to follow, 12 bytes minimum

tmin, tmax, rmin, rmax :: requested padding limits
    tmin and rmin are for desired resistance to traffic analysis.
    tmax and rmax are for bandwidth limits.
    tmin and tmax are the transmit limits for the router sending this options block.
    rmin and rmax are the receive limits for the router sending this options block.
    Each is a 4.4 fixed-point float representing 0 to 15.9375
    (or think of it as an unsigned 8-bit integer divided by 16.0).
    This is the ratio of padding to data. Examples:
    Value of 0x00 means no padding
    Value of 0x01 means add 6 percent padding
    Value of 0x10 means add 100 percent padding
    Value of 0x80 means add 800 percent (8x) padding
    Alice and Bob will negotiate the minimum and maximum in each direction.
    These are guidelines, there is no enforcement.
    Sender should honor receiver's maximum.
    Sender may or may not honor receiver's minimum, within bandwidth constraints.

tdmy: Max dummy traffic willing to send, 2 bytes big endian, bytes/sec average
rdmy: Requested dummy traffic, 2 bytes big endian, bytes/sec average
tdelay: Max intra-message delay willing to insert, 2 bytes big endian, msec average
rdelay: Requested intra-message delay, 2 bytes big endian, msec average

Padding distribution specified as additional parameters?
Random delay specified as additional parameters?

more_options :: Format TBD

1) SessionRequest

تنسيق الخيارات قيد التحديد.
التفاوض على الخيارات قيد التحديد.

RouterInfo

مرر RouterInfo الخاص بأليس إلى بوب. يُستخدم في الجزء الثاني من رسالة المصافحة 3. مرر RouterInfo الخاص بأليس إلى بوب، أو RouterInfo الخاص بوب إلى أليس. يُستخدم اختيارياً في مرحلة البيانات.

+----+----+----+----+----+----+----+----+
| 2  |  size   |flg |    RouterInfo     |
+----+----+----+----+                   +
| (Alice RI in handshake msg 3 part 2)  |
~ (Alice, Bob, or third-party           ~
|  RI in data phase)                    |
~               .   .   .               ~
|                                       |
+----+----+----+----+----+----+----+----+

blk :: 2
size :: 2 bytes, big endian, size of flag + router info to follow
flg :: 1 byte flags
       bit order: 76543210
       bit 0: 0 for local store, 1 for flood request
       bits 7-1: Unused, set to 0 for future compatibility
routerinfo :: Alice's or Bob's RouterInfo

Notes

عند الاستخدام في مرحلة البيانات، يجب على المستقبل (Alice أو Bob) التحقق من أن هذا هو نفس Router Hash المرسل أصلاً (بالنسبة لـ Alice) أو المرسل إليه (بالنسبة لـ Bob). ثم، تعامل معه كرسالة I2NP DatabaseStore محلية. تحقق من التوقيع، تحقق من الطابع الزمني الأحدث، واحفظه في netDb المحلي. إذا كان flag bit 0 هو 1، والطرف المستقبل هو floodfill، تعامل معه كرسالة DatabaseStore Message مع reply token غير صفري، وانشره إلى أقرب floodfills.
معلومات الموجه (Router Info) غير مضغوطة بـ gzip (على عكس رسالة DatabaseStore Message، حيث تكون مضغوطة)
يجب عدم طلب الـ Flooding إلا إذا كان هناك RouterAddresses منشورة في الـ RouterInfo. يجب على الـ router المستقبل عدم عمل flood للـ RouterInfo إلا إذا كان يحتوي على RouterAddresses منشورة.
يجب على المطورين التأكد من أنه عند قراءة كتلة، البيانات المشوهة أو الضارة لن تتسبب في تجاوز القراءات إلى الكتلة التالية.
هذا البروتوكول لا يوفر إقرار استلام بأن RouterInfo تم استلامها أو تخزينها أو إرسالها عبر floodfill (سواء في مرحلة المصافحة أو مرحلة البيانات). إذا كان الإقرار مطلوباً، وكان المستقبِل floodfill، فيجب على المرسِل بدلاً من ذلك إرسال I2NP DatabaseStoreMessage قياسية مع reply token.

Issues

يمكن أيضاً استخدامها في مرحلة البيانات، بدلاً من I2NP DatabaseStoreMessage. على سبيل المثال، يمكن لبوب استخدامها لبدء مرحلة البيانات.
هل يُسمح لهذا أن يحتوي على RI لأجهزة router أخرى غير المنشئ، كبديل عام لـ DatabaseStoreMessages، على سبيل المثال للفيضان بواسطة floodfills؟

دالة اشتقاق المفاتيح (KDF) (لرسالة المصافحة 2 والجزء 1 من الرسالة 3)

رسالة I2NP واحدة مع رأس معدل. قد لا يتم تجزئة رسائل I2NP عبر الكتل أو عبر إطارات ChaChaPoly.

يستخدم هذا أول 9 بايت من رأس I2NP القياسي لـ NTCP، ويزيل آخر 7 بايت من الرأس، كما يلي: اقتطاع انتهاء الصلاحية من 8 إلى 4 بايت، إزالة الطول ذي البايتين (استخدم حجم الكتلة - 9)، وإزالة مجموع التحقق SHA256 ذي البايت الواحد.

+----+----+----+----+----+----+----+----+
| 3  |  size   |type|    msg id         |
+----+----+----+----+----+----+----+----+
|   short exp       |     message       |
+----+----+----+----+                   +
|                                       |
~               .   .   .               ~
|                                       |
+----+----+----+----+----+----+----+----+

blk :: 3
size :: 2 bytes, big endian, size of type + msg id + exp + message to follow
        I2NP message body size is (size - 9).
type :: 1 byte, I2NP msg type, see I2NP spec
msg id :: 4 bytes, big endian, I2NP message ID
short exp :: 4 bytes, big endian, I2NP message expiration, Unix timestamp, unsigned seconds.
             Wraps around in 2106
message :: I2NP message body

Notes

يجب على المطورين التأكد من أنه عند قراءة كتلة، فإن البيانات المشوهة أو الضارة لن تتسبب في تجاوز القراءة إلى الكتلة التالية.

2) SessionCreated

ينصح Noise برسالة إنهاء صريحة. NTCP الأصلي لا يحتوي على واحدة. قم بإسقاط الاتصال. يجب أن تكون هذه آخر كتلة غير مبطنة في الإطار.

+----+----+----+----+----+----+----+----+
| 4  |  size   |    valid data frames   |
+----+----+----+----+----+----+----+----+
    received   | rsn|     addl data     |
+----+----+----+----+                   +
~               .   .   .               ~
+----+----+----+----+----+----+----+----+

blk :: 4
size :: 2 bytes, big endian, value = 9 or more
valid data frames received :: The number of valid AEAD data phase frames received
                              (current receive nonce value)
                              0 if error occurs in handshake phase
                              8 bytes, big endian
rsn :: reason, 1 byte:
       0: normal close or unspecified
       1: termination received
       2: idle timeout
       3: router shutdown
       4: data phase AEAD failure
       5: incompatible options
       6: incompatible signature type
       7: clock skew
       8: padding violation
       9: AEAD framing error
       10: payload format error
       11: message 1 error
       12: message 2 error
       13: message 3 error
       14: intra-frame read timeout
       15: RI signature verification fail
       16: s parameter missing, invalid, or mismatched in RouterInfo
       17: banned
addl data :: optional, 0 or more bytes, for future expansion, debugging,
             or reason text.
             Format unspecified and may vary based on reason code.

Notes

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

Padding

هذا للحشو داخل إطارات AEAD. الحشو للرسائل 1 و 2 يكون خارج إطارات AEAD. جميع عمليات الحشو للرسالة 3 ومرحلة البيانات تكون داخل إطارات AEAD.

يجب أن تلتزم الحشوة داخل AEAD تقريبياً بالمعاملات المتفاوض عليها. أرسل Bob معاملات tx/rx الدنيا/العليا المطلوبة في الرسالة 2. أرسلت Alice معاملات tx/rx الدنيا/العليا المطلوبة في الرسالة 3. قد يتم إرسال خيارات محدثة أثناء مرحلة البيانات. انظر معلومات كتلة الخيارات أعلاه.

إذا كان موجوداً، يجب أن يكون هذا آخر block في الإطار.

+----+----+----+----+----+----+----+----+
|254 |  size   |      padding           |
+----+----+----+                        +
|                                       |
~               .   .   .               ~
|                                       |
+----+----+----+----+----+----+----+----+

blk :: 254
size :: 2 bytes, big endian, size of padding to follow
padding :: random data

Notes

استراتيجيات الحشو (Padding) قيد التحديد.
الحد الأدنى للحشو قيد التحديد.
الإطارات التي تحتوي على حشو فقط مسموحة.
إعدادات الحشو الافتراضية قيد التحديد.
انظر كتلة الخيارات لتفاوض معاملات الحشو
انظر كتلة الخيارات لمعاملات الحد الأدنى/الأقصى للحشو
Noise يحدد الرسائل بـ 64KB. إذا كان مطلوبًا حشو أكثر، أرسل إطارات متعددة.
استجابة الموجه عند انتهاك الحشو المتفاوض عليه تعتمد على التنفيذ.

Other block types

يجب على التنفيذات تجاهل أنواع الكتل غير المعروفة للتوافق المستقبلي، باستثناء الرسالة 3 الجزء 2، حيث لا يُسمح بالكتل غير المعروفة.

Future work

يجب تحديد طول الحشو (padding) إما على أساس كل رسالة على حدة وتقديرات توزيع الطول، أو يجب إضافة تأخيرات عشوائية. هذه التدابير المضادة يجب تضمينها لمقاومة DPI، حيث أن أحجام الرسائل ستكشف بطريقة أخرى أن حركة I2P يتم حملها بواسطة بروتوكول النقل. مخطط الحشو الدقيق هو مجال للعمل المستقبلي، الملحق A يوفر معلومات أكثر حول هذا الموضوع.

5) Termination

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

عند أي إنهاء طبيعي أو غير طبيعي، يجب على الـ routers أن تقوم بمحو أي بيانات مؤقتة في الذاكرة، بما في ذلك مفاتيح handshake المؤقتة، ومفاتيح التشفير المتماثل، والمعلومات ذات الصلة.

Published Router Info

التشفير لجزء 1 من رسالة المصافحة 3، باستخدام KDF الرسالة 2)

عنوان الراوتر المنشور (RouterAddress) (جزء من معلومات الراوتر RouterInfo) سيحتوي على معرف بروتوكول إما “NTCP” أو “NTCP2”.

يجب أن يحتوي RouterAddress على خيارات “host” و “port”، كما هو الحال في بروتوكول NTCP الحالي.

يجب أن يحتوي RouterAddress على ثلاث خيارات للإشارة إلى دعم NTCP2:

s=(Base64 key) المفتاح العام الثابت الحالي لـ Noise (s) لهذا RouterAddress. مُرمز بـ Base 64 باستخدام أبجدية I2P Base 64 القياسية. 32 بايت في النظام الثنائي، 44 بايت مُرمز بـ Base 64، مفتاح عام X25519 بترتيب البايت الأصغر أولاً.
i=(Base64 IV) قيمة IV الحالية لتشفير قيمة X في الرسالة 1 لهذا RouterAddress. مُرمزة بـ Base 64 باستخدام أبجدية I2P القياسية لـ Base 64. 16 بايت في النظام الثنائي، 24 بايت مُرمزة بـ Base 64، big-endian.
v=2 الإصدار الحالي (2). عند النشر كـ “NTCP”، يكون الدعم الإضافي للإصدار 1 مُضمناً. الدعم للإصدارات المستقبلية سيكون بقيم مفصولة بفواصل، مثل v=2,3 يجب على التنفيذ التحقق من التوافق، بما في ذلك الإصدارات المتعددة إذا كانت الفاصلة موجودة. الإصدارات المفصولة بفواصل يجب أن تكون بترتيب رقمي.

يجب على Alice التحقق من وجود جميع الخيارات الثلاثة وصحتها قبل الاتصال باستخدام بروتوكول NTCP2.

عندما يتم نشره كـ “NTCP” مع خيارات “s” و “i” و “v”، يجب على الـ router قبول الاتصالات الواردة على ذلك المضيف والمنفذ لكل من بروتوكولي NTCP و NTCP2، واكتشاف إصدار البروتوكول تلقائياً.

عندما يتم نشرها كـ “NTCP2” مع خيارات “s” و “i” و “v”، يقبل الـ router الاتصالات الواردة على ذلك المضيف والمنفذ لبروتوكول NTCP2 فقط.

إذا كان router يدعم كلاً من اتصالات NTCP1 و NTCP2 ولكن لا يطبق الكشف التلقائي للإصدار للاتصالات الواردة، فيجب عليه الإعلان عن كل من عناوين “NTCP” و “NTCP2”، وتضمين خيارات NTCP2 في عنوان “NTCP2” فقط. يجب على الـ router تعيين قيمة تكلفة أقل (أولوية أعلى) في عنوان “NTCP2” من عنوان “NTCP”، بحيث يُفضل NTCP2.

إذا تم نشر عناوين NTCP2 RouterAddresses متعددة (إما كـ “NTCP” أو “NTCP2”) في نفس RouterInfo (لعناوين IP أو منافذ إضافية)، يجب أن تحتوي جميع العناوين التي تحدد نفس المنفذ على خيارات وقيم NTCP2 متطابقة. على وجه الخصوص، يجب أن تحتوي جميعها على نفس المفتاح الثابت و iv.

وظيفة اشتقاق المفتاح (KDF) (لرسالة المصافحة 3 الجزء 2)

إذا لم تنشر Alice عنوان NTCP2 الخاص بها (كـ “NTCP” أو “NTCP2”) للاتصالات الواردة، يجب عليها نشر عنوان router “NTCP2” يحتوي فقط على مفتاحها الثابت وإصدار NTCP2، حتى يتمكن Bob من التحقق من صحة المفتاح بعد استلام RouterInfo الخاص بـ Alice في الرسالة 3 الجزء 2.

s=(مفتاح Base64) كما هو محدد أعلاه للعناوين المنشورة.
v=2 كما هو محدد أعلاه للعناوين المنشورة.

هذا عنوان الموجه لن يحتوي على خيارات “i” أو “host” أو “port”، حيث أن هذه غير مطلوبة لاتصالات NTCP2 الصادرة. التكلفة المنشورة لهذا العنوان لا تهم بشكل صارم، حيث أنه للاتصالات الواردة فقط؛ ومع ذلك، قد يكون مفيداً للموجهات الأخرى إذا تم تعيين التكلفة أعلى (أولوية أقل) من العناوين الأخرى. القيمة المقترحة هي 14.

قد تقوم Alice أيضاً بإضافة الخيارين “s” و “v” ببساطة إلى عنوان “NTCP” منشور موجود.

3) SessionConfirmed

بسبب التخزين المؤقت لـ RouterInfos، يجب على الـ routers عدم تدوير المفتاح العام الثابت أو الـ IV أثناء تشغيل الـ router، سواء كان في عنوان منشور أم لا. يجب على الـ routers تخزين هذا المفتاح والـ IV بشكل دائم لإعادة الاستخدام بعد إعادة التشغيل الفوري، بحيث تستمر الاتصالات الواردة في العمل، ولا يتم كشف أوقات إعادة التشغيل. يجب على الـ routers تخزين، أو تحديد بطريقة أخرى، وقت الإغلاق الأخير بشكل دائم، بحيث يمكن حساب وقت التوقف السابق عند بدء التشغيل.

مع مراعاة المخاوف المتعلقة بكشف أوقات إعادة التشغيل، قد تقوم routers بتدوير هذا المفتاح أو IV عند بدء التشغيل إذا كان الـ router متوقفاً سابقاً لبعض الوقت (ساعتان على الأقل).

إذا كان الـ router يحتوي على أي RouterAddresses منشورة لـ NTCP2 (كـ NTCP أو NTCP2)، فيجب أن يكون الحد الأدنى لوقت التوقف قبل التدوير أطول بكثير، على سبيل المثال شهر واحد، ما لم يتغير عنوان IP المحلي أو يقوم الـ router بـ “rekeys”.

إذا كان لدى الموجه أي RouterAddresses منشورة لـ SSU، ولكن ليس NTCP2 (كـ NTCP أو NTCP2)، فيجب أن يكون الحد الأدنى لوقت التوقف قبل التدوير أطول، على سبيل المثال يوم واحد، ما لم يتغير عنوان IP المحلي أو يقوم الموجه بـ “rekeys”. هذا ينطبق حتى لو كان عنوان SSU المنشور يحتوي على introducers.

إذا لم يكن لدى الـ router أي RouterAddresses منشورة (NTCP أو NTCP2 أو SSU)، فقد يكون الحد الأدنى لوقت التوقف قبل التدوير قصيراً يصل إلى ساعتين، حتى لو تغير عنوان IP، ما لم يقم الـ router بإعادة المفاتيح “rekeys”.

إذا قام الـ router بإجراء “rekeys” إلى Router Hash مختلف، فيجب عليه إنشاء noise key وIV جديدين أيضاً.

يجب على التطبيقات أن تكون على دراية بأن تغيير المفتاح العام الثابت أو IV سيمنع اتصالات NTCP2 الواردة من routers التي قامت بتخزين RouterInfo أقدم مؤقتاً. يجب أن يأخذ نشر RouterInfo، واختيار أقران tunnel (بما في ذلك كل من OBGW وأقرب hop للـ IB)، واختيار zero-hop tunnel، واختيار النقل، واستراتيجيات التطبيق الأخرى هذا الأمر في الاعتبار.

دوران IV يخضع لنفس القواعد المطابقة لدوران المفاتيح، باستثناء أن IVs غير موجودة إلا في RouterAddresses المنشورة، لذلك لا يوجد IV للموجهات المخفية أو المحمية بجدار الحماية. إذا تغير أي شيء (الإصدار، المفتاح، الخيارات؟) فمن المستحسن أن يتغير IV أيضاً.

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

Identity Hiding

إنكار المسؤولية ليس هدفاً. راجع النظرة العامة أعلاه.

يتم تعيين خصائص لكل نمط تصف السرية المقدمة للمفتاح العام الثابت للمبادر، وللمفتاح العام الثابت للمجيب. الافتراضات الأساسية هي أن المفاتيح الخاصة المؤقتة آمنة، وأن الأطراف تلغي المصافحة إذا تلقت مفتاحاً عاماً ثابتاً من الطرف الآخر لا تثق به.

يتناول هذا القسم فقط تسريب الهوية من خلال حقول المفاتيح العامة الثابتة في عمليات التصافح. بالطبع، قد تتعرض هويات المشاركين في Noise من خلال وسائل أخرى، بما في ذلك حقول البيانات، أو تحليل حركة المرور، أو البيانات الوصفية مثل عناوين IP.

Alice: (8) مُشفّر مع السرية الأمامية لطرف مُصادق عليه.

Bob: (3) لا يتم إرساله، ولكن يمكن للمهاجم السلبي فحص المرشحين للمفتاح الخاص للمستجيب وتحديد ما إذا كان المرشح صحيحاً.

بوب ينشر مفتاحه العام الثابت في netDb. أليس قد تفعل أو قد لا تفعل؟

Issues

إذا قام Bob بتغيير مفتاحه الثابت، هل يمكن الرجوع إلى نمط “XX”؟

إطار عمل بروتوكول Noise

عند النشر كـ “NTCP”، يجب على الـ router أن يكتشف تلقائياً إصدار البروتوكول للاتصالات الواردة.

هذا الاكتشاف يعتمد على التنفيذ، ولكن إليك بعض التوجيهات العامة.

لاكتشاف إصدار اتصال NTCP الوارد، يقوم Bob بما يلي:

انتظر ما لا يقل عن 64 بايت (الحد الأدنى لحجم رسالة NTCP2 الأولى)
إذا كانت البيانات المستقبلة الأولية 288 بايت أو أكثر، فإن الاتصال الوارد هو الإصدار 1.
إذا كان أقل من 288 بايت، إما
انتظر لفترة قصيرة للحصول على المزيد من البيانات (استراتيجية جيدة قبل اعتماد NTCP2 على نطاق واسع) إذا تم استلام 288 على الأقل إجمالاً، فهو NTCP 1.

جرب المراحل الأولى من فك التشفير كإصدار 2، إذا فشلت، انتظر وقتاً قصيراً للحصول على المزيد من البيانات (استراتيجية جيدة بعد اعتماد NTCP2 على نطاق واسع)

- Decrypt the first 32 bytes (the X key)
  of the SessionRequest packet using AES-256 with key RH_B.

- Verify a valid point on the curve.
  If it fails, wait a short time for more data for NTCP 1

- Verify the AEAD frame.
  If it fails, wait a short time for more data for NTCP 1

لاحظ أنه قد يتم التوصية بتغييرات أو استراتيجيات إضافية إذا اكتشفنا هجمات تجزئة TCP نشطة على NTCP 1.

لتسهيل الكشف السريع عن الإصدار والمصافحة، يجب على التطبيقات التأكد من أن Alice تقوم بتخزين ثم إرسال المحتويات الكاملة للرسالة الأولى دفعة واحدة، بما في ذلك الحشو. هذا يزيد من احتمالية أن تكون البيانات موجودة في حزمة TCP واحدة (ما لم يتم تقسيمها من قبل نظام التشغيل أو الصناديق الوسيطة)، ويتم استقبالها كاملة من قبل Bob. هذا أيضاً من أجل الكفاءة ولضمان فعالية الحشو العشوائي. هذا ينطبق على كل من مصافحات NTCP و NTCP2.

إضافات إلى الإطار العام

إذا كان كل من Alice و Bob يدعمان NTCP2، فيجب على Alice الاتصال باستخدام NTCP2.
إذا فشلت Alice في الاتصال بـ Bob باستخدام NTCP2 لأي سبب، يفشل الاتصال. قد لا تعيد Alice المحاولة باستخدام NTCP 1.
الرجوع إلى نمط XX إذا قام Bob بتغيير مفاتيحه؟ هذا سيتطلب بايت نوع مُضاف في المقدمة؟
“التقدم إلى الأمام” إلى نمط KK إذا أعادت Alice الاتصال، بافتراض أن Bob لا يزال لديه مفتاحها الثابت؟ هذا لا يوفر أي رحلات ذهاب وإياب ويستخدم 4 جولات DH مقارنة بـ 3 لـ XK. ربما لا.

  KK(s, rs):
    -> s
    <- s
    ...
    -> e, es, ss
    <- e, ee, se

بدائيات التشفير الجديدة لـ I2P

يناقش هذا القسم هجوماً على مخططات الحشو النموذجية يسمح للمهاجمين باكتشاف توزيع الاحتمالات لطول الرسائل غير المحشوة، من خلال مراقبة طول الرسائل المحشوة فقط. دع N يكون متغيراً عشوائياً يصف عدد البايتات غير المحشوة، و P بالمثل لعدد بايتات الحشو. يكون إجمالي حجم الرسالة آنذاك N + P.

افترض أنه لحجم غير مُبطن n، يتم إضافة على الأقل P_min(n) >= 0 وعلى الأكثر P_max(n) >= P_min(n) بايت من البطانة في مخطط البطانة. المخطط الواضح يستخدم بطانة بطول P مُختار عشوائياً بشكل موحد:

Pr[P = p | N = n] = 1 / (P_max(n) - P_min(n)) if P_min(n) <= p <= P_max(n),
                    0                         otherwise.

مخطط padding ساذج سيضمن ببساطة أن حجم الرسالة المحشوة لا يتجاوز N_max:

P_max(n) = N_max - n, n <= N_max
P_min(n) = 0.

ومع ذلك، فإن هذا يسرب معلومات حول الطول غير المحشو.

يمكن للمهاجم بسهولة تقدير Pr[x <= N + P <= y]، على سبيل المثال عن طريق استخدام الرسم البياني التكراري.

من هذا، يمكنه أيضاً محاولة تقدير Pr[n_1 <= N <= n_2]، في الواقع:

Pr[N + P = m] = Σ_n Pr[N = n] Pr[P = m - n | N = n].

في المخطط البدائي،

Pr[N + P = m] = Σ_{n <= m} Pr[N = n] / (N_max - n).

من الواضح جداً، كما كان الأمر قبل إجراء الحساب أعلاه، أن هذا يسرب معلومات حول Pr[N = n]: إذا كان طول الحزم دائماً تقريباً أكثر من m، فإن N + P <= m لن يُلاحظ تقريباً أبداً. هذه ليست القضية الأكبر رغم ذلك، على الرغم من أن القدرة على مراقبة الحد الأدنى لطول الرسالة يمكن اعتبارها مشكلة بحد ذاتها.

المسألة الأكبر هي أنه من الممكن تحديد Pr[N = n] بدقة:

Pr[N + P = m] - Pr[N + P = m-1] = Pr[N = m] / (N_max - m),

أي أن

Pr[N = n] = (N_max - n)(Pr[N + P = n] - Pr[N + P = n - 1])

لتمييز NTCP2، إذن، يمكن للمهاجم استخدام أي مما يلي:

تقدير Pr[kB <= N <= (k + 1)B - 1] للأعداد الصحيحة الموجبة k. ستكون دائماً صفر لـ NTCP2.
تقدير Pr[N = kB] ومقارنته مع ملف تعريف I2P معياري.

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

في بعض الأشكال (مثل تقدير Pr[kB <= N <= (k + 1)B - 1]) يتطلب الهجوم عدة بايتات فقط من الذاكرة (عدد صحيح واحد يكفي) ويمكن القول أن مثل هذا الهجوم قد يكون مُدرجاً في العديد من أطر عمل DPI المتقدمة قليلاً ولكن المعيارية مع ذلك.

يقترح هذا الاقتراح استخدام إحدى التدابير المضادة التالية:

تطوير مخطط حشو بديل يأخذ في الاعتبار التوزيع (المقدر) للعدد N باستخدام توزيع طول حشو غير منتظم. مخطط الحشو الجيد سيتطلب على الأرجح الاحتفاظ بمخطط بياني لعدد الكتل لكل رسالة.
إضافة تأخيرات عشوائية بين أجزاء الرسائل (ذات الأحجام العشوائية).

الخيار الثاني مفضل بشكل عام أكثر، لأنه يمكن استخدامه في الوقت نفسه كإجراء مضاد ضد تحليل التدفق. ومع ذلك، قد تكون هذه التأخيرات خارج نطاق بروتوكول NTCP2، بحيث قد يُفضل الخيار الأول بدلاً من ذلك، والذي يعتبر أيضاً أسهل في التنفيذ.

تقدير النفقات العامة للمعالجة

مقاومة DPI القائمة على التوقيت (توقيت/تأخيرات الرسائل البينية يمكن أن تكون معتمدة على التنفيذ؛ التأخيرات داخل الرسائل يمكن إدخالها في أي نقطة، بما في ذلك قبل إرسال الحشو العشوائي، على سبيل المثال). التأخيرات الاصطناعية (ما يسميه obfs4 بـ IAT أو وقت الوصول البيني) مستقلة عن البروتوكول نفسه.

ملاحظة

نظرة عامة

الدافع

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

Non-Goals

Related Goals

Security Goals

Additional DPI Discussion

1) Online DPI

2) Offline DPI

Future work

Noise Protocol Framework

أهداف الأمان

New Cryptographic Primitives for I2P

Processing overhead estimate

Messages

Authenticated Encryption

الأهداف غير المطلوبة

Notes

الأهداف ذات الصلة

Key Derivation Function (KDF) (for handshake message 1)

مناقشة إضافية حول DPI

Notes

Key Derivation Function (KDF) (for handshake message 2 and message 3 part 1)

2) SessionCreated

Notes

Notes

Issues

Encryption for for handshake message 3 part 1, using message 2 KDF)

Key Derivation Function (KDF) (for handshake message 3 part 2)

3) SessionConfirmed

١) فحص الحزم العميق المباشر (Online DPI)

Key Derivation Function (KDF) (for data phase)

4) Data Phase

٢) فحص الحزم العميق دون اتصال (Offline DPI)

SipHash obfuscated length

العمل المستقبلي

التشفير المُصادق عليه

ChaCha20/Poly1305

Block Ordering Rules

معالجة أخطاء AEAD

دالة اشتقاق المفاتيح (KDF) (لرسالة المصافحة 1)

1) SessionRequest

RouterInfo

Notes

Issues

دالة اشتقاق المفاتيح (KDF) (لرسالة المصافحة 2 والجزء 1 من الرسالة 3)

Notes

2) SessionCreated

Notes

Padding

Notes

Other block types

Future work

5) Termination

Published Router Info

التشفير لجزء 1 من رسالة المصافحة 3، باستخدام KDF الرسالة 2)

وظيفة اشتقاق المفتاح (KDF) (لرسالة المصافحة 3 الجزء 2)

3) SessionConfirmed

Identity Hiding

Issues

إطار عمل بروتوكول Noise

إضافات إلى الإطار العام

بدائيات التشفير الجديدة لـ I2P

تقدير النفقات العامة للمعالجة

Community Poll