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

إدخالات netDB جديدة

Proposal 123
مفتوح
Author zzz, str4d, orignal
Created 2016-01-16
Last Updated 2020-07-18
Supercedes: 110, 120, 121, 122

الحالة

تم الانتهاء من أجزاء من هذا الاقتراح، وتم تنفيذه في الإصدار 0.9.38 و0.9.39.
تم الآن تحديث المواصفات الخاصة بالهياكل المشتركة، وI2CP، وI2NP، وغيرها لتعكس التغييرات المدعومة حاليًا.

الأجزاء المكتملة لا تزال عرضة لمراجعات طفيفة.
أما الأجزاء الأخرى من هذا الاقتراح فهي لا تزال قيد التطوير وعرضة لمراجعات جوهرية.

تُعد ميزة البحث عن الخدمة (الأنواع 9 و11) ذات أولوية منخفضة وغير مجدولة، وقد يتم فصلها إلى اقتراح منفصل.

نظرة عامة

هذا تحديث وتجميع للإقتراحات الأربعة التالية:

  • 110 LS2
  • 120 Meta LS2 للدعم الكبير للاتصال المتعدد (multihoming)
  • 121 LS2 مشفر
  • 122 البحث عن خدمة بدون مصادقة (anycasting)

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

الاقتراحات التالية مرتبطة إلى حد ما:

  • 140 الاتصال المتعدد الخفي (incompatible with this proposal)
  • 142 قالب تشفير جديد (للتشفير التماثلي الجديد)
  • 144 ECIES-X25519-AEAD-Ratchet
  • 145 ECIES-P256
  • 146 Red25519
  • 148 EdDSA-BLAKE2b-Ed25519
  • 149 B32 لـ LS2 المشفر
  • 150 بروتوكول مزرعة الثوم (Garlic Farm Protocol)
  • 151 ECDSA Blinding

الاقتراح

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

الأهداف

  • التوافق العكسي
  • إمكانية استخدام LS2 مع دعم الاتصال المتعدد القديم
  • لا يتطلب تشفيرًا أو بنيات أولية جديدة للدعم
  • الحفاظ على فصل التشفير عن التوقيع؛ دعم جميع الإصدارات الحالية والمستقبلية
  • تمكين مفاتيح التوقيع الخارجية (offline keys) بشكل اختياري
  • تقليل دقة الطوابع الزمنية لتقليل التعرف (fingerprinting)
  • تمكين تشفير جديد للوجهات
  • تمكين دعم الاتصال المتعدد على نطاق واسع
  • إصلاح مشكلات متعددة في LS المشفر الحالي
  • دعم اختياري للتعمية (blinding) لتقليل الرؤية من قبل الخوادم الممتلئة (floodfills)
  • يدعم التشفير إما مفتاحًا واحدًا أو مفاتيح قابلة للإبطال متعددة
  • البحث عن الخدمة لتسهيل البحث عن outproxies، وتشغيل تمهيد DHT للتطبيقات، واستخدامات أخرى
  • عدم كسر أي شيء يعتمد على تجزئة الوجهة الثنائية بحجم 32 بايت، مثل bittorrent
  • إضافة مرونة إلى leasesets من خلال الخصائص، كما هو الحال في routerinfos.
  • وضع طابع النشر والانتهاء المتغير في الرأس، بحيث يعمل حتى إذا كانت المحتويات مشفرة (لا يتم اشتقاق الطابع الزمني من أقرب إيجار)
  • جميع الأنواع الجديدة تعيش في نفس مساحة DHT والمواقع نفسها مثل leasesets الحالية، بحيث يمكن للمستخدمين التحول من LS القديم إلى LS2، أو التبديل بين LS2 وMeta وEncrypted، دون تغيير الوجهة أو التجزئة.
  • يمكن تحويل وجهة حالية لاستخدام مفاتيح خارجية، أو العودة إلى مفاتيح داخلية، دون تغيير الوجهة أو التجزئة.

غير الأهداف / خارج النطاق

  • خوارزمية جديدة لتدوير DHT أو توليد عشوائي مشترك
  • نوع التشفير الجديد ونظام التشفير من طرف إلى طرف لاستخدام هذا النوع سيكون في اقتراح منفصل. لا يتم تحديد أو مناقشة أي تشفير جديد هنا.
  • تشفير جديد لـ RIs أو بناء الأنفاق. سيكون ذلك في اقتراح منفصل.
  • طرق تشفير ونقل واستقبال رسائل I2NP DLM / DSM / DSRM. لا تتغير.
  • كيفية إنشاء ودعم Meta، بما في ذلك الاتصال بين الراوترات، والإدارة، والتبديل عند الفشل، والتنسيق. قد تُضاف الدعم إلى I2CP أو i2pcontrol أو بروتوكول جديد. قد يتم أو لا يتم توحيد ذلك.
  • كيفية تنفيذ وإدارة أنفاق ذات صلاحية أطول، أو إلغاء الأنفاق الحالية. هذا أمر صعب للغاية، وبدونه لا يمكن تحقيق إيقاف تشغيل سلس معقول.
  • تغييرات نموذج التهديد
  • تنسيق التخزين الخارجي، أو طرق تخزين/استرجاع/مشاركة البيانات.
  • تفاصيل التنفيذ غير مناقشة هنا ويتم تركها لكل مشروع.

التبرير

يُضيف LS2 حقولًا لتغيير نوع التشفير وللتغيرات المستقبلية في البروتوكول.

يُصلح LS2 المشفر عدة مشكلات أمنية في LS المشفر الحالي باستخدام تشفير غير متماثل لمجموعة الإيجارات بأكملها.

يوفر Meta LS2 دعمًا مرنًا وفعالًا وواسع النطاق للاتصال المتعدد.

توفر سجلات وقائمة الخدمة خدمات البث (anycast) مثل البحث عن الأسماء وتمهيد DHT.

أنواع بيانات NetDB

تُستخدم أرقام الأنواع في رسائل I2NP Database Lookup/Store.

تشير العمود “end-to-end” إلى ما إذا كانت الاستعلامات/الاستجابات تُرسل إلى وجهة في رسالة ثوم (Garlic Message).

الأنواع الحالية:

NetDB DataLookup TypeStore Type
any0any
LS11
RI20
exploratory3DSRM

الأنواع الجديدة:

NetDB DataLookup TypeStore TypeStd. LS2 Header?Sent end-to-end?
LS213yesyes
Encrypted LS215nono
Meta LS217yesno
Service Recordn/a9yesno
Service List411nono

ملاحظات

  • تُستخدم أنواع الاستعلام حاليًا في البتات 3-2 في رسالة Database Lookup. أي أنواع إضافية تتطلب استخدام البت 4.

  • جميع أنواع التخزين فردية لأن البتات العليا في حقل النوع في رسالة Database Store تُهمل من قبل الراوترات القديمة. نفضل أن يفشل التحليل كـ LS بدلاً من RI مضغوط.

  • هل يجب أن يكون النوع صريحًا أم ضمنيًا أم لا شيء في البيانات المشمولة بالتوقيع؟

عملية البحث/التخزين

قد تُعاد الأنواع 3 و5 و7 كاستجابة لاستعلام leaseset قياسي (النوع 1).
لا يُعاد النوع 9 كاستجابة لاستعلام.
يُعاد النوع 11 كاستجابة لاستعلام جديد من نوع البحث عن الخدمة (النوع 11).

