رسائل بناء الأنفاق الأصغر

Proposal 157
مغلق
Author zzz، أوائل
Created 2020-10-09
Last Updated 2021-07-31
Target Version 0.9.51

ملاحظة

تم تنفيذها اعتبارًا من الإصدار API 0.9.51. جاري نشرها واختبارها على الشبكة. عرضة للمراجعة الطفيفة. انظر I2NP وTunnel-Creation-ECIES للمواصفات النهائية.

نظرة عامة

الملخص

الحجم الحالي للسجلات المشفرة لطلب بناء النفق والسجلات في الرد هو 528 بايت. بالنسبة لرسائل بناء النفق المتغيرة والردود على بناء النفق، يكون الحجم الإجمالي 2113 بايت. يتم تقسيم هذه الرسالة إلى ثلاثة رسائل أنفاق لكل منها 1 كيلوبايت للمسار العكسي.

التغييرات على سجل بحجم 528 بايت لأجهزة التوجيه ECIES-X25519 محددة في Prop152 وTunnel-Creation-ECIES. بالنسبة لمزيج من أجهزة التوجيه ElGamal وECIES-X25519 في نفق، يجب أن يظل حجم السجل 528 بايت. ومع ذلك، إذا كانت جميع أجهزة التوجيه في نفق هي ECIES-X25519، فمن الممكن إنشاء سجل بناء أصغر، لأن تشفير ECIES-X25519 لديه عبء منخفض كثيرا مقارنة بـ ElGamal.

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

هذا الاقتراح يحدد سجلات طلبات وردود جديدة ورسائل بناء طلبات وردود جديدة.

يجب أن يكون مختلق النفق وجميع العقد في النفق المنشأ ECIES-X25519، ويجب أن يكون على الأقل الإصدار 0.9.51. لن يكون هذا الاقتراح مفيدًا حتى تتحول معظم أجهزة التوجيه في الشبكة إلى ECIES-X25519. من المتوقع أن يحدث ذلك بحلول نهاية عام 2021.

الأهداف

انظر Prop152 وProp156 للحصول على أهداف إضافية.

  • سجلات أصغر ورسائل
  • الحفاظ على مساحة كافية للخيارات المستقبلية، كما هو الحال في Prop152 وTunnel-Creation-ECIES
  • التناسب مع رسالة نفق واحدة للمسار العكسي
  • دعم العُقد ECIES فقط
  • الحفاظ على التحسينات التي تم تنفيذها في Prop152 وTunnel-Creation-ECIES
  • تحقيق أقصى قدر من التوافق مع الشبكة الحالية
  • إخفاء رسائل البناء الواردة من OBEP
  • إخفاء رسائل الردود على البناء الصادرة من IBGW
  • لا تتطلب “يوم العلم” لترقية الشبكة بأكملها
  • تنفيذ ممتاز لتقليل المخاطر
  • إعادة استخدام الخوارزميات التشفيرية الحالية

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

انظر Prop156 لأهداف إضافية غير مطلوبة.

  • لا يوجد متطلبات لإنشاء أنفاق مختلطة بين ElGamal/ECIES
  • تغييرات في تشفير الطبقات، لهذا راجع Prop153
  • ليس هناك تسريع لعمليات التشفير. يفترض أن ChaCha20 وAES متشابهتان، حتى مع AESNI، على الأقل بالنسبة للأحجام الصغيرة للبيانات المعنية.

التصميم

السجلات

انظر الملحق للحسابات.

سجلات الطلبات والردود المشفرة ستكون 218 بايت، مقارنة بـ 528 بايت حاليًا.

سجلات الطلبات النصية ستكون 154 بايت، مقارنة بـ 222 بايت لسجلات ElGamal، و464 بايت لسجلات ECIES كما هو محدد في Prop152 وTunnel-Creation-ECIES.

