الحالة
تمت الموافقة في المراجعة بتاريخ 2025-04-15. تم دمج التغييرات في المواصفات. تم تنفيذها في Java I2P اعتبارًا من API 0.9.66. راجع وثائق التنفيذ للحصول على الحالة.
نظرة عامة
خرجت من Prop123 كتقديم منفصل.
لا يمكن التحقق من التوقيعات غير المتصلة في معالجة مخطط البيانات القابلة للاسترجاع. يحتاج إلى علم للإشارة إلى توقيع غير متصل ولكن لا يوجد مكان لوضع علم.
سيتطلب بروتوكول I2CP جديد تمامًا ورقم تنسيق، ليتم إضافته إلى مواصفات DATAGRAMS. دعونا نسميه “Datagram2”.
الأهداف
- إضافة دعم للتوقيعات غير المتصلة
- إضافة مقاومة الإعادة
- إضافة نكهة بدون توقيعات
- إضافة حقول للأعلام والخيارات للمرونة
الأهداف الغير مطلوبة
الدعــم الكـامـل للبروتوكول من الطرف إلى الطرف للتحكم في الاختناق، إلخ. سيتم بناؤه فوق، أو كبديل لـ Datagram2، وهو بروتوكول منخفض المستوى. لن يكون من المنطقي تصميم بروتوكول عالي الأداء يعتمد فقط على Datagram2، بسبب حقل الإرسال وتكاليف التوقيع. أي بروتوكول من هذا القبيل يجب أن يقوم بإجراء مصافحة أولية مع Datagram2 ثم التبديل إلى مخططات البيانات RAW.
الدافع
باقي من عمل LS2 الذي تم الانتهاء منه خلاف ذلك في عام 2019.
من المتوقع أن يكون التطبيق الأول لاستخدام Datagram2 إعلانات تقديم bittorrent عبر بروتوكول UDP، كما هو مطبق في i2psnark و zzzot، انظر Prop160.
مواصفات مخطط البيانات القابلة للاسترجاع
للإشارة، فيما يلي مراجعة للمواصفات لمخططات البيانات القابلة للاسترجاع، مأخوذة من Datagrams. رقم بروتوكول I2CP القياسي لمخططات البيانات القابلة للاسترجاع هو PROTO_DATAGRAM (17).
+----+----+----+----+----+----+----+----+
| from |
+ +
| |
~ ~
~ ~
| |
+ +
| |
| |
+----+----+----+----+----+----+----+----+
| signature |
+ +
| |
+ +
| |
+ +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
| payload...
+----+----+----+----//
from :: a `Destination`
length: 387+ bytes
المرسل والموقع لمخطط البيانات
signature :: توقيع `Signature`
يجب أن يتطابق نوع التوقيع مع نوع المفتاح العام للتوقيع الخاص بـ $from
الطول: 40+ بايتات، كما يتطلب نوع التوقيع.
لنوع المفتاح DSA_SHA1 الافتراضي:
توقيع DSA للهاش SHA-256 للحمولة.
لأنواع المفاتيح الأخرى:
`التوقيع` للحمولة.
يمكن التحقق من التوقيع بالمفتاح العام للتوقيع الخاص بـ $from
payload :: البيانات
الطول: من 0 إلى حوالي 31.5 كيلوبايت (انظر الملاحظات)
الطول الإجمالي: طول الحمولة + 423+
التصميم
- تحديد بروتوكول جديد 19 - مخطط بيانات قابل للاسترجاع مع خيارات.
- تحديد بروتوكول جديد 20 - مخطط بيانات قابل للاسترجاع بدون توقيع.
- إضافة حقل للأعلام للتوقيعات غير المتصلة والتوسع المستقبلي
- نقل التوقيع بعد الحمولة لسهولة المعالجة
- مواصفات توقيع جديدة مختلفة عن مخطط البيانات القابل للاسترجاع أو البث، بحيث يفشل التحقق من التوقيع إذا تم تفسيره كمخطط بيانات قابل للاسترجاع أو لبث. يتم تحقيق ذلك عن طريق نقل التوقيع بعد الحمولة، وبإدخال هاش الوجهة في دالة التوقيع.
- إضافة منع الإعادة للمخططات، كما تم في Prop164 للبث.
- إضافة قسم للخيارات التعسفية
- إعادة استخدام تنسيق التوقيع غير المتصل من Common وStreaming.
- قسم التوقيع غير المتصل يجب أن يكون قبل الحمولة المتغيرة الطول والـ توقيع، حيث يتم تحديد طول التوقيع.
المواصفات
البروتوكول
رقم بروتوكول I2CP الجديد لـ Datagram2 هو 19. أضفه كـ PROTO_DATAGRAM2 إلى I2CP.
رقم بروتوكول I2CP الجديد لـ Datagram3 هو 20. أضفه كـ PROTO_DATAGRAM2 إلى I2CP.
تنسيق Datagram2
أضف Datagram2 إلى DATAGRAMS على النحو التالي:
+----+----+----+----+----+----+----+----+
| |
~ from ~
~ ~
| |
+----+----+----+----+----+----+----+----+
| flags | options (optional) |
+----+----+ +
~ ~
~ ~
+----+----+----+----+----+----+----+----+
| |
~ offline_signature (optional) ~
~ expires, sigtype, pubkey, offsig ~
| |
+----+----+----+----+----+----+----+----+
| |
~ payload ~
~ ~
| |
+----+----+----+----+----+----+----+----+
| |
~ signature ~
~ ~
| |
+----+----+----+----+----+----+----+----+
from :: a `Destination`
length: 387+ bytes
المرسل و(ما لم يتم التوقيع بطريقة غير متصلة) موقع مخطط البيانات
flags :: (2 بايتات)
ترتيب البتات: 15 14 ... 3 2 1 0
بتات 3-0: الإصدار: 0x02 (0 0 1 0)
البتة 4: إذا كانت 0، لا توجد خيارات؛ إذا كانت 1، يتم تضمين تخطيط الخيارات
البتة 5: إذا كانت 0، لا يوجد توقيع غير متصل؛ إذا كانت 1، موقعة بشكل غير متصل
البتات 15-6: غير مستخدمة، اضبط على 0 للتوافق مع الاستخدامات المستقبلية
options :: (2+ بايتات إذا كانت موجودة)
إذا كان العلم يشير إلى وجود الخيارات، فإن `Mapping`
يحتوي على خيارات نصية تعسفية
offline_signature ::
إذا كان العلم يشير إلى المفاتيح غير المتصلة، فقسم التوقيع غير المتصل،
كما هو محدد في المواصفات المشتركة لهياكل البيانات،
مع الحقول الأربعة التالية. الطول: يختلف حسب أنواع التوقيع
عبر الإنترنت وغير المتصل، عادةً 102 بايتات لأنواع التوقيع
Ed25519
يمكن، ويجب، إنشاء هذا القسم بشكل غير متصل.
expires :: الطابع الزمني لانقضاء الصلاحية
(4 بايتات، ترتيب بايتات الكبير، ثوانٍ منذ البداية، ينتهي في 2106)
sigtype :: نوع التوقيع الانتقالي (2 بايتات، ترتيب بايتات الكبير)
pubkey :: المفتاح العام للتوقيع الانتقالي (الطول كما يقتضيه نوع التوقيع)،
عادةً 32 بايتات لأنواع التوقيع Ed25519.
offsig :: توقيع `Signature`
توقيع للطابع الزمني لانقضاء الصلاحية، نوع التوقيع الانتقالي،
والمفتاح العام، بواسطة المفتاح العام للوجهة،
الطول: 40+ بايتات، كما يقتضيه نوع التوقيع، عادةً
64 بايتات لأنواع التوقيع Ed25519.
payload :: البيانات
الطول: من 0 إلى حوالي 61 كيلوبايت (انظر الملاحظات)
signature :: توقيع `Signature`
يجب أن يتطابق نوع التوقيع مع نوع المفتاح العام للتوقيع الخاص بـ $from
(إذا لم يكن هناك توقيع غير متصل) أو نوع التوقيع الانتقالي
(إذا كان موقعة بطريقة غير متصلة)
الطول: 40+ بايتات، كما يقتضيه نوع التوقيع، عادةً
64 بايتات لأنواع التوقيع Ed25519.
`التوقيع` للحمولة والحقول الأخرى كما هو محدد أدناه.
يتم التحقق من التوقيع بالمفتاح العام للتوقيع الخاص بـ $from
(إذا لم يكن هناك توقيع غير متصل) أو المفتاح العام الانتقالي
(إذا كان موقعة بطريقة غير متصلة)
الإجمالي الطول: 433 + طول الحمولة على الأقل؛ الطول المعتاد للمُرسلين X25519 وبدون توقيعات غير متصلة: 457 + طول الحمولة. لاحظ أن الرسالة سيتم ضغطها عادةً باستخدام gzip عند طبقة I2CP، مما سيؤدي إلى توفيرات كبيرة إذا كانت الوجهة من نوع from قابلة للضغط.
ملاحظة: تنسيق التوقيع غير المتصل هو نفسه في مواصفات الهياكل المشتركة Common وStreaming.
التوقيعات
التوقيع يشمل الحقول التالية.
- المقدمة: هاش بطول 32 بايت للوجهة المستهدفة (غير مضمن في مخطط البيانات)
- الأعلام
- الخيارات (إذا كانت موجودة)
- التوقيع غير المتصل (إذا كان موجودًا)
- الحمولة
في مخطط البيانات القابل للاسترجاع، لنوع المفتاح DSA_SHA1، كان التوقيع على هاش SHA-256 للحمولة، وليس الحمولة نفسها؛ هنا، التوقيع دائمًا على الحقول أعلاه (ليس على الهاش)، بغض النظر عن نوع المفتاح.
التحقق من ToHash
يجب على المستقبلين التحقق من التوقيع (باستخدام هاش الوجهة لديهم) والتخلص من مخطط البيانات حالما يفشل، لمنع الإعادة.
تنسيق Datagram3
أضف Datagram3 إلى DATAGRAMS كما يلي:
+----+----+----+----+----+----+----+----+
| |
~ fromhash ~
~ ~
| |
+----+----+----+----+----+----+----+----+
| flags | options (optional) |
+----+----+ +
~ ~
~ ~
+----+----+----+----+----+----+----+----+
| |
~ payload ~
~ ~
| |
+----+----+----+----+----+----+----+----+
fromhash :: هاش `Hash`
الطول: 32 بايت
مرسل مخطط البيانات
flags :: (2 بايتات)
ترتيب البتات: 15 14 ... 3 2 1 0
بتات 3-0: الإصدار: 0x03 (0 0 1 1)
البتة 4: إذا كانت 0، لا توجد خيارات؛ إذا كانت 1، يتم تضمين تخطيط الخيارات
بتات 15-5: غير مستخدمة، اضبط على 0 للتوافق مع الاستخدامات المستقبلية
options :: (2+ بايتات إذا كانت موجودة)
إذا أشار العلم إلى وجود الخيارات، فإن `Mapping`
يحتوي على خيارات نصية تعسفية
payload :: البيانات
الطول: من 0 إلى حوالي 61 كيلوبايت (انظر الملاحظات)
الطول الإجمالي: 34 + طول الحمولة على الأقل.
SAM
أضف STYLE=DATAGRAM2 وSTYLE=DATAGRAM3 إلى مواصفات SAMv3. تحديث المعلومات حول التوقيعات غير المتصلة.
التكاليف المضافة
يضيف هذا التصميم 2 بايتات كمصاريف إضافية لمخططات البيانات القابلة للاسترجاع للأعلام. هذا مقبول.
تحليل الأمان
يجب أن يكون إدخال هاش الوجهة في التوقيع فعالًا في منع هجمات الإعادة.
تنسيق Datagram3 يفتقر إلى التوقيعات، لذا لا يمكن التحقق من المرسل، وهجمات الإعادة ممكنة. يجب أن يتم التحقق المطلوب في طبقة التطبيق، أو بواسطة الراوتر في طبقة ratchet.
ملاحظات
- الطول العملي محدود بالطبقات الأدنى من البروتوكولات - مواصفات رسالة النفق TUNMSG تحدد الرسائل بحوالي 61.2 كيلوبايت والوسائط الناقلة تحد الرسائل حاليًا بحوالي 64 كيلوبايت، لذا فإن طول البيانات هنا محدود بحوالي 61 كيلوبايت.
- انظر الملاحظات الهامة حول موثوقية المخططات الكبيرة API. للحصول على أفضل النتائج، حدد الحمولة بحوالي 10 كيلوبايت أو أقل.
التوافق
لا يوجد. يجب إعادة كتابة التطبيقات لتوجيه رسائل I2CP الخاصة بـ Datagram2 استنادًا إلى البروتوكول و/أو المنفذ. الرسائل المحورة بشكل خاطئ من Datagram2 والمفسرة كمخططات بيانات قابلة للاسترجاع أو رسائل تدفق ستفشل بناءً على التوقيع أو التنسيق أو كليهما.
الهجرة
كل تطبيق UDP يجب أن يكتشف الدعم وينتقل بشكل منفصل. أبرز تطبيق UDP هو بروتوكول تورنت.
بروتوكول تورنت
بروتوكول DHT: يحتاج إلى علم تمديد ربما، مثل i2p_dg2، التنسيق مع BiglyBT
الإعلانات عبر بروتوكول UDP في تورنت Prop160: قم بتصميمها من البداية. التنسيق مع BiglyBT وi2psnark وzzzot
أخرى
Bote: غير مرجح أن ينتقل، غير مدعوم بنشاط
Streamr: لا أحد يستخدمه، لا توجد خطة للهجرة
SAM لتطبيقات UDP: لا توجد معروفة