فقط النوع 3 يمكن إرساله في رسالة ثوم من عميل إلى عميل.

التنسيق

الأنواع 3 و7 و9 تستخدم تنسيقًا مشتركًا::

رأس LS2 القياسي

  • كما هو محدد أدناه

الجزء المحدد حسب النوع

  • كما هو محدد أدناه لكل جزء

التوقيع القياسي لـ LS2:

  • الطول حسب نوع التوقيع لمفتاح التوقيع

لا يبدأ النوع 5 (المشفر) بـ Destination وله تنسيق مختلف. انظر أدناه.

النوع 11 (Service List) هو تجميع لعدة سجلات خدمة ولديه تنسيق مختلف. انظر أدناه.

اعتبارات الخصوصية/الأمان

قيد المراجعة (TBD)

رأس LS2 القياسي

تستخدم الأنواع 3 و7 و9 رأس LS2 القياسي، كما هو محدد أدناه:

التنسيق

رأس LS2 القياسي:
  - النوع (1 بايت)
    ليس فعليًا في الرأس، لكنه جزء من البيانات المشمولة بالتوقيع.
    يُؤخذ من الحقل في رسالة Database Store.
  - الوجهة (387+ بايت)
  - الطابع الزمني للنشر (4 بايت، big endian، ثواني منذ العصر، يدور في 2106)
  - الانتهاء (2 بايت، big endian) (انزياح من الطابع الزمني للنشر بالثواني، كحد أقصى 18.2 ساعة)
  - العلامات (2 بايت)
    ترتيب البتات: 15 14 ... 3 2 1 0
    البت 0: إذا كان 0، لا توجد مفاتيح خارجية؛ إذا كان 1، توجد مفاتيح خارجية
    البت 1: إذا كان 0، leaseset منشور قياسي.
           إذا كان 1، leaseset غير منشور. لا ينبغي توزيعه أو نشره أو إرساله كاستجابة لاستعلام. إذا انتهى هذا leaseset، لا تطلب من netdb نسخة جديدة، إلا إذا كانت البتة 2 مضبوطة.
    البت 2: إذا كان 0، leaseset منشور قياسي.
           إذا كان 1، سيتم تعمية وترميز هذا leaseset غير المشفر عند النشر.
           إذا انتهى هذا leaseset، اطلب الموقع المعتم من netdb للحصول على نسخة جديدة.
           إذا تم ضبط هذه البتة على 1، يجب ضبط البتة 1 على 1 أيضًا.
           اعتبارًا من الإصدار 0.9.42.
    البتات 3-15: تُضبط على 0 للتوافق مع الاستخدامات المستقبلية
  - إذا أشارت العلامة إلى مفاتيح خارجية، قسم التوقيع الخارجي:
    طابع انتهاء الصلاحية (4 بايت، big endian، ثواني منذ العصر، يدور في 2106)
    نوع التوقيع المؤقت (2 بايت، big endian)
    المفتاح العمومي للتوقيع المؤقت (الطول حسب نوع التوقيع)
    توقيع على طابع الانتهاء، ونوع التوقيع المؤقت، والمفتاح العمومي،
    بواسطة المفتاح العمومي للوجهة،
    الطول حسب نوع توقيع المفتاح العمومي للوجهة.
    يمكن، ويجب، إنشاء هذا القسم خارجيًا.

التبرير

  • غير منشور/منشور: للاستخدام عند إرسال تخزين قاعدة بيانات من طرف إلى طرف، قد يرغب الراوتر المرسل في الإشارة إلى أن هذا leaseset لا ينبغي إرساله للآخرين. نحن نستخدم حاليًا أساليب تقديرية للحفاظ على هذه الحالة.

  • منشور: يحل محل المنطق المعقد المطلوب لتحديد “الإصدار” لـ leaseset. حاليًا، الإصدار هو انتهاء صلاحية آخر إيجار، ويجب على الراوتر الناشر زيادة هذا الانتهاء بـ 1 مللي ثانية على الأقل عند نشر leaseset يزيل فقط إيجارًا أقدم.

  • الانتهاء: يسمح بانتهاء صلاحية إدخال netdb يكون أبكر من انتهاء آخر إيجار له. قد لا يكون مفيدًا لـ LS2، حيث من المتوقع أن تظل leasesets بحد أقصى 11 دقيقة، ولكن لأنواع جديدة أخرى، يكون ضروريًا (انظر Meta LS وService Record أدناه).

  • مفاتيح خارجية اختيارية، لتقليل تعقيد التنفيذ الأولي/المطلوب.

المشكلات

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

  • بديل: طابع زمني بـ 3 بايت (العصر / 10 دقائق)، إصدار بـ 1 بايت، انتهاء بـ 2 بايت

  • هل النوع صريح أم ضمني في البيانات / التوقيع؟ “ثوابت” النطاق للتوقيع؟

ملاحظات

  • يجب ألا ينشر الراوترات leaseset أكثر من مرة في الثانية. إذا فعلوا ذلك، يجب أن يزيدوا بشكل اصطناعي الطابع الزمني للنشر بـ 1 على leaseset المنشور سابقًا.

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

  • المفاتيح والتوقيع الخارجي مناسبان فقط للوجهات طويلة الأمد، أي الخوادم، وليس العملاء.

أنواع DatabaseEntry الجديدة

LeaseSet 2

التغييرات من LeaseSet الحالي:

  • إضافة الطابع الزمني للنشر، وطابع انتهاء الصلاحية، والعلامات، والخصائص
  • إضافة نوع التشفير
  • إزالة مفتاح الإبطال

البحث باستخدام علامة LS القياسية (1) التخزين باستخدام نوع LS2 القياسي (3) التخزين في تجزئة الوجهة تُستخدم هذه التجزئة بعد ذلك لتوليد “مفتاح التوجيه” اليومي، كما في LS1 مدة الانتهاء النموذجية 10 دقائق، كما في LS عادي. ينشر بواسطة الوجهة

التنسيق

رأس LS2 القياسي كما هو محدد أعلاه

  الجزء المحدد حسب نوع LS2 القياسي
  - الخصائص (Mapping كما هو محدد في مواصفات الهياكل المشتركة، 2 بايت صفر إذا لم تكن موجودة)
  - عدد أقسام المفاتيح التي تلي (1 بايت، الحد الأقصى قيد المراجعة)
  - أقسام المفاتيح:
    - نوع التشفير (2 بايت، big endian)
    - طول مفتاح التشفير (2 بايت، big endian)
      هذا صريح، بحيث يمكن لخوادم التعبئة تحليل LS2 بأنواع تشفير غير معروفة.
    - مفتاح التشفير (عدد البايتات المحدد)
  - عدد leases2 (1 بايت)
  - leases2 (40 بايت لكل منها)
    هذه إيجارات، ولكن بـ 4 بايت بدلاً من 8 بايت للانتهاء،
    ثواني منذ العصر (تدور في 2106)

  التوقيع القياسي لـ LS2:
  - التوقيع
    إذا أشارت العلامة إلى مفاتيح خارجية، يتم التوقيع بواسطة المفتاح العمومي المؤقت،
    وإلا، بواسطة المفتاح العمومي للوجهة
    الطول حسب نوع توقيع مفتاح التوقيع
    التوقيع على كل ما سبق.