سجلات الردود النصية ستكون 202 بايت، مقارنة بـ 496 بايت لسجلات ElGamal، و512 بايت لسجلات ECIES كما هو محدد في Prop152 وTunnel-Creation-ECIES.

تشفير الردود سيكون ChaCha20 (ليس ChaCha20/Poly1305)، لذلك لا تحتاج السجلات النصية أن تكون مضاعفات لـ 16 بايت.

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

رسائل بناء الأنفاق

سيكون كلاهما “متغيرًا” مع حقل عدد السجلات بواحد بايت، كما هو الحال مع الرسائل المتغيرة الحالية.

ShortTunnelBuild: النوع 25

الطول النموذجي (مع 4 سجلات): 873 بايت

عند استخدامه لبناء الأنفاق الواردة، يوصى (لكن ليس مطلوبًا) بأن يتم تشفير هذه الرسالة بواسطة المنتشئ، الاستهداف للبوابة الواردة (تعليمات التوصيل ROUTER)، لإخفاء رسائل البناء الواردة من OBEP. يفك تشفير IBGW الرسالة، ويضع الرد في الفتحة الصحيحة، ويرسل ShortTunnelBuildMessage إلى الخطوة التالية.

طول السجل يتم تحديده بحيث يتناسب STBM المشفر بالثوم داخل رسالة نفق واحدة. انظر الملحق أدناه.

OutboundTunnelBuildReply: النوع 26

نحن نعرف رسالة OutboundTunnelBuildReply جديدة. يتم استخدامها لبناء الأنفاق الصادرة فقط. الهدف هو إخفاء رسائل البناء الواردة من IBGW. يجب أن يتم تشفيرها بالثوم بواسطة OBEP، الاستهداف للمنشئ (تعليمات التوصيل TUNNEL). يفك OBEP تشفير رسالة بناء النفق، ينشئ OutboundTunnelBuildReply، ويضع الرد في الحقل النصي. تذهب السجلات الأخرى إلى الفتحات الأخرى. ثم يقوم بتشفير الرسالة إلى المنشئ بالمفاتيح المتماثلة المشتقة.

الملاحظات

بتشفير OTBRM وSTBM بالثوم، نتجنب أيضًا أي قضايا احتمالية مع التوافق في IBGW وOBEP للأنفاق المزدوجة.

تدفق الرسائل

STBM: رسالة بناء النفق القصير (النوع 25)
  OTBRM: رسالة رد بناء النفق الصادر (النوع 26)

  بناء صادر أ-ب-ج
  الرد عبر الوارد د-هـ-و


                  نفق جديد
           STBM      STBM      STBM
  منشئ ------> أ ------> ب ------> ج ---\
                                     OBEP   \
                                            | ملفوفة بالثوم
                                            | OTBRM
                                            | (توصيل TUNNEL)
                                            | من OBEP إلى
                                            | المنشئ
                نفق موجود                     /
  منشئ <-------و---------هـ-------- د <--/
                                     IBGW



  بناء وارد د-هـ-و
  مرسل عبر المخرج الحالي أ-ب-ج


                نفق موجود
  منشئ ------> أ ------> ب ------> ج ---\
                                    OBEP    \
                                            | ملفوفة بالثوم (اختياري)
                                            | STBM
                                            | (توصيل ROUTER)
                                            | من المنشئ
                  نفق جديد                  | إلى IBGW
            STBM      STBM      STBM        /
  منشئ <------ و <------ هـ <------ د <--/
                                     IBGW

تشفير السجلات

تشفير سجل الطلبات والردود: كما هو محدد في Prop152 وTunnel-Creation-ECIES.

تشفير سجل الردود للفتح الأخرى: ChaCha20.

تشفير الطبقة

حاليا لا يوجد خطة لتغيير تشفير الطبقة للأنفاق البنية باستخدام هذا المواصفات؛ سيظل AES، كما هو مستخدم حاليا لكل الأنفاق.

تغيير تشفير الطبقة إلى ChaCha20 هو موضوع لأبحاث إضافية.

رسالة بيانات النفق الجديدة

حاليا لا توجد خطة لتغيير رسالة البيانات النفقية 1KB المستخدمة للأنفاق البنية باستخدام هذا المواصفات.

قد يكون من المفيد تقديم رسالة I2NP جديدة أكبر أو متغيرة الحجم، بالتزامن مع هذا الاقتراح، لل

استخدام عبر هذه الأنفاق. هذا يمكن أن يقلل من النفقات العامة للرسائل الكبيرة. وهذا موضوع لأبحاث إضافية.

المواصفات

سجل الطلب القصير

سجل الطلب القصير غير مشفر

هذا هو المواصفات المقترحة لسجل بناء النفق ECIES-X25519. ملخص التغييرات من Tunnel-Creation-ECIES:

  • تغيير الطول غير المشفر من 464 إلى 154 بايت
  • تغيير الطول المشفر من 528 إلى 218 بايت
  • إزالة مفاتيح الطبقات والردود والإفيدينات، سيتم إنشاؤها من split() وKDF

لا يحتوي سجل الطلب على أي مفاتيح ردود ChaCha. تشتق هذه المفاتيح من KDF. انظر أدناه.

جميع الحقول من اليسار لليمين.

حجم غير مشفر: 154 بايت.

bytes     0-3: المعرف النفق لتلقي الرسائل كما، غير صفر
  bytes     4-7: معرّف النفق التالي، غير صفر
  bytes    8-39: تجزئة هوية الموجه التالي
  byte       40: الأعلام
  bytes   41-42: أعلام أكثر، غير مستخدمة، ضبط على 0 للتوافق
  byte       43: نوع تشفير الطبقة
  bytes   44-47: وقت الطلب (بالدقائق منذ الحقبة، مقرب للأسفل)
  bytes   48-51: انتهاء الطلب (بالثواني منذ الإنشاء)
  bytes   52-55: معرّف الرسالة التالي
  bytes    56-x: خيارات بناء النفق (خرائط)
  bytes     x-x: بيانات أخرى تشترطها الأعلام أو الخيارات
  bytes   x-153: حشو عشوائي (انظر أدناه)

حقل الأعلام هو نفس التعريف في Tunnel-Creation ويحتوي على ما يلي::

ترتيب البتات: 76543210 (البت 7 هو MSB) البت 7: إذا تمت المجموعة، السماح للرسائل من أي شخص البت 6: إذا تمت المجموعة، السماح للرسائل لأي شخص، وإرسال الرد إلى القفزة التالية المحددة في رسالة رد بناء النفق البتات 5-0: غير معرّفة، يجب الضبط على 0 للتوافق مع الخيارات المستقبلية

البت 7 يشير إلى أن القفزة ستكون بوابة دخول (IBGW). البت 6 يشير إلى أن القفزة ستكون نقطة نهاية صادرة (OBEP). إذا لم يتم الضبط على أي منهما، ستكون القفزة مشاركة وسيطة. لا يمكن ضبط كلاهما في نفس الوقت.

نوع تشفير الطبقة: 0 لـ AES (كما في الأنفاق الحالية)؛ 1 للمستقبل (ChaCha؟)

انتهاء الطلب هو من أجل مدة النفق المتغيرة المستقبلية. حاليا، القيمة المدعومة الوحيدة هي 600 (10 دقائق).

المفتاح العام الزمني للمنشئ هو مفتاح ECIES، بالترتيب الكبير. يستخدم لعمليات KDF لمفاتيح وIVs الطبقة والرد لـ IBGW. هذا فقط مضمن في سجل النص العادي في رسالة بناء النفق الوارد. ضروري لأنه لا يوجد DH في هذه الطبقة لسجل البناء.

خيارات بناء النفق هو هيكل خرائط كما هو معرف في Common. هذا للاستخدام المستقبلي. لا توجد خيارات معرفة حاليا. إذا كان هيكل الخرائط فارغًا، فهذا هو بايتين 0x00 0x00. الحد الأقصى لحجم الخرائط (بما في ذلك حقل الطول) هو 98 بايت، والحد الأقصى لقيمة حقل طول الخرائط هو 96.

سجل الطلب القصير مشفراً

جميع الحقول من اليسار لليمين عدا المفتاح العام الزمني الذي هو بالترتيب الصغير.

حجم مشفر: 218 بايت

bytes    0-15: تجزئة هوية القفزة المُختصرة
  bytes   16-47: المرسل لمفتاح عام X25519 الزمني
  bytes  48-201: ChaCha20 مشفر ShortBuildRequestRecord
  bytes 202-217: Poly1305 MAC

سجل الردود القصيرة

سجل الردود القصيرة غير مشفر

هذا هو المواصفات المقترحة لبناء سجل الردود القصيرة للأنفاق ECIES-X25519. ملخص التغييرات من Tunnel-Creation-ECIES:

  • تغيير الطول غير المشفر من 512 إلى 202 بايت
  • تغيير الطول المشفر من 528 إلى 218 بايت

الردود ECIES مشفرة باستخدام ChaCha20/Poly1305.

جميع الحقول من اليسار لليمين.

حجم غير مشفر: 202 بايت.

bytes    0-x: خيارات الردود على بناء النفق (خرائط)
  bytes    x-x: بيانات أخرى تقتضيها الخيارات
  bytes  x-200: حشو عشوائي (انظر أدناه)
  byte     201: بايت الرد

خيارات الردود على بناء النفق هو هيكل خرائط كما هو معرف في Common. هذا للاستخدام المستقبلي. لا توجد خيارات معرفة حاليا. إذا كان هيكل الخرائط فارغًا، فهذا هو بايتين 0x00 0x00. الحد الأقصى لحجم الخرائط (بما في ذلك حقل الطول) هو 201 بايت، والحد الأقصى لقيمة حقل طول الخرائط هو 199.

بايت الرد هو واحد من القيم التالية كما هو معرف في Tunnel-Creation لتجنب استخراج البصمة:

  • 0x00 (قبول)
  • 30 (TUNNEL_REJECT_BANDWIDTH)

سجل الردود القصير مشفراً

حجم مشفر: 218 بايت

bytes   0-201: ChaCha20 مشفر ShortBuildReplyRecord
  bytes 202-217: Poly1305 MAC

KDF

انظر قسم KDF أدناه.

ShortTunnelBuild

نوع I2NP 25

هذه الرسالة ترسل إلى القفزة الوسطى، OBEP، وIBEP (منشئ). لا يمكن إرسالها إلى IBGW (استخدم ملفوف بالثوم InboundTunnelBuild بدلاً من ذلك). عند إرسالها من قبل OBEP، تتحول إلى OutboundTunnelBuildReply، ملفوفة بالثوم، وترسل إلى المنشئ.

+----+----+----+----+----+----+----+----+
  | num| ShortBuildRequestRecords...
  +----+----+----+----+----+----+----+----+

  num ::
         1 بايت `عدد صحيح`
         القيم الصالحة: 1-8

  حجم السجل: 218 بايت
  الحجم الكلي: 1+$num*218

ملاحظات

  • العدد النموذجي للسجلات هو 4، لحجم اجمالي 873.

OutboundTunnelBuildReply

نوع I2NP 26

هذه الرسالة ترسل فقط من قبل OBEP إلى IBEP (المنشئ) عبر نفق وارد موجود. لا يمكن إرسالها إلى أي قفزة أخرى. هي دائما مشفرة بالثوم.

+----+----+----+----+----+----+----+----+
  | num|                                  |
  +----+                                  +
  |      ShortBuildReplyRecords...        |
  +----+----+----+----+----+----+----+----+

  num ::
         العدد الاجمالي للسجلات,
         1 بايت `عدد صحيح`
         القيم الصالحة: 1-8

  ShortBuildReplyRecords ::
         السجلات المشفرة
         الطول: num * 218

  حجم السجل المشفر: 218 بايت
  الحجم الكلي: 1+$num*218

ملاحظات

  • العدد النموذجي للسجلات هو 4، لحجم اجمالي 873.
  • يجب أن تكون هذه الرسالة مشفرة بالثوم.

KDF

نحن نستخدم ck من حالة Noise بعد تشفير/فك تشفير سجل بناء النفق لاشتقاق المفاتيح التالية: مفتاح الرد، مفتاح AES للطبقة، مفتاح IV الطبقة ومفتاح رد الثوم/العلامة لـ OBEP.

مفتاح الرد: على عكس السجلات الطويلة لا يمكننا استخدام الجزء الأيسر من ck لمفتاح الرد، لأنه ليس الأخير وسيتم استخدامه لاحقاً. يستخدم مفتاح الرد لتشفير الرد الذي يسجل باستخدام AEAD/Chaha20/Poly1305 وChacha20 للرد على السجلات الأخرى. كلاهما يستخدم نفس المفتاح، القيد هو موضع السجل في الرسالة بدءاً من 0.

keydata = HKDF(ck, ZEROLEN, "SMTunnelReplyKey", 64)
  replyKey = keydata[32:63]
  ck = keydata[0:31]

  مفتاح الطبقة:
  مفتاح الطبقة دائماً AES في الوقت الحالي، لكن يمكن استخدام نفس KDF من Chacha20

  keydata = HKDF(ck, ZEROLEN, "SMTunnelLayerKey", 64)
  layerKey = keydata[32:63]

  مفتاح IV للسجل غير OBEP:
  ivKey = keydata[0:31]
  لأنه الأخير

  مفتاح IV لسجل OBEP:
  ck = keydata[0:31]
  keydata = HKDF(ck, ZEROLEN, "TunnelLayerIVKey", 64)
  ivKey = keydata[32:63]
  ck = keydata[0:31]

  مفتاح رد الثوم/العلامة لـ OBEP:
  keydata = HKDF(ck, ZEROLEN, "RGarlicKeyAndTag", 64)
  replyKey = keydata[32:63]
  replyTag = keydata[0:7]

التبرير

هذا التصميم يزيد من إعادة استخدام الخوارزميات التشفيرية الحالية، البروتوكولات، والشفرة.

هذا التصميم يقلل من المخاطر.

ChaCha20 أسرع قليلاً من AES للسجلات الصغيرة، في اختبارات جافا. ChaCha20 يتجنب الحاجة إلى مضاعفات حجم البيانات لـ 16.

ملاحظات التطبيق

  • كما هو الحال مع الرسالة المتغيرة الحالية لبناء النفق، الرسائل التي تقل عن 4 سجلات لا ينصح بها. الافتراضي النموذجي هو 3 قفزات. يجب بناء الأنفاق الواردة بسجل إضافي للمنشئ، لذلك القفزة الأخيرة لا تعرف أنها الأخيرة. حتى لا تعرف القفزات الوسطى إذا كان النفق واردًا أو صادرًا، يجب بناء الأنفاق الصادرة بـ 4 سجلات أيضًا.

القضايا

الهجرة

ستستغرق التنفيذ والاختبار والإصدار عدة إصدارات وحوالي عام. المراحل كما يلي. تعيين كل مرحلة لإصدار معين يعتمد إلى حد كبير على سرعة التطوير.

قد تختلف تفاصيل التنفيذ والهجرة لكل تنفيذ I2P.

يجب أن يضمن مختلق النفق أن جميع القفزات في النفق المنشأ هي ECIES-X25519، وعلى الأقل الإصدار TBD. يجب أن لا يكون مختلق النفق بالضرورة ECIES-X25519؛ يمكن أن يكون ElGamal. ومع ذلك، إذا كان المختلق هو ElGamal، فإنه يكشف للقفزة الأقرب أنه المنشئ. لذلك، عمليًا، يجب أن تُنشأ هذه الأنفاق فقط بواسطة أجهزة التوجيه ECIES.

يجب أن لا يكون من الضروري أن يتم تسوير الأنفاق المُزوجة OBEP أو IBGW بـ ECIES أو من أي إصدار معين. الرسائل الجديدة ملفوفة بالثوم وغير مرئية في OBEP أو IBGW من النفق المُزوج.

المرحلة 1: التنفيذ، غير مفعل بشكل افتراضي

المرحلة 2 (الإصدار التالي): التمكين بشكل افتراضي

لا توجد مشكلات في التوافق مع الإصدارات السابقة. لا يجوز إرسال الرسائل الجديدة إلا إلى أجهزة التوجيه التي تدعمها.

الملحق

دون عبء الثوم للـ STBM غير المشفر الوارد، إذا لم نستخدم ITBM:

حجم الفتحة المتاح 4 الحالي: 4 * 528 + النفقات العامة = 3 رسائل نفق

  رسالة بناء 4 فتحة تناسب في رسالة نفق واحدة، ECIES فقط:

  1024
  - 21 عنوان الجزء
  ----
  1003
  - 35 تعليمات التوزيع غير المجزأة ROUTER
  ----
  968
  - 16 عنوان I2NP
  ----
  952
  - 1 عدد الفتحات
  ----
  951
  / 4 فتحات
  ----
  237 حجم سجل البناء المشفر الجديد (مقابل 528 الآن)
  - 16 تجزئة مختصرة
  - 32 مفتاح زمني
  - 16 MAC
  ----
  173 حجم سجل البناء النصي الأقصى (مقابل 222 الآن)

مع عبء الثوم لأنماط “N” لتشفير STBM الوارد، إذا لم نستخدم ITBM:

حجم الفتحة المتاح 4 الحالي: 4 * 528 + النفقات العامة = 3 رسائل نفق

  رسالة بناء مشفرة بالثوم 4 فتحة لتناسب في رسالة نفق واحدة، ECIES فقط:

  1024
  - 21 عنوان الجزء
  ----
  1003
  - 35 تعليمات التوزيع غير المجزأة ROUTER
  ----
  968
  - 16 عنوان I2NP
  -  4 الطول
  ----
  948
  - 32 بايت مفتاح زمني
  ----
  916
  - 7 بايت كتلة DateTime
  ----
  909
  - 3 بايت نفقات عامة من كتلة Garlic
  ----
  906
  - 9 بايت عنوان I2NP
  ----
  897
  - 1 بايت تعليمات التوصيل Garlic المحلي
  ----
  896
  - 16 بايت Poly1305 MAC
  ----
  880
  - 1 عدد الفتحات
  ----
  879
  / 4 فتحات
  ----
  219 حجم سجل البناء المشفر الجديد (مقابل 528 الآن)
  - 16 تجزئة مختصرة
  - 32 مفتاح زمني
  - 16 MAC
  ----
  155 حجم سجل البناء النصي الأقصى (مقابل 222 الآن)

الملاحظات:

الحجم الحالي لسجل البناء النصي قبل الحشو غير المستخدم: 193

إزالة التجزئة الكاملة لجهاز التوجيه وتوليد HKDF للمفاتيح/IVs يمكن أن يحرر الكثير من المساحة للخيارات المستقبلية. إذا كان كل شيء HKDF، فالمساحة النصية المطلوبة حوالي 58 بايت (بدون أي خيارات).

سيكون OTBRM الملفوف بالثوم أصغر قليلاً من STBM الملفوف بالثوم، لأن تعليمات التوصيل محليه وليس ROUTER، لا توجد كتلة DATETIME مضمنة، ويستخدم علامة 8 بايت بدلاً من مفتاح زمني 32 بايت لرسالة ‘N’ الكاملة.

المصادر