التبرير

  • الخصائص: التوسع المستقبلي والمرونة. توضع أولًا في حال كانت ضرورية لتحليل البيانات المتبقية.

  • أزواج متعددة من نوع التشفير/المفتاح العمومي تسهل الانتقال إلى أنواع تشفير جديدة. الطريقة الأخرى هي نشر leasesets متعددة، ربما باستخدام نفس الأنفاق، كما نفعل الآن لوجهات DSA وEdDSA. يمكن تحديد نوع التشفير الوارد في النفق باستخدام آلية session tag الحالية، و/أو فك التشفير التجريبي باستخدام كل مفتاح. قد توفر أطوال الرسائل الواردة أيضًا دليلًا.

المناقشة

يستمر هذا الاقتراح في استخدام المفتاح العمومي في leaseset كمفتاح تشفير من طرف إلى طرف، ويترك الحقل العمومي في الوجهة غير مستخدم، كما هو الحال الآن. لا يتم تحديد نوع التشفير في شهادة مفتاح الوجهة، وستبقى 0.

البديل المرفوض هو تحديد نوع التشفير في شهادة مفتاح الوجهة، واستخدام المفتاح العمومي في الوجهة، وعدم استخدام المفتاح العمومي في leaseset. لا نخطط للقيام بذلك.

مزايا LS2:

  • موقع المفتاح العمومي الفعلي لا يتغير.
  • يمكن تغيير نوع التشفير أو المفتاح العمومي دون تغيير الوجهة.
  • إزالة حقل الإبطال غير المستخدم
  • التوافق الأساسي مع أنواع DatabaseEntry الأخرى في هذا الاقتراح
  • السماح بأنواع تشفير متعددة

عيوب LS2:

  • موقع المفتاح العمومي ونوع التشفير يختلف عن RouterInfo
  • يحافظ على المفتاح العمومي غير المستخدم في leaseset
  • يتطلب التنفيذ عبر الشبكة؛ في البديل، يمكن استخدام أنواع تشفير تجريبية، إذا سمح بها خوادم التعبئة (لكن انظر الاقتراحات 136 و137 حول دعم أنواع توقيع تجريبية). قد يكون الاقتراح البديل أسهل في التنفيذ والاختبار لأنواع التشفير التجريبية.

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

بعض هذا خارج نطاق هذا الاقتراح،
لكن وضع الملاحظات هنا مؤقتًا لأننا لا نملك
اقتراح تشفير منفصل بعد.
انظر أيضًا اقتراحات ECIES 144 و145.

  • يمثل نوع التشفير مزيجًا
    من المنحنى، وطول المفتاح، ونظام التشفير من طرف إلى طرف،
    بما في ذلك KDF وMAC، إن وجد.

  • أدرجنا حقل طول المفتاح، بحيث يكون LS2
    قابلاً للتحليل والتحقق من قبل خادم التعبئة حتى لأنواع التشفير غير المعروفة.

  • أول نوع تشفير جديد مقترح سيكون
    على الأرجح ECIES/X25519. كيف يستخدم من طرف إلى طرف
    (إما نسخة معدلة قليلاً من ElGamal/AES+SessionTag
    أو شيء جديد تمامًا، مثل ChaCha/Poly) سيتم تحديده
    في اقتراح أو أكثر منفصلة.
    انظر أيضًا اقتراحات ECIES 144 و145.

ملاحظات

  • تغيرت مدة انتهاء الإيجارات من 8 بايت إلى 4 بايت.

  • إذا نفذنا الإبطال في يوم ما، يمكننا فعل ذلك بحقل انتهاء صفر، أو إيجارات صفرية، أو كليهما. لا حاجة لمفتاح إبطال منفصل.

  • تكون مفاتيح التشفير مرتبة حسب تفضيل الخادم، الأكثر تفضيلًا أولًا. السلوك الافتراضي للعميل هو اختيار أول مفتاح بدعم نوع تشفير مدعوم. قد يستخدم العملاء خوارزميات اختيار أخرى بناءً على دعم التشفير، والأداء النسبي، وعوامل أخرى.

LS2 المشفر

الأهداف:

  • إضافة التعمية (blinding)
  • السماح بأنواع توقيع متعددة
  • لا يتطلب أي بنيات تشفير أولية جديدة
  • تشفير اختياري لكل مستلم، قابل للإبطال
  • دعم تشفير LS2 القياسي وMeta LS2 فقط

لا يُرسل LS2 المشفر أبدًا في رسالة ثوم من طرف إلى طرف.
استخدم LS2 القياسي كما هو موضح أعلاه.

التغييرات من LeaseSet المشفر الحالي:

  • تشفير كل شيء لأغراض الأمان
  • تشفير آمن، ليس فقط باستخدام AES.
  • تشفير لكل مستلم

البحث باستخدام علامة LS القياسية (1) التخزين باستخدام نوع LS2 المشفر (5) التخزين في تجزئة نوع التوقيع المعتم والمفتاح العمومي المعتم نوع توقيع بـ 2 بايت (big endian، مثل 0x000b) || المفتاح العمومي المعتم تُستخدم هذه التجزئة بعد ذلك لتوليد “مفتاح التوجيه” اليومي، كما في LS1 مدة الانتهاء النموذجية 10 دقائق، كما في LS عادي، أو ساعات، كما في meta LS. ينشر بواسطة الوجهة

التعريفات

نحدد الدوال التالية المقابلة للقطع البنائية التشفيرية المستخدمة
لـ LS2 المشفر:

CSRNG(n)
مخرجات بطول n بايت من مولد أرقام عشوائية آمن تشفيريًا.

بالإضافة إلى شرط أن يكون CSRNG آمنًا تشفيريًا (وبالتالي  
مناسبًا لتوليد مواد المفاتيح)، يجب أن يكون آمنًا  
لاستخدام مخرجات n بايت كمواد مفاتيح عندما تكون تسلسلات البايت التي تسبقها وتليها مكشوفة على الشبكة (مثل في salt أو تعبئة مشفرة). يجب على التنفيذات التي تعتمد على مصدر قد لا يكون موثوقًا أن تُجري تجزئة لأي مخرجات ستُعرض على الشبكة. انظر [PRNG references](http://projectbullrun.org/dual-ec/ext-rand.html) و[Tor dev discussion](https://lists.torproject.org/pipermail/tor-dev/2015-November/009954.html).

H(p, d)
دالة تجزئة SHA-256 التي تأخذ سلسلة تخصيص p وبيانات d، وتُنتج مخرجات بطول 32 بايت.

استخدم SHA-256 كما يلي::

    H(p, d) := SHA-256(p || d)

STREAM
تشفير الدفق ChaCha20 كما هو محدد في RFC 7539 Section 2.4 ، مع العداد الأولي
مضبوطًا على 1. S_KEY_LEN = 32 و S_IV_LEN = 12.

ENCRYPT(k, iv, plaintext)  
    يُشفّر plaintext باستخدام مفتاح التشفير k، وnonce iv الذي يجب أن يكون فريدًا للمفتاح k. يُعيد نصًا مشفرًا بنفس حجم plaintext.

    يجب أن يكون النص المشفر بأكمله غير قابل للتمييز عن عشوائي إذا كان المفتاح سريًا.

DECRYPT(k, iv, ciphertext)  
    يُفك تشفير ciphertext باستخدام مفتاح التشفير k، وnonce iv. يُعيد النص الأصلي.

SIG
نظام توقيع RedDSA (المقابل لـ SigType 11) مع تعمية المفتاح.
يحتوي على الدوال التالية:

DERIVE_PUBLIC(privkey)  
    تُعيد المفتاح العمومي المقابل للمفتاح الخاص المعطى.

SIGN(privkey, m)  
    تُعيد توقيعًا بواسطة المفتاح الخاص privkey على الرسالة m المعطاة.

VERIFY(pubkey, m, sig)  
    تتحقق من التوقيع sig مقابل المفتاح العمومي pubkey والرسالة m. تُعيد  
    صحيحًا إذا كان التوقيع صحيحًا، خطأً خلاف ذلك.

يجب أن تدعم أيضًا عمليات تعمية المفتاح التالية:

GENERATE_ALPHA(data, secret)  
    تولّد alpha للذين يعرفون البيانات وسر اختياري.  
    يجب أن تكون النتيجة موزعة بشكل متطابق مع المفاتيح الخاصة.

BLIND_PRIVKEY(privkey, alpha)  
    يُعمي مفتاحًا خاصًا، باستخدام سر alpha.

BLIND_PUBKEY(pubkey, alpha)  
    يُعمي مفتاحًا عموميًا، باستخدام سر alpha.  
    لزوج مفاتيح معين (privkey, pubkey) ينطبق العلاقة التالية::

        BLIND_PUBKEY(pubkey, alpha) ==
        DERIVE_PUBLIC(BLIND_PRIVKEY(privkey, alpha))

DH
نظام اتفاق المفتاح العام X25519. مفاتيح خاصة بطول 32 بايت، مفاتيح عامة بطول 32
بايت، يُنتج مخرجات بطول 32 بايت. يحتوي على الدوال التالية:

GENERATE_PRIVATE()  
    يولد مفتاحًا خاصًا جديدًا.

DERIVE_PUBLIC(privkey)  
    يُعيد المفتاح العمومي المقابل للمفتاح الخاص المعطى.

DH(privkey, pubkey)  
    يولد سرًا مشتركًا من المفتاح الخاص والعامة المعطى.

HKDF(salt, ikm, info, n)
دالة اشتقاق مفتاح تشفيرية تأخذ مواد مفتاح إدخال ikm (التي
يجب أن تكون إنتروبيا جيدة ولكن ليس مطلوبًا أن تكون سلسلة عشوائية موحدة)، وملح
بطول 32 بايت، وقيمة ‘info’ محددة بالسياق، وتُنتج مخرجات
بطول n بايت مناسبة للاستخدام كمواد مفتاح.

استخدم HKDF كما هو محدد في [RFC 5869](https://tools.ietf.org/html/rfc5869)، باستخدام دالة HMAC التجزئة SHA-256  
كما هو محدد في [RFC 2104](https://tools.ietf.org/html/rfc2104). هذا يعني أن SALT_LEN كحد أقصى 32 بايت.

التنسيق

يتكون تنسيق LS2 المشفر من ثلاث طبقات متداخلة:

  • طبقة خارجية تحتوي على المعلومات النصية الضرورية للتخزين والاسترجاع.
  • طبقة وسطى تتعامل مع مصادقة العميل.
  • طبقة داخلية تحتوي على بيانات LS2 الفعلية.

التنسيق العام يبدو كالتالي::

بيانات الطبقة 0 + Enc(بيانات الطبقة 1 + Enc(بيانات الطبقة 2)) + توقيع

لاحظ أن LS2 المشفر معتم. لا يوجد Destination في الرأس.
موضع تخزين DHT هو SHA-256(sig type || المفتاح العمومي المعتم)، ويتم تدويره يوميًا.

لا يستخدم رأس LS2 القياسي المحدد أعلاه.

الطبقة 0 (الخارجية)

النوع
1 بايت

ليس فعليًا في الرأس، لكنه جزء من البيانات المشمولة بالتوقيع.  
يُؤخذ من الحقل في رسالة Database Store.

نوع توقيع المفتاح العمومي المعتم
2 بايت، big endian
سيكون دائمًا النوع 11، يحدد مفتاحًا معتمًا من نوع Red25519.

المفتاح العمومي المعتم
الطول حسب نوع التوقيع

الطابع الزمني للنشر
4 بايت، big endian

ثواني منذ العصر، يدور في 2106

الانتهاء
2 بايت، big endian

انزياح من الطابع الزمني للنشر بالثواني، كحد أقصى 18.2 ساعة

العلامات
2 بايت

ترتيب البتات: 15 14 ... 3 2 1 0

البت 0: إذا كان 0، لا توجد مفاتيح خارجية؛ إذا كان 1، توجد مفاتيح خارجية

البتات الأخرى: تُضبط على 0 للتوافق مع الاستخدامات المستقبلية

بيانات المفتاح المؤقت
موجودة إذا أشارت العلامة إلى مفاتيح خارجية

طابع انتهاء الصلاحية  
    4 بايت، big endian

    ثواني منذ العصر، يدور في 2106

نوع توقيع مؤقت  
    2 بايت، big endian

المفتاح العمومي للتوقيع المؤقت  
    الطول حسب نوع التوقيع

التوقيع  
    الطول حسب نوع توقيع المفتاح العمومي المعتم

    على طابع الانتهاء، ونوع التوقيع المؤقت، والمفتاح العمومي المؤقت.

    يتم التحقق باستخدام المفتاح العمومي المعتم.

lenOuterCiphertext
2 بايت، big endian

outerCiphertext
lenOuterCiphertext بايت

بيانات الطبقة 1 المشفرة. انظر أدناه لاستخلاص المفتاح وخوارزميات التشفير.

التوقيع
الطول حسب نوع توقيع مفتاح التوقيع المستخدم

التوقيع على كل ما سبق.

إذا أشارت العلامة إلى مفاتيح خارجية، يتم التحقق من التوقيع باستخدام المفتاح العمومي المؤقت. وإلا، يتم التحقق باستخدام المفتاح العمومي المعتم.

الطبقة 1 (الوسطى)

العلامات
1 بايت

ترتيب البتات: 76543210

البت 0: 0 للجميع، 1 لكل عميل، قسم المصادقة يتبع

البتات 3-1: مخطط المصادقة، فقط إذا كانت البتة 0 مضبوطة على 1 لكل عميل، وإلا 000  
          000: مصادقة عميل DH (أو لا مصادقة لكل عميل)  
          001: مصادقة عميل PSK

البتات 7-4: غير مستخدمة، تُضبط على 0 للتوافق المستقبلي

بيانات مصادقة عميل DH
موجودة إذا كانت البتة 0 للعلامة مضبوطة على 1 والبتات 3-1 مضبوطة على 000.

المفتاح العمومي العابر  
    32 بايت

العملاء  
    2 بايت، big endian

    عدد إدخالات authClient التالية، 40 بايت لكل منها

authClient  
    بيانات المصادقة لعميل واحد.  
    انظر أدناه لخوارزمية المصادقة لكل عميل.

    clientID_i  
        8 بايت

    clientCookie_i  
        32 بايت

بيانات مصادقة عميل PSK
موجودة إذا كانت البتة 0 للعلامة مضبوطة على 1 والبتات 3-1 مضبوطة على 001.

authSalt  
    32 بايت

العملاء  
    2 بايت، big endian

    عدد إدخالات authClient التالية، 40 بايت لكل منها

authClient  
    بيانات المصادقة لعميل واحد.  
    انظر أدناه لخوارزمية المصادقة لكل عميل.

    clientID_i  
        8 بايت

    clientCookie_i  
        32 بايت

innerCiphertext
الطول مُستدل من lenOuterCiphertext (أي بيانات متبقية)

بيانات الطبقة 2 المشفرة. انظر أدناه لاستخلاص المفتاح وخوارزميات التشفير.

الطبقة 2 (الداخلية)

النوع
1 بايت

إما 3 (LS2) أو 7 (Meta LS2)

البيانات
بيانات LeaseSet2 للنوع المعطى.

تشمل الرأس والتوقيع.

استخلاص مفتاح التعمية

نستخدم المخطط التالي لتعمية المفتاح،
استنادًا إلى Ed25519 وZCash RedDSA .
التوقيعات Re25519 على منحنى Ed25519، باستخدام SHA-512 للتجزئة.

لا نستخدم Tor’s rend-spec-v3.txt appendix A.2 ،
الذي له أهداف تصميم مشابهة، لأن مفاتيحه العامة المعتمة
قد تكون خارج المجموعة الفرعية من الدرجة الأولية، مع آثار أمنية غير معروفة.

الأهداف

  • يجب أن يكون مفتاح التوقيع العام في الوجهة غير المعتمة
    Ed25519 (sig type 7) أو Red25519 (sig type 11)؛
    لا تُدعم أنواع توقيع أخرى
  • إذا كان مفتاح التوقيع العام خارجيًا، يجب أن يكون المفتاح العمومي للتوقيع المؤقت أيضًا Ed25519
  • تعمية المفتاح بسيطة حسابيًا
  • استخدام بنيات تشفيرية موجودة
  • لا يمكن فك تعمية المفاتيح العامة المعتمة
  • يجب أن تكون المفاتيح العامة المعتمة على منحنى Ed25519 والمجموعة الفرعية من الدرجة الأولية
  • يجب معرفة مفتاح التوقيع العام للوجهة
    (الوجهة الكاملة غير مطلوبة) لاستخلاص المفتاح العام المعتم
  • توفير اختياري لسر إضافي مطلوب لاستخلاص المفتاح العام المعتم

الأمان

يتطلب أمان مخطط التعمية أن يكون
توزيع alpha هو نفسه توزيع المفاتيح الخاصة غير المعتمة.
ومع ذلك، عند تعمية مفتاح خاص Ed25519 (sig type 7)
إلى مفتاح خاص Red25519 (sig type 11)، يكون التوزيع مختلفًا.
لتحقيق متطلبات zcash section 4.1.6.1 ،
يجب استخدام Red25519 (sig type 11) للمفاتيح غير المعتمة أيضًا، بحيث
“مزيج مفتاح عام مُعاد تعيينه وتوقيعات تحت هذا المفتاح لا يكشف المفتاح الذي تم إعادة تعيينه منه.”
نسمح بالنوع 7 للوجهات الحالية، لكن نوصي
بالنوع 11 للوجهات الجديدة التي ستكون مشفرة.

التعريفات

B
نقطة الأساس Ed25519 (المولد) 2^255 - 19 كما في Ed25519

L
ترتيب Ed25519 2^252 + 27742317777372353535851937790883648493
كما في Ed25519

DERIVE_PUBLIC(a)
تحويل مفتاح خاص إلى عام، كما في Ed25519 (الضرب في G)

alpha
رقم عشوائي بطول 32 بايت يعرفه من يعرف الوجهة.

GENERATE_ALPHA(destination, date, secret)
توليد alpha للتاريخ الحالي، للذين يعرفون الوجهة والسر.
يجب أن تكون النتيجة موزعة بشكل متطابق مع مفاتيح Ed25519 الخاصة.

a
مفتاح التوقيع الخاص EdDSA أو RedDSA بطول 32 بايت غير معتم يستخدم لتوقيع الوجهة

A
مفتاح التوقيع العام EdDSA أو RedDSA بطول 32 بايت في الوجهة،
= DERIVE_PUBLIC(a)، كما في Ed25519

a’
مفتاح التوقيع الخاص EdDSA بطول 32 بايت معتم يستخدم لتوقيع leaseset المشفر
هذا مفتاح خاص EdDSA صالح.

A’
مفتاح التوقيع العام EdDSA بطول 32 بايت معتم في الوجهة،
يمكن توليده بـ DERIVE_PUBLIC(a’)، أو من A و alpha.
هذا مفتاح عام EdDSA صالح، على المنحنى وعلى المجموعة الفرعية من الدرجة الأولية.

LEOS2IP(x)
قلب ترتيب بايتات الإدخال إلى little-endian

H*(x)
32 بايت = (LEOS2IP(SHA512(x))) mod B، نفس ما في Ed25519 hash-and-reduce

حسابات التعمية

يجب توليد سر جديد alpha ومفاتيح معتمة جديدة كل يوم (UTC).
يتم حساب السر alpha والمفاتيح المعتمة كما يلي.

GENERATE_ALPHA(destination, date, secret)، للجميع:

// GENERATE_ALPHA(destination, date, secret)

  // السر اختياري، وإلا طوله صفر
  A = مفتاح التوقيع العام للوجهة
  stA = نوع توقيع A، 2 بايت big endian (0x0007 أو 0x000b)
  stA' = نوع توقيع المفتاح العام المعتم A'، 2 بايت big endian (0x000b)
  keydata = A || stA || stA'
  datestring = 8 بايت ASCII YYYYMMDD من التاريخ الحالي بالتوقيت العالمي
  secret = سلسلة مشفرة UTF-8
  seed = HKDF(H("I2PGenerateAlpha", keydata), datestring || secret, "i2pblinding1", 64)
  // معاملة seed كقيمة 64 بايت little-endian
  alpha = seed mod L

BLIND_PRIVKEY()، لمالك نشر leaseset:

// BLIND_PRIVKEY()

  alpha = GENERATE_ALPHA(destination, date, secret)
  // إذا كان لمفتاح خاص Ed25519 (النوع 7)
  seed = مفتاح التوقيع الخاص للوجهة
  a = النصف الأيسر من SHA512(seed) و clamped كما هو معتاد لـ Ed25519
  // وإلا، لمفتاح خاص Red25519 (النوع 11)
  a = مفتاح التوقيع الخاص للوجهة
  // الجمع باستخدام الحساب القياسي
  مفتاح التوقيع الخاص المعتم = a' = BLIND_PRIVKEY(a, alpha) = (a + alpha) mod L
  مفتاح التوقيع العام المعتم = A' = DERIVE_PUBLIC(a')

BLIND_PUBKEY()، للعملاء الذين يسترجعون leaseset:

// BLIND_PUBKEY()

  alpha = GENERATE_ALPHA(destination, date, secret)
  A = مفتاح التوقيع العام للوجهة
  // الجمع باستخدام عناصر المجموعة (نقاط على المنحنى)
  المفتاح العام المعتم = A' = BLIND_PUBKEY(A, alpha) = A + DERIVE_PUBLIC(alpha)

كلا طريقتي حساب A’ تعطيان نفس النتيجة، كما هو مطلوب.

التوقيع

يتم توقيع leaseset غير المعتم بواسطة مفتاح التوقيع الخاص غير المعتم Ed25519 أو Red25519
ويتم التحقق منه باستخدام مفتاح التوقيع العام غير المعتم Ed25519 أو Red25519 (sig types 7 أو 11) كما هو معتاد.

إذا كان مفتاح التوقيع العام خارجيًا،
يتم توقيع leaseset غير المعتم بواسطة مفتاح التوقيع الخاص المؤقت غير المعتم Ed25519 أو Red25519
ويتم التحقق منه باستخدام مفتاح التوقيع العام المؤقت Ed25519 أو Red25519 (sig types 7 أو 11) كما هو معتاد.
انظر أدناه لمزيد من الملاحظات حول المفاتيح الخارجية لـ leasesets المشفرة.

لتوقيع leaseset المشفر، نستخدم Red25519، استنادًا إلى RedDSA
لتوقيع والتحقق باستخدام مفاتيح معتمة.
التوقيعات Red25519 على منحنى Ed25519، باستخدام SHA-512 للتجزئة.

Red25519 مطابق تمامًا لـ Ed25519 باستثناء ما هو محدد أدناه.

حسابات التوقيع/التحقق

تستخدم الجزء الخارجي من leaseset المشفر مفاتيح وتوقيعات Red25519.

Red25519 مطابق تقريبًا لـ Ed25519. هناك فرقان:

مفاتيح Red25519 الخاصة تُولد من أرقام عشوائية ثم يجب أن تُختزل mod L، حيث L معرف أعلاه.
مفاتيح Ed25519 الخاصة تُولد من أرقام عشوائية ثم “تُشبك” باستخدام
القناع البتّي للبايتات 0 و31. لا يتم ذلك لـ Red25519.
الدوال GENERATE_ALPHA() و BLIND_PRIVKEY() المعرفة أعلاه تولد
مفاتيح Red25519 صحيحة باستخدام mod L.

في Red25519، حساب r للتوقيع يستخدم بيانات عشوائية إضافية،
ويستخدم قيمة المفتاح العام بدلاً من تجزئة المفتاح الخاص.
بسبب البيانات العشوائية، كل توقيع Red25519 مختلف، حتى
عند توقيع نفس البيانات بنفس المفتاح.

التوقيع:

T = 80 بايت عشوائية
  r = H*(T || publickey || message)
  // الباقي هو نفسه في Ed25519

التحقق:

// نفس ما في Ed25519

التشفير والمعالجة

استخلاص بيانات الاعتماد الفرعية

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

A = مفتاح التوقيع العام للوجهة
  stA = نوع توقيع A، 2 بايت big endian (0x0007 أو 0x000b)
  stA' = نوع توقيع A'، 2 بايت big endian (0x000b)
  keydata = A || stA || stA'
  credential = H("credential", keydata)

تضمن سلسلة التخصيص أن بيانات الاعتماد لا تتصادم مع أي تجزئة تستخدم
كمفتاح بحث DHT، مثل تجزئة الوجهة العادية.

للمفتاح المعتم، يمكننا بعد ذلك استخلاص بيانات اعتماد فرعية:

subcredential = H("subcredential", credential || blindedPublicKey)

تُدرج بيانات الاعتماد الفرعية في عمليات استخلاص المفتاح أدناه، مما يربط
تلك المفاتيح بمعرفة مفتاح التوقيع العام للوجهة.

تشفير الطبقة 1

أولاً، يتم إعداد الإدخال لعملية استخلاص المفتاح:

outerInput = subcredential || publishedTimestamp

بعد ذلك، يتم توليد salt عشوائي:

outerSalt = CSRNG(32)

ثم يتم استخلاص المفتاح المستخدم لتشفير الطبقة 1:

keys = HKDF(outerSalt, outerInput, "ELS2_L1K", 44)
  outerKey = keys[0:31]
  outerIV = keys[32:43]

أخيرًا، يتم تشفير وتوثيق نص الطبقة 1:

outerCiphertext = outerSalt || ENCRYPT(outerKey, outerIV, outerPlaintext)

فك تشفير الطبقة 1

يتم تحليل salt من نص الطبقة 1 المشفر:

outerSalt = outerCiphertext[0:31]

ثم يتم استخلاص المفتاح المستخدم لتشفير الطبقة 1:

outerInput = subcredential || publishedTimestamp
  keys = HKDF(outerSalt, outerInput, "ELS2_L1K", 44)
  outerKey = keys[0:31]
  outerIV = keys[32:43]

أخيرًا، يتم فك تشفير نص الطبقة 1 المشفر:

outerPlaintext = DECRYPT(outerKey, outerIV, outerCiphertext[32:end])

تشفير الطبقة 2

عند تمكين مصادقة العميل، authCookie يتم حسابه كما هو موضح أدناه.
عند تعطيل مصادقة العميل، authCookie هو مصفوفة بايتات فارغة.

يستمر التشفير بطريقة مشابهة للطبقة 1:

innerInput = authCookie || subcredential || publishedTimestamp
  innerSalt = CSRNG(32)
  keys = HKDF(innerSalt, innerInput, "ELS2_L2K", 44)
  innerKey = keys[0:31]
  innerIV = keys[32:43]
  innerCiphertext = innerSalt || ENCRYPT(innerKey, innerIV, innerPlaintext)

فك تشفير الطبقة 2

عند تمكين مصادقة العميل، authCookie يتم حسابه كما هو موضح أدناه.
عند تعطيل مصادقة العميل، authCookie هو مصفوفة بايتات فارغة.

يستمر فك التشفير بطريقة مشابهة للطبقة 1:

innerInput = authCookie || subcredential || publishedTimestamp
  innerSalt = innerCiphertext[0:31]
  keys = HKDF(innerSalt, innerInput, "ELS2_L2K", 44)
  innerKey = keys[0:31]
  innerIV = keys[32:43]
  innerPlaintext = DECRYPT(innerKey, innerIV, innerCiphertext[32:end])

مصادقة العميل الفردية

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

هناك بديلين لتنفيذ مصادقة العميل الفردية:

مصادقة عميل DH

يولد كل عميل زوج مفاتيح DH [csk_i, cpk_i]، ويرسل المفتاح العام cpk_i
إلى الخادم.

معالجة الخادم ^^^^^^^^^^^^^^^^^ يولد الخادم authCookie جديدًا وزوج مفاتيح DH عابر:

authCookie = CSRNG(32)
  esk = GENERATE_PRIVATE()
  epk = DERIVE_PUBLIC(esk)

ثم لكل عميل مصرح له، يشفر الخادم authCookie إلى مفتاحه العام:

sharedSecret = DH(esk, cpk_i)
  authInput = sharedSecret || cpk_i || subcredential || publishedTimestamp
  okm = HKDF(epk, authInput, "ELS2_XCA", 52)
  clientKey_i = okm[0:31]
  clientIV_i = okm[32:43]
  clientID_i = okm[44:51]
  clientCookie_i = ENCRYPT(clientKey_i, clientIV_i, authCookie)

يضع الخادم كل زوج [clientID_i, clientCookie_i] في الطبقة 1 من
LS2 المشفر، مع epk.

معالجة العميل ^^^^^^^^^^^^^^^^^ يستخدم العميل مفتاحه الخاص لاستخلاص معرف العميل المتوقع clientID_i،
ومفتاح التشفير clientKey_i، وIV التشفير clientIV_i:

sharedSecret = DH(csk_i, epk)
  authInput = sharedSecret || cpk_i || subcredential || publishedTimestamp
  okm = HKDF(epk, authInput, "ELS2_XCA", 52)
  clientKey_i = okm[0:31]
  clientIV_i = okm[32:43]
  clientID_i = okm[44:51]

ثم يبحث العميل في بيانات المصادقة للطبقة 1 عن إدخال يحتوي
clientID_i. إذا وُجد إدخال مطابق، يفك تشفيره للحصول على
authCookie:

authCookie = DECRYPT(clientKey_i, clientIV_i, clientCookie_i)

مصادقة عميل المفتاح المشترك مسبقًا (PSK)

يولد كل عميل مفتاحًا سريًا بطول 32 بايت psk_i، ويرسله إلى الخادم.
بديلًا، يمكن للخادم توليد مفتاح سري، وإرساله إلى عميل أو أكثر.

معالجة الخادم ^^^^^^^^^^^^^^^^^ يولد الخادم authCookie جديدًا وملح:

authCookie = CSRNG(32)
  authSalt = CSRNG(32)

ثم لكل عميل مصرح له، يشفر الخادم authCookie إلى مفتاحه المشترك مسبقًا:

authInput = psk_i || subcredential || publishedTimestamp
  okm = HKDF(authSalt, authInput, "ELS2PSKA", 52)
  clientKey_i = okm[0:31]
  clientIV_i = okm[32:43]
  clientID_i = okm[44:51]
  clientCookie_i = ENCRYPT(clientKey_i, clientIV_i, authCookie)

يضع الخادم كل زوج [clientID_i, clientCookie_i] في الطبقة 1 من
LS2 المشفر، مع authSalt.

معالجة العميل ^^^^^^^^^^^^^^^^^ يستخدم العميل مفتاحه المشترك مسبقًا لاستخلاص معرف العميل المتوقع clientID_i،
ومفتاح التشفير clientKey_i، وIV التشفير clientIV_i:

authInput = psk_i || subcredential || publishedTimestamp
  okm = HKDF(authSalt, authInput, "ELS2PSKA", 52)
  clientKey_i = okm[0:31]
  clientIV_i = okm[32:43]
  clientID_i = okm[44:51]

ثم يبحث العميل في بيانات المصادقة للطبقة 1 عن إدخال يحتوي
clientID_i. إذا وُجد إدخال مطابق، يفك تشفيره للحصول على
authCookie:

authCookie = DECRYPT(clientKey_i, clientIV_i, clientCookie_i)

اعتبارات الأمان

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

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

قد يختار الخادم إخفاء عدد العملاء المشتركين عن طريق إدراج إدخالات عشوائية
في قائمة بيانات المصادقة.

مزايا مصادقة عميل DH ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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

عيوب مصادقة عميل DH ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  • يتطلب عمليات DH N + 1 في جانب الخادم لـ N عملاء.
  • يتطلب عملية DH واحدة في جانب العميل.
  • يتطلب من العميل توليد مفتاح سري.

مزايا مصادقة عميل PSK ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  • لا يتطلب عمليات DH.
  • يسمح للخادم بتوليد مفتاح سري.
  • يسمح للخادم بمشاركة نفس المفتاح مع عملاء متعددين، إذا رغب.

عيوب مصادقة عميل PSK ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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

LS مشفر مع عناوين Base 32

انظر الاقتراح 149.

لا يمكنك استخدام LS2 مشفر لـ bittorrent، بسبب ردود الإعلان المدمجة التي تكون 32 بايت.
تحتوي الـ 32 بايت فقط على التجزئة. لا يوجد مجال للإشارة إلى أن
leaseset مشفر، أو أنواع التوقيع.

LS مشفر مع مفاتيح خارجية

لـ leasesets المشفرة مع مفاتيح خارجية، يجب أيضًا توليد المفاتيح الخاصة المعتمة خارجيًا،
واحد لكل يوم.

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

لا يوجد تنسيق ملف محدد في هذا الاقتراح لتغليف مفاتيح مؤقتة و
معتمة متعددة وتوفيرها للعميل أو الراوتر.
لا يوجد تحسين لبروتوكول I2CP محدد في هذا الاقتراح لدعم
leasesets مشفرة مع مفاتيح خارجية.

ملاحظات

  • الخدمة التي تستخدم leasesets مشفرة ستنشر النسخة المشفرة إلى
    خوادم التعبئة. ومع ذلك، من أجل الكفاءة، سترسل leasesets غير مشفرة إلى
    العملاء في رسالة الثوم المغلفة، بعد المصادقة (عبر قائمة بيضاء، على
    سبيل المثال).

  • قد تحد خوادم التعبئة الحد الأقصى للحجم إلى قيمة معقولة لمنع الإساءة.

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

  • تم اختيار ChaCha20 على AES. بينما تكون السرعات متشابهة إذا كان
    دعم AES متوفرًا في العتاد، فإن ChaCha20 أسرع بـ 2.5-3 مرات عندما
    لا يكون دعم AES متوفرًا، مثل على أجهزة ARM منخفضة المستوى.

  • لا نهتم كثيرًا بالسرعة لدرجة استخدام BLAKE2b المفتاح. لديه حجم مخرجات
    كبيرًا بما يكفي لاستيعاب أكبر n نحتاجه (أو يمكننا استدعائه مرة واحدة لكل
    مفتاح مرغوب به مع وسيطة عداد). BLAKE2b أسرع بكثير من SHA-256، و
    BLAKE2b المفتاح سيخفض العدد الإجمالي لاستدعاءات دالة التجزئة.
    ومع ذلك، انظر الاقتراح 148، حيث يُقترح أن ننتقل إلى BLAKE2b لأسباب أخرى.
    انظر Secure key derivation performance .

Meta LS2

يُستخدم هذا لاستبدال الاتصال المتعدد. مثل أي leaseset، يتم توقيعه من قبل
المنشئ. هذا قائمة موثقة من تجزئات الوجهة.

يُعد Meta LS2 أعلى، وربما عقدًا وسيطة،
لهيكل شجري.
يحتوي على عدد من الإدخالات، كل منها يشير إلى LS أو LS2 أو Meta LS2 آخر
لدعم الاتصال المتعدد على نطاق واسع.
قد يحتوي Meta LS2 على مزيج من إدخالات LS وLS2 وMeta LS2.
أوراق الشجر في الشجرة تكون دائمًا LS أو LS2.
الشجرة عبارة عن DAG؛ الحلقات ممنوعة؛ يجب على العملاء الذين يقومون بالبحث اكتشاف الحلقات ورفض اتباعها.

قد يكون لـ Meta LS2 مدة انتهاء أطول بكثير من LS أو LS2 قياسي.
قد يكون للطبقة العليا انتهاء بعد تاريخ النشر بعدة ساعات.
سيتم فرض الحد الأقصى لوقت الانتهاء من قبل خوادم التعبئة والعملاء، وسيتم تحديده لاحقًا.

حالة الاستخدام لـ Meta LS2 هي الاتصال المتعدد على نطاق واسع، ولكن بدون
مزيد من الحماية لتتبع ارتباط الراوترات بـ leasesets (عند إعادة التشغيل) مما
يوفره الآن مع LS أو LS2.
هذا يعادل حالة استخدام “فيسبوك”، التي ربما لا تحتاج
إلى حماية التتبع. ربما تحتاج هذه الحالة إلى مفاتيح خارجية،
التي تُوفر في الرأس القياسي في كل عقدة من الشجرة.

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

دمج leasesets حيث تُجمع الإيجارات من راوترات متعددة، وتُوقع، وتُنشر
في leaseset واحد موثق في الاقتراح 140، “الاتصال المتعدد الخفي”.
هذا الاقتراح غير قابل للتطبيق كما هو مكتوب، لأن اتصالات البث لن تكون
“ثابتة” على راوتر واحد، انظر http://zzz.i 2p/topics/2335 .

بروتوكول الواجهة الخلفية، والتفاعل مع داخليات الراوتر والعميل، سيكون
معقدًا جدًا للاتصال المتعدد الخفي.

لتجنب إغراق خادم التعبئة لـ Meta LS في المستوى العلوي، يجب أن يكون الانتهاء
بضع ساعات على الأقل. يجب على العملاء تخزين Meta LS في المستوى العلوي، والحفاظ عليه
عبر إعادة التشغيل إذا لم ينتهِ.

نحتاج إلى تحديد خوارزمية للعملاء للتنقل في الشجرة، بما في ذلك خطط الاستبدال،
حتى يتم توزيع الاستخدام. بعض دالة المسافة بالتجزئة، التكلفة، والعشوائية.
إذا كان للعقدة كل من LS أو LS2 وMeta LS، نحتاج إلى معرفة متى يُسمح
باستخدام تلك leasesets، ومتى نستمر في التنقل في الشجرة.

البحث باستخدام علامة LS القياسية (1) التخزين باستخدام نوع Meta LS2 (7) التخزين في تجزئة الوجهة تُستخدم هذه التجزئة بعد ذلك لتوليد “مفتاح التوجيه” اليومي، كما في LS1 مدة الانتهاء النموذجية ساعات. كحد أقصى 18.2 ساعة (65535 ثانية) ينشر بواسطة الوجهة “الرئيسية” أو المنسق، أو منسقي وسيطين

التنسيق

رأس LS2 القياسي كما هو محدد أعلاه

  الجزء المحدد حسب نوع Meta LS2
  - الخصائص (Mapping كما هو محدد في مواصفات الهياكل المشتركة، 2 بايت صفر إذا لم تكن موجودة)
  - عدد الإدخالات (1 بايت) الحد الأقصى قيد المراجعة
  - الإدخالات. كل إدخال يحتوي على: (40 بايت)
    - التجزئة (32 بايت)
    - العلامات (2 بايت)
      قيد المراجعة. اضبط الكل على صفر للتوافق مع الاستخدامات المستقبلية.
    - النوع (1 بايت) نوع LS الذي يشير إليه؛
      1 لـ LS، 3 لـ LS2، 5 للمشفر، 7 للميتا، 0 للمجهول.
    - التكلفة (الأولوية) (1 بايت)
    - الانتهاء (4 بايت) (4 بايت، big endian، ثواني منذ العصر، يدور في 2106)
  - عدد الإبطالات (1 بايت) الحد الأقصى قيد المراجعة
  - الإبطالات: كل إبطال يحتوي على: (32 بايت)
    - التجزئة (32 بايت)

  التوقيع القياسي لـ LS2:
  - التوقيع (40+ بايت)
    التوقيع على كل ما سبق.

العلامات والخصائص: للاستخدام المستقبلي

ملاحظات

  • الخدمة الموزعة التي تستخدم هذا سيكون لديها “رئيسي” واحد أو أكثر مع
    المفتاح الخاص لوجهة الخدمة. سيحددون (خارج النطاق)
    القائمة الحالية للوجهات النشطة وسينشرون Meta LS2. من أجل
    التكرار، يمكن لعدة رؤساء أن يشتركوا (أي ينشروا في وقت واحد)
    Meta LS2.

  • يمكن لخدمة موزعة أن تبدأ بوجهة واحدة أو تستخدم
    الاتصال المتعدد القديم، ثم تنتقل إلى Meta LS2. يمكن لاستعلام LS قياسي أن يعيد
    أيًا من LS أو LS2 أو Meta LS2.

  • عندما تستخدم خدمة Meta LS2، ليس لديها أنفاق (إيجارات).

سجل الخدمة

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

هذا ليس LS2 لكنه يستخدم تنسيق الرأس والتوقيع القياسي لـ LS2.

البحث باستخدام n/a، انظر قائمة الخدمة التخزين باستخدام نوع سجل الخدمة (9) التخزين في تجزئة اسم الخدمة تُستخدم هذه التجزئة بعد ذلك لتوليد “مفتاح التوجيه” اليومي، كما في LS1 مدة الانتهاء النموذجية ساعات. كحد أقصى 18.2 ساعة (65535 ثانية) ينشر بواسطة الوجهة

التنسيق

رأس LS2 القياسي كما هو محدد أعلاه

  الجزء المحدد حسب نوع سجل الخدمة
  - المنفذ (2 بايت، big endian) (0 إذا لم يُحدد)
  - تجزئة اسم الخدمة (32 بايت)

  التوقيع القياسي لـ LS2:
  - التوقيع (40+ بايت)
    التوقيع على كل ما سبق.

ملاحظات

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

  • التخزين: قد يقيد خادم التعبئة التخزين الصارم لهذه السجلات
    ويحد من عدد السجلات المخزنة لكل تجزئة وانتهائها. قد تُستخدم
    قائمة بيضاء من التجزئات.

  • أي نوع netdb آخر عند نفس التجزئة له أولوية، لذلك لا يمكن لسجل الخدمة أبدًا
    أن يكتب فوق LS/RI، لكن LS/RI سيكتب فوق جميع سجلات الخدمة عند تلك التجزئة.

قائمة الخدمة

هذا لا يشبه LS2 ويستخدم تنسيقًا مختلفًا.

تُنشأ قائمة الخدمة وتُوقع بواسطة خادم التعبئة. إنها غير موثقة
بمعنى أن أي شخص يمكنه الانضمام إلى خدمة بنشر سجل خدمة إلى
خادم تعبئة.

تحتوي قائمة الخدمة على سجلات خدمة قصيرة، وليس سجلات خدمة كاملة. هذه
تحتوي على توقيعات ولكن فقط تجزئات، وليس وجهات كاملة، لذلك لا يمكن التحقق منها دون
الوجهة الكاملة.

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

إذا تم تضمين اسم الخدمة في سجل الخدمة أعلاه،
فقد يعترض مشغلو خوادم التعبئة؛ إذا تم تضمين التجزئة فقط،
فلا يوجد تحقق، ويمكن