مواصفات الهياكل الشائعة

تصف هذه الوثيقة بعض أنواع البيانات الشائعة لجميع بروتوكولات I2P، مثل I2NP ، وI2CP ، وSSU ، إلخ.

مواصفة النوع العام

عدد صحيح

الوصف

يمثل عدد صحيح غير سالب.

المحتويات

من 1 إلى 8 بايت بترتيب بايت الشبكة (big endian) تمثل عدد صحيح غير مُوقع.

التاريخ

الوصف

عدد المللي ثانية منذ منتصف الليل في 1 يناير 1970 بتوقيت GMT. إذا كان الرقم 0، فإن التاريخ غير محدد أو فارغ.

المحتويات

8 بايت Integer

نص

الوصف

يمثل سلسلة نصية مُرمزة بتشفير UTF-8.

المحتويات

بايت واحد أو أكثر حيث البايت الأول هو عدد البايتات (وليس الأحرف!) في السلسلة النصية والبايتات المتبقية من 0-255 هي مصفوفة الأحرف المُرمزة بـ UTF-8 غير المنتهية بقيمة فارغة. الحد الأقصى للطول هو 255 بايت (وليس أحرف). قد يكون الطول 0.

PublicKey

الوصف

تُستخدم هذه البنية في التشفير غير المتماثل ElGamal أو غيره، وتمثل الأس فقط وليس الأعداد الأولية، والتي هي ثابتة ومُعرَّفة في مواصفات التشفير ELGAMAL . خطط التشفير الأخرى في طور التعريف، انظر الجدول أدناه.

المحتويات

يتم استنتاج نوع المفتاح وطوله من السياق أو يتم تحديدهما في شهادة المفتاح الخاصة بوجهة أو RouterInfo، أو الحقول في LeaseSet2 أو هيكل بيانات آخر. النوع الافتراضي هو ElGamal. اعتباراً من الإصدار 0.9.38، قد يتم دعم أنواع أخرى، حسب السياق. المفاتيح هي big-endian ما لم يُذكر خلاف ذلك.

مفاتيح X25519 مدعومة في Destinations و LeaseSet2 اعتباراً من الإصدار 0.9.44. مفاتيح X25519 مدعومة في RouterIdentities اعتباراً من الإصدار 0.9.48.

المفتاح الخاص

الوصف

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

المحتويات

يتم استنتاج نوع المفتاح وطوله من السياق أو يتم تخزينهما بشكل منفصل في هيكل بيانات أو ملف مفتاح خاص. النوع الافتراضي هو ElGamal. اعتباراً من الإصدار 0.9.38، قد يتم دعم أنواع أخرى، حسب السياق. المفاتيح تكون big-endian ما لم يُذكر خلاف ذلك.

SessionKey

الوصف

يتم استخدام هذا الهيكل للتشفير وفك التشفير المتماثل باستخدام AES256.

المحتويات

32 بايت

JavaDoc: http://docs.i2p-projekt.de/javadoc/net/i2p/data/SessionKey.html

SigningPublicKey

الوصف

تُستخدم هذه البنية للتحقق من التوقيعات.

المحتويات

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

• عندما يتكون مفتاح من عنصرين (على سبيل المثال النقاط X,Y)، يتم تسلسله عبر حشو كل عنصر إلى length/2 بأصفار بادئة إذا لزم الأمر.

• جميع الأنواع تستخدم ترتيب Big Endian، باستثناء EdDSA و RedDSA، والتي يتم تخزينها ونقلها بتنسيق Little Endian.

JavaDoc: http://docs.i2p-projekt.de/javadoc/net/i2p/data/SigningPublicKey.html

SigningPrivateKey

الوصف

تُستخدم هذه البنية لإنشاء التوقيعات.

المحتويات

يتم تحديد نوع المفتاح وطوله عند إنشائه. النوع الافتراضي هو DSA_SHA1. اعتباراً من الإصدار 0.9.12، قد يتم دعم أنواع أخرى، حسب السياق.

• عندما يتكون مفتاح من عنصرين (على سبيل المثال النقاط X,Y)، يتم تسلسله عبر حشو كل عنصر إلى length/2 مع أصفار بادئة إذا لزم الأمر.

• جميع الأنواع تستخدم ترتيب البايت الكبير (Big Endian)، باستثناء EdDSA و RedDSA، والتي يتم تخزينها ونقلها بتنسيق ترتيب البايت الصغير (Little Endian).

JavaDoc: http://docs.i2p-projekt.de/javadoc/net/i2p/data/SigningPrivateKey.html

التوقيع

الوصف

تمثل هذه البنية توقيع بعض البيانات.

المحتويات

يتم استنتاج نوع التوقيع وطوله من نوع المفتاح المستخدم. النوع الافتراضي هو DSA_SHA1. اعتبارًا من الإصدار 0.9.12، قد يتم دعم أنواع أخرى، اعتمادًا على السياق.

• عندما يتكون التوقيع من عنصرين (على سبيل المثال القيم R,S)، يتم تسلسله عبر حشو كل عنصر إلى length/2 بأصفار بادئة إذا لزم الأمر.

• جميع الأنواع تستخدم ترتيب البايت الكبير (Big Endian)، باستثناء EdDSA و RedDSA، والتي يتم تخزينها ونقلها بتنسيق ترتيب البايت الصغير (Little Endian).

JavaDoc: http://docs.i2p-projekt.de/javadoc/net/i2p/data/Signature.html

التجميع

الوصف

يمثل SHA256 لبعض البيانات.

المحتويات

32 بايت

JavaDoc: http://docs.i2p-projekt.de/javadoc/net/i2p/data/Hash.html

علامة الجلسة

ملاحظة: Session Tags لوجهات ECIES-X25519 (ratchet) وrouters ECIES-X25519 هي 8 بايت. راجع ECIES و ECIES-ROUTERS .

الوصف

رقم عشوائي

المحتويات

32 بايت

JavaDoc: http://docs.i2p-projekt.de/javadoc/net/i2p/data/SessionTag.html

TunnelId

الوصف

يحدد معرفاً فريداً لكل router في tunnel. معرف Tunnel ID عادة ما يكون أكبر من الصفر؛ لا تستخدم قيمة الصفر إلا في حالات خاصة.

المحتويات

4 بايت Integer

JavaDoc: http://docs.i2p-projekt.de/javadoc/net/i2p/data/TunnelId.html

الشهادة

الوصف

الشهادة هي حاوية لمختلف الإيصالات أو إثباتات العمل المستخدمة عبر شبكة I2P.

المحتويات

1 بايت عدد صحيح يحدد نوع الشهادة، متبوعًا بـ 2 بايت عدد صحيح يحدد حجم حمولة الشهادة، ثم ذلك العدد من البايتات.

+----+----+----+----+----+-/
|type| length  | payload
+----+----+----+----+----+-/

type :: Integer
        length -> 1 byte

length :: Integer
          length -> 2 bytes

payload :: data
           length -> $length bytes

ملاحظات

• بالنسبة لـ Router Identities ، تكون الشهادة دائماً NULL حتى الإصدار 0.9.15. اعتباراً من 0.9.16، يتم استخدام Key Certificate لتحديد أنواع المفاتيح. اعتباراً من 0.9.48، يُسمح بأنواع المفاتيح العامة للتشفير X25519. انظر أدناه.

• بالنسبة لـ Garlic Cloves ، تكون الشهادة دائماً NULL، ولا توجد أنواع أخرى مُنفذة حالياً.

• بالنسبة لـ Garlic Messages ، تكون الشهادة دائماً NULL، ولا يوجد أي تطبيقات أخرى حالياً.

• بالنسبة لـ Destinations ، قد تكون الشهادة غير فارغة (non-NULL). اعتباراً من الإصدار 0.9.12، يمكن استخدام شهادة مفتاح لتحديد نوع المفتاح العام للتوقيع. انظر أدناه.

• يُحذر المطورون من السماح بوجود بيانات زائدة في الشهادات. يجب فرض الطول المناسب لكل نوع من أنواع الشهادات.

أنواع الشهادات

أنواع الشهادات التالية معرّفة:

تم تقديم شهادات المفاتيح في الإصدار 0.9.12. قبل ذلك الإصدار، كانت جميع PublicKeys هي مفاتيح ElGamal بحجم 256 بايت، وجميع SigningPublicKeys كانت مفاتيح DSA-SHA1 بحجم 128 بايت. توفر شهادة المفتاح آلية للإشارة إلى نوع PublicKey و SigningPublicKey في Destination أو RouterIdentity، ولتعبئة أي بيانات مفتاح تتجاوز الأطوال المعيارية.

من خلال الحفاظ على 384 بايت بالضبط قبل الشهادة، ووضع أي بيانات مفاتيح إضافية داخل الشهادة، نحافظ على التوافق مع أي برامج تقوم بتحليل الوجهات وهويات الـ router.

حمولة شهادة المفتاح تحتوي على:

أنواع مفاتيح التوقيع العامة المُعرّفة هي:

• كامل أو الجزء الأول من المفتاح العام المشفر

• حشو عشوائي إذا كان إجمالي أطوال المفتاحين أقل من 384 بايت

• الجزء الكامل أو الأول من مفتاح التوقيع العام

يتم محاذاة المفتاح العام للتشفير في البداية ويتم محاذاة المفتاح العام للتوقيع في النهاية. الحشو (إن وُجد) يكون في المنتصف. أطوال وحدود بيانات المفتاح الأولية، والحشو، وأجزاء بيانات المفتاح الزائدة في الشهادات غير محددة بشكل صريح، ولكنها مُشتقة من أطوال أنواع المفاتيح المحددة. إذا تجاوز إجمالي أطوال المفاتيح العامة للتشفير والتوقيع 384 بايت، فسيتم احتواء الباقي في شهادة المفتاح. إذا لم يكن طول المفتاح العام للتشفير 256 بايت، فإن الطريقة لتحديد الحد الفاصل بين المفتاحين ستكون محددة في مراجعة مستقبلية لهذا المستند.

أمثلة على التخطيطات باستخدام مفتاح ElGamal العام للتشفير ونوع مفتاح التوقيع العام المحدد:

ملاحظات

• يُحذر المطورون من السماح بوجود بيانات زائدة في شهادات المفاتيح (Key Certificates). يجب فرض الطول المناسب لكل نوع من أنواع الشهادات.

• شهادة KEY مع الأنواع 0,0 (ElGamal,DSA_SHA1) مسموحة ولكن غير مستحبة. لم يتم اختبارها جيداً وقد تسبب مشاكل في بعض التطبيقات. استخدم شهادة NULL في التمثيل القانوني لـ Destination أو RouterIdentity من نوع (ElGamal,DSA_SHA1)، والذي سيكون أقصر بـ 4 بايتات من استخدام شهادة KEY.

الربط

الوصف

مجموعة من تعيينات المفتاح/القيمة أو الخصائص

المحتويات

عدد صحيح بحجم 2 بايت متبوع بسلسلة من أزواج String=String;

تحذير: معظم استخدامات Mapping تكون في هياكل موقعة، حيث يجب ترتيب إدخالات Mapping حسب المفتاح، بحيث يكون التوقيع غير قابل للتغيير. عدم الترتيب حسب المفتاح سيؤدي إلى فشل التوقيع!

+----+----+----+----+----+----+----+----+
|  size   | key_string (len + data)| =  |
+----+----+----+----+----+----+----+----+
| val_string (len + data)     | ;  | ...
+----+----+----+----+----+----+----+
size :: `Integer`
        length -> 2 bytes
        Total number of bytes that follow

key_string :: `String`
              A string (one byte length followed by UTF-8 encoded characters)

= :: A single byte containing '='

val_string :: `String`
              A string (one byte length followed by UTF-8 encoded characters)

; :: A single byte containing ';'

ملاحظات

• التشفير ليس الأمثل - نحتاج إما إلى أحرف ‘=’ و ‘;’، أو إلى أطوال السلاسل النصية، ولكن ليس كلاهما

• تشير بعض الوثائق إلى أن السلاسل النصية قد لا تتضمن ‘=’ أو ‘;’ ولكن هذا التشفير يدعمها

• السلاسل النصية معرّفة لتكون UTF-8 ولكن في التطبيق الحالي، I2CP يستخدم UTF-8 بينما I2NP لا يفعل ذلك. على سبيل المثال، سلاسل UTF-8 النصية في تخطيط خيارات RouterInfo في رسالة I2NP Database Store ستتعرض للتلف.

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

• التخطيطات المتضمنة في رسائل I2NP (مثل في RouterAddress أو RouterInfo) يجب أن تكون مرتبة حسب المفتاح بحيث يكون التوقيع ثابتاً. المفاتيح المكررة غير مسموحة.

• التطابقات الموجودة في I2CP SessionConfig يجب أن تُرتب حسب المفتاح بحيث يكون التوقيع ثابتاً. المفاتيح المكررة غير مسموحة.

• يتم تعريف طريقة الترتيب كما في Java String.compareTo()، باستخدام قيمة Unicode للأحرف.

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

• حدود أطوال سلاسل المفتاح والقيمة هي 255 بايت (وليس حرف) لكل منهما، بالإضافة إلى بايت الطول. قد يكون بايت الطول 0.

• حد الطول الإجمالي هو 65535 بايت، بالإضافة إلى حقل الحجم المكون من 2 بايت، أو 65537 إجمالي.

JavaDoc: http://docs.i2p-projekt.de/javadoc/net/i2p/data/DataHelper.html

مواصفات الهيكل المشترك

KeysAndCert

الوصف

مفتاح تشفير عام، ومفتاح توقيع عام، وشهادة، تُستخدم إما كـ RouterIdentity أو Destination.

المحتويات

PublicKey متبوع بـ SigningPublicKey ثم Certificate .

+----+----+----+----+----+----+----+----+
| public_key                            |
+                                       +
|                                       |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| padding (optional)                    |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| signing_key                           |
+                                       +
|                                       |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| certificate                           |
+----+----+----+-/

public_key :: `PublicKey` (partial or full)
              length -> 256 bytes or as specified in key certificate

padding :: random data
           length -> 0 bytes or as specified in key certificate
           public_key length + padding length + signing_key length == 384 bytes

signing__key :: `SigningPublicKey` (partial or full)
                length -> 128 bytes or as specified in key certificate

certificate :: `Certificate`
               length -> >= 3 bytes

total length: 387+ bytes

تم اقتراح هذه الإرشادات في الاقتراح 161 وتم تنفيذها في إصدار API 0.9.57. هذه الإرشادات متوافقة مع الإصدارات السابقة مع جميع الإصدارات منذ 0.6 (2005). راجع الاقتراح 161 للحصول على معلومات أساسية وتفاصيل إضافية.

لأي مجموعة مستخدمة حالياً من أنواع المفاتيح غير ElGamal + DSA-SHA1، ستكون هناك حشوة. بالإضافة إلى ذلك، بالنسبة للوجهات، فإن حقل المفتاح العام بحجم 256 بايت لم يعد مستخدماً منذ الإصدار 0.6 (2005).

يجب على المطورين توليد البيانات العشوائية لمفاتيح Destination العامة، وحشو Destination و Router Identity، بحيث تكون قابلة للضغط في بروتوكولات I2P المختلفة مع الحفاظ على الأمان، ودون أن تبدو تمثيلات Base 64 تالفة أو غير آمنة. هذا يوفر معظم فوائد إزالة حقول الحشو دون أي تغييرات مدمرة في البروتوكول.

بشكل دقيق، فإن مفتاح التوقيع العام المكون من 32 بايت وحده (في كل من Destinations و Router Identities) ومفتاح التشفير العام المكون من 32 بايت (في Router Identities فقط) هو رقم عشوائي يوفر كل الإنتروبيا اللازمة لجعل hashes SHA-256 لهذه الهياكل قوية تشفيرياً وموزعة عشوائياً في DHT قاعدة بيانات الشبكة.

ومع ذلك، من باب الحذر الشديد، نوصي باستخدام حد أدنى 32 بايت من البيانات العشوائية في حقل المفتاح العام ElG والحشو. بالإضافة إلى ذلك، إذا كانت جميع الحقول تحتوي على أصفار، فإن وجهات Base 64 ستحتوي على تسلسلات طويلة من أحرف AAAA، مما قد يسبب القلق أو الالتباس للمستخدمين.

كرر الـ 32 بايت من البيانات العشوائية حسب الحاجة بحيث يكون هيكل KeysAndCert الكامل قابلاً للضغط بدرجة عالية في بروتوكولات I2P مثل I2NP Database Store Message و Streaming SYN و SSU2 handshake و repliable Datagrams.

أمثلة:

• هوية Router مع نوع تشفير X25519 ونوع توقيع Ed25519 ستحتوي على 10 نسخ (320 بايت) من البيانات العشوائية، لتوفير حوالي 288 بايت عند الضغط.

• وجهة بنوع توقيع Ed25519 ستحتوي على 11 نسخة (352 بايت) من البيانات العشوائية، مما يوفر حوالي 320 بايت عند الضغط.

يجب على التطبيقات، بطبيعة الحال، تخزين الهيكل الكامل المكون من 387+ بايت لأن hash SHA-256 للهيكل يغطي المحتويات الكاملة.

ملاحظات

• لا تفترض أن هذه دائماً 387 بايت! إنها 387 بايت بالإضافة إلى طول الشهادة المحدد في البايتات 385-386، والذي قد يكون غير صفر.

• اعتباراً من الإصدار 0.9.12، إذا كانت الشهادة هي Key Certificate، فقد تختلف حدود حقول المفاتيح. راجع قسم Key Certificate أعلاه للتفاصيل.

• يتم محاذاة المفتاح العام للتشفير في البداية ويتم محاذاة المفتاح العام للتوقيع في النهاية. الحشو (إن وجد) يكون في المنتصف.

JavaDoc: http://docs.i2p-projekt.de/javadoc/net/i2p/data/KeysAndCert.html

RouterIdentity

الوصف

يحدد الطريقة لتعريف router معين بشكل فريد

المحتويات

مطابق لـ KeysAndCert.

انظر KeysAndCert للحصول على إرشادات حول إنتاج البيانات العشوائية لحقل الحشو.

ملاحظات

• كان الشهادة لـ RouterIdentity دائماً NULL حتى الإصدار 0.9.12.

• لا تفترض أن هذه دائماً 387 بايت! إنها 387 بايت بالإضافة إلى طول الشهادة المحدد في البايتات 385-386، والذي قد يكون غير صفري.

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

• المفتاح العام للتشفير محاذي في البداية والمفتاح العام للتوقيع محاذي في النهاية. الحشو (إن وجد) يكون في المنتصف.

• RouterIdentities مع شهادة مفتاح ومفتاح عام ECIES_X25519 مدعومة اعتباراً من الإصدار 0.9.48. قبل ذلك، كانت جميع RouterIdentities من نوع ElGamal.

JavaDoc: http://docs.i2p-projekt.de/javadoc/net/i2p/data/router/RouterIdentity.html

الوجهة

الوصف

يُعرّف الـ Destination نقطة نهاية معينة يمكن توجيه الرسائل إليها للتسليم الآمن.

المحتويات

مطابق لـ KeysAndCert ، باستثناء أن المفتاح العام لا يُستخدم أبداً، وقد يحتوي على بيانات عشوائية بدلاً من مفتاح ElGamal عام صحيح.

انظر KeysAndCert للحصول على إرشادات حول توليد البيانات العشوائية لحقول المفتاح العام والحشو.

ملاحظات

• تم استخدام المفتاح العام للوجهة في التشفير القديم من i2cp إلى i2cp والذي تم تعطيله في الإصدار 0.6 (2005)، وهو حالياً غير مستخدم باستثناء IV لتشفير LeaseSet، والذي أصبح مهجوراً. يتم استخدام المفتاح العام في LeaseSet بدلاً من ذلك.

• لا تفترض أن هذه دائماً 387 بايت! إنها 387 بايت بالإضافة إلى طول الشهادة المحدد في البايتات 385-386، والذي قد يكون غير صفر.

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

• المفتاح العام للتشفير محاذٍ في البداية والمفتاح العام للتوقيع محاذٍ في النهاية. الحشو (إن وُجد) يكون في المنتصف.

JavaDoc: http://docs.i2p-projekt.de/javadoc/net/i2p/data/Destination.html

عقد الإيجار

الوصف

يُعرّف التفويض لنفق معين لاستقبال الرسائل المستهدفة إلى Destination .

المحتويات

SHA256 Hash لـ RouterIdentity الخاص بـ router البوابة، ثم TunnelId ، وأخيراً Date النهاية.

+----+----+----+----+----+----+----+----+
| tunnel_gw                             |
+                                       +
|                                       |
+                                       +
|                                       |
+                                       +
|                                       |
+----+----+----+----+----+----+----+----+
|     tunnel_id     |      end_date
+----+----+----+----+----+----+----+----+
                    |
+----+----+----+----+

tunnel_gw :: Hash of the `RouterIdentity` of the tunnel gateway
             length -> 32 bytes

tunnel_id :: `TunnelId`
             length -> 4 bytes

end_date :: `Date`
            length -> 8 bytes

LeaseSet

الوصف

يحتوي على جميع عقود الإيجار (Leases ) المصرح بها حاليًا لوجهة (Destination ) معينة، والمفتاح العام الذي يمكن تشفير رسائل garlic إليه، ثم مفتاح التوقيع العام الذي يمكن استخدامه لإلغاء هذا الإصدار المحدد من البنية. إن LeaseSet هو واحد من البنيتين المخزونتين في قاعدة بيانات الشبكة (الأخرى هي RouterInfo )، ويتم فهرسته تحت SHA256 للوجهة (Destination ) المحتواة.

المحتويات

Destination ، متبوعًا بـ PublicKey للتشفير، ثم SigningPublicKey والذي يمكن استخدامه لإلغاء هذا الإصدار من LeaseSet، ثم 1 بايت Integer يحدد كم عدد هياكل Lease الموجودة في المجموعة، متبوعة بهياكل Lease الفعلية وأخيرًا Signature للبايتات السابقة موقعة بواسطة SigningPrivateKey الخاص بـ Destination .

+----+----+----+----+----+----+----+----+
| destination                           |
+                                       +
|                                       |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| encryption_key                        |
+                                       +
|                                       |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| signing_key                           |
+                                       +
|                                       |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| num| Lease 0                          |
+----+                                  +
|                                       |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| Lease 1                               |
+                                       +
|                                       |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| Lease ($num-1)                        |
+                                       +
|                                       |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| signature                             |
+                                       +
|                                       |
+                                       +
|                                       |
+                                       +
|                                       |
+                                       +
|                                       |
+----+----+----+----+----+----+----+----+

destination :: `Destination`
               length -> >= 387+ bytes

encryption_key :: `PublicKey`
                  length -> 256 bytes

signing_key :: `SigningPublicKey`
               length -> 128 bytes or as specified in destination's key
                         certificate

num :: `Integer`
       length -> 1 byte
       Number of leases to follow
       value: 0 <= num <= 16

leases :: [`Lease`]
          length -> $num*44 bytes

signature :: `Signature`
             length -> 40 bytes or as specified in destination's key
                       certificate

• تم استخدام المفتاح العام للوجهة في التشفير القديم من I2CP إلى I2CP والذي تم تعطيله في الإصدار 0.6، وهو حالياً غير مستخدم.

• يتم استخدام مفتاح التشفير للتشفير الشامل من طرف إلى طرف ElGamal/AES+SessionTag ELGAMAL-AES . يتم حالياً إنشاؤه من جديد عند كل بدء تشغيل للموجه، وهو غير مستمر.

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

• يُسمح بـ LeaseSet بدون أي Leases ولكنه غير مستخدم. كان مخصصاً لإلغاء LeaseSet، والذي لم يتم تنفيذه. جميع متغيرات LeaseSet2 تتطلب Lease واحد على الأقل.

• إن signing_key غير مستخدم حالياً. كان مخصصاً لإلغاء LeaseSet، والذي لم يتم تنفيذه. يتم حالياً إنشاؤه من جديد عند كل بدء تشغيل للـ router، وهو غير دائم. نوع signing key هو دائماً نفس نوع signing key الخاص بالوجهة.

• يتم التعامل مع أقرب انتهاء صلاحية لجميع الـ Leases كطابع زمني أو إصدار للـ LeaseSet. عموماً لن تقبل الـ routers تخزين LeaseSet ما لم يكن “أحدث” من النسخة الحالية. توخ الحذر عند نشر LeaseSet جديد حيث يكون أقدم Lease هو نفسه أقدم Lease في الـ LeaseSet السابق. يجب على الـ router الناشر عموماً زيادة انتهاء صلاحية أقدم Lease بما لا يقل عن 1 ميللي ثانية في تلك الحالة.

• قبل الإصدار 0.9.7، عندما يتم تضمينه في رسالة DatabaseStore المرسلة من router المصدر، كان router يعيّن جميع انتهاء صلاحيات leases المنشورة لنفس القيمة، وهي قيمة أقدم lease. اعتباراً من الإصدار 0.9.7، ينشر router انتهاء الصلاحية الفعلي لكل lease. هذا تفصيل تنفيذي وليس جزءاً من مواصفات الهياكل.

JavaDoc: http://docs.i2p-projekt.de/javadoc/net/i2p/data/LeaseSet.html

Lease2

الوصف

يحدد التفويض لنفق معين لاستقبال الرسائل المستهدفة لـ Destination . مماثل لـ Lease ولكن مع end_date من 4 بايت. يُستخدم بواسطة LeaseSet2 . مدعوم اعتباراً من الإصدار 0.9.38؛ راجع المقترح 123 للمزيد من المعلومات.

المحتويات

SHA256 Hash لـ RouterIdentity الخاص بـ router البوابة، ثم TunnelId ، وأخيراً تاريخ انتهاء من 4 بايت.

+----+----+----+----+----+----+----+----+
| tunnel_gw                             |
+                                       +
|                                       |
+                                       +
|                                       |
+                                       +
|                                       |
+----+----+----+----+----+----+----+----+
|     tunnel_id     |      end_date     |
+----+----+----+----+----+----+----+----+

tunnel_gw :: Hash of the `RouterIdentity` of the tunnel gateway
             length -> 32 bytes

tunnel_id :: `TunnelId`
             length -> 4 bytes

end_date :: 4 byte date
            length -> 4 bytes
            Seconds since the epoch, rolls over in 2106.

• الحجم الإجمالي: 40 بايت

JavaDoc: http://docs.i2p-projekt.de/javadoc/net/i2p/data/Lease2.html

التوقيع دون اتصال

الوصف

هذا جزء اختياري من LeaseSet2Header . يُستخدم أيضاً في streaming و I2CP. مدعوم اعتباراً من الإصدار 0.9.38؛ راجع الاقتراح 123 لمزيد من المعلومات.

المحتويات

يحتوي على انتهاء صلاحية، ونوع توقيع وSigningPublicKey مؤقت، وSignature .

+----+----+----+----+----+----+----+----+
|     expires       | sigtype |         |
+----+----+----+----+----+----+         +
|       transient_public_key            |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
|           signature                   |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+

expires :: 4 byte date
           length -> 4 bytes
           Seconds since the epoch, rolls over in 2106.

sigtype :: 2 byte type of the transient_public_key
           length -> 2 bytes

transient_public_key :: `SigningPublicKey`
                        length -> As inferred from the sigtype

signature :: `Signature`
             length -> As inferred from the sigtype of the signing public key
                       in the `Destination` that preceded this offline signature.
             Signature of expires timestamp, transient sig type, and public key,
             by the destination public key.

• يمكن، بل ويجب، إنشاء هذا القسم في وضع عدم الاتصال.

LeaseSet2Header

الوصف

هذا هو الجزء المشترك من LeaseSet2 و MetaLeaseSet . مدعوم اعتبارًا من الإصدار 0.9.38؛ راجع المقترح 123 لمزيد من المعلومات.

المحتويات

يحتوي على Destination ، وطابعين زمنيين، وOfflineSignature اختياري.

+----+----+----+----+----+----+----+----+
| destination                           |
+                                       +
|                                       |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
|     published     | expires |  flags  |
+----+----+----+----+----+----+----+----+
| offline_signature (optional)          |
+                                       +
|                                       |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+

destination :: `Destination`
               length -> >= 387+ bytes

published :: 4 byte date
             length -> 4 bytes
             Seconds since the epoch, rolls over in 2106.

expires :: 2 byte time
           length -> 2 bytes
           Offset from published timestamp in seconds, 18.2 hours max

flags :: 2 bytes
  Bit order: 15 14 ... 3 2 1 0
  Bit 0: If 0, no offline keys; if 1, offline keys
  Bit 1: If 0, a standard published leaseset.
         If 1, an unpublished leaseset.
  Bit 2: If 0, a standard published leaseset.
         If 1, this unencrypted leaseset will be blinded and encrypted when published.
  Bits 15-3: set to 0 for compatibility with future uses

offline_signature :: `OfflineSignature`
                     length -> varies
                     Optional, only present if bit 0 is set in the flags.

• الأعلام (2 بايت):

  • البت 0: إذا تم تعيينه، فإن المفاتيح غير المتصلة موجودة (انظر OfflineSignature )
  • البت 1: إذا تم تعيينه، فهذا leaseSet غير منشور
  • البت 2: إذا تم تعيينه، فهذا leaseSet مُعمى
  • البتات 15-3: محجوزة، يتم تعيينها إلى 0

• الحجم الإجمالي: 395 بايت كحد أدنى

• الحد الأقصى الفعلي لوقت انتهاء الصلاحية هو حوالي 660 (11 دقيقة) لـ LeaseSet2 و 65535 (18.2 ساعة كاملة) لـ MetaLeaseSet .

• LeaseSet (1) لم يكن لديه حقل ‘published’، لذلك تطلب إصدار النسخ البحث عن أقدم lease. يضيف LeaseSet2 حقل ‘published’ بدقة ثانية واحدة. يجب على الـ routers تحديد معدل إرسال leasesets جديدة إلى floodfills بمعدل أبطأ بكثير من مرة واحدة في الثانية (لكل وجهة). إذا لم يتم تطبيق هذا، فيجب على الكود التأكد من أن كل leaseset جديد لديه وقت ‘published’ متأخر ثانية واحدة على الأقل عن السابق، وإلا فإن floodfills لن تقوم بتخزين أو إغراق الـ leaseset الجديد.

LeaseSet2

الوصف

متضمن في رسالة I2NP DatabaseStore من النوع 3. مدعوم اعتباراً من الإصدار 0.9.38؛ راجع المقترح 123 للمزيد من المعلومات.

يحتوي على جميع Lease2 المعتمدة حالياً لـ Destination معين، وPublicKey التي يمكن تشفير رسائل garlic إليها. LeaseSet هو أحد الهيكلين المخزنين في قاعدة بيانات الشبكة (والآخر هو RouterInfo )، ويتم فهرسته تحت SHA256 للـ Destination المحتوى.

المحتويات

LeaseSet2Header ، متبوعاً بخيارات، ثم واحد أو أكثر من PublicKey للتشفير، Integer يحدد كم عدد هياكل Lease2 في المجموعة، متبوعاً بهياكل Lease2 الفعلية وأخيراً Signature للبايتات السابقة موقعة بواسطة SigningPrivateKey الخاص بـ Destination أو المفتاح المؤقت.

+----+----+----+----+----+----+----+----+
|         ls2_header                    |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
|          options                      |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
|numk| keytype0| keylen0 |              |
+----+----+----+----+----+              +
|          encryption_key_0             |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| keytypen| keylenn |                   |
+----+----+----+----+                   +
|          encryption_key_n             |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| num| Lease2 0                         |
+----+                                  +
|                                       |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| Lease2($num-1)                        |
+                                       +
|                                       |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| signature                             |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+

ls2header :: `LeaseSet2Header`
             length -> varies

options :: `Mapping`
           length -> varies, 2 bytes minimum

numk :: `Integer`
        length -> 1 byte
        Number of key types, key lengths, and `PublicKey`s to follow
        value: 1 <= numk <= max TBD

keytype :: The encryption type of the `PublicKey` to follow.
           length -> 2 bytes

keylen :: The length of the `PublicKey` to follow.
          Must match the specified length of the encryption type.
          length -> 2 bytes

encryption_key :: `PublicKey`
                  length -> keylen bytes

num :: `Integer`
       length -> 1 byte
       Number of `Lease2`s to follow
       value: 0 <= num <= 16

leases :: [`Lease2`]
          length -> $num*40 bytes

signature :: `Signature`
             length -> 40 bytes or as specified in destination's key
                       certificate, or by the sigtype of the transient public key,
                       if present in the header

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

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

ترتيب المفاتيح في leasesets غير المنشورة (العميل) لا يهم فعليًا، لأن الاتصالات عادة لن تُحاول مع العملاء غير المنشورين. ما لم يُستخدم هذا الترتيب لتحديد تفضيل مدمج، كما هو موضح أعلاه.

الخيارات

اعتباراً من API 0.9.66، تم تحديد تنسيق معياري لخيارات سجل الخدمة. راجع الاقتراح 167 للتفاصيل. قد يتم تحديد خيارات أخرى غير سجلات الخدمة، باستخدام تنسيق مختلف، في المستقبل.

يجب ترتيب خيارات LS2 حسب المفتاح، بحيث يكون التوقيع ثابتاً.

خيارات سجل الخدمة محددة كما يلي:

• serviceoption := optionkey optionvalue
• optionkey := _service._proto
• service := الاسم الرمزي للخدمة المطلوبة. يجب أن يكون بأحرف صغيرة. مثال: “smtp”. الأحرف المسموحة هي [a-z0-9-] ويجب ألا تبدأ أو تنتهي بـ ‘-’. يجب استخدام المعرفات القياسية من REGISTRY أو Linux /etc/services إذا كانت معرفة هناك.
• proto := بروتوكول النقل للخدمة المطلوبة. يجب أن يكون بأحرف صغيرة، إما “tcp” أو “udp”. “tcp” يعني التدفق و “udp” يعني البيانات القابلة للرد. قد يتم تعريف مؤشرات البروتوكول للبيانات الخام و datagram2 لاحقاً. الأحرف المسموحة هي [a-z0-9-] ويجب ألا تبدأ أو تنتهي بـ ‘-’.
• optionvalue := self | srvrecord[,srvrecord]*
• self := “0” ttl port [appoptions]
• srvrecord := “1” ttl priority weight port target [appoptions]
• ttl := وقت البقاء، ثواني صحيحة. عدد صحيح موجب. مثال: “86400”. يُوصى بحد أدنى 86400 (يوم واحد)، راجع قسم التوصيات أدناه للتفاصيل.
• priority := أولوية المضيف المستهدف، القيمة الأقل تعني الأفضلية الأكبر. عدد صحيح غير سالب. مثال: “0” مفيد فقط إذا كان هناك أكثر من سجل واحد، لكنه مطلوب حتى لو كان سجل واحد فقط.
• weight := وزن نسبي للسجلات ذات الأولوية نفسها. القيمة الأعلى تعني فرصة أكبر للاختيار. عدد صحيح غير سالب. مثال: “0” مفيد فقط إذا كان هناك أكثر من سجل واحد، لكنه مطلوب حتى لو كان سجل واحد فقط.
• port := منفذ I2CP الذي يمكن العثور على الخدمة عليه. عدد صحيح غير سالب. مثال: “25” المنفذ 0 مدعوم لكن غير مُوصى به.
• target := اسم المضيف أو b32 للوجهة التي توفر الخدمة. اسم مضيف صالح كما في NAMING . يجب أن يكون بأحرف صغيرة. مثال: “aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.b32.i2p” أو “example.i2p”. يُوصى بـ b32 ما لم يكن اسم المضيف “معروفاً جيداً”، أي في كتب العناوين الرسمية أو الافتراضية.
• appoptions := نص تعسفي خاص بالتطبيق، يجب ألا يحتوي على " " أو “,”. الترميز هو UTF-8.

أمثلة:

في LS2 لـ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.b32.i2p، يشير إلى خادم SMTP واحد:

“_smtp._tcp” “1 86400 0 0 25 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb.b32.i2p”

في LS2 لـ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.b32.i2p، يشير إلى خادمي SMTP:

“_smtp._tcp” “1 86400 0 0 25 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb.b32.i2p,86400 1 0 25 cccccccccccccccccccccccccccccccccccccccccccc.b32.i2p”

في LS2 لـ bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb.b32.i2p، يشير إلى نفسه كخادم SMTP:

“_smtp._tcp” “0 999999 25”

ملاحظات

• تم استخدام المفتاح العام للوجهة في التشفير القديم من I2CP إلى I2CP والذي تم تعطيله في الإصدار 0.6، وهو حالياً غير مستخدم.

• تُستخدم مفاتيح التشفير للتشفير من طرف إلى طرف ElGamal/AES+SessionTag ELGAMAL-AES (النوع 0) أو مخططات التشفير الأخرى من طرف إلى طرف. انظر ECIES والاقتراحين 145 و156. يمكن إنشاؤها من جديد عند كل بدء تشغيل للrouter أو يمكن أن تكون دائمة. X25519 (النوع 4، انظر ECIES ) مدعوم اعتباراً من الإصدار 0.9.44.

• التوقيع يغطي البيانات أعلاه، مُسبوقة بالبايت الواحد الذي يحتوي على نوع DatabaseStore (3).

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

• يتم توفير طول المفتاح لكل مفتاح، بحيث يمكن لـ floodfills والعملاء تحليل البنية حتى لو لم تكن جميع أنواع التشفير معروفة أو مدعومة.

• انظر الملاحظة حول حقل ‘published’ في LeaseSet2Header

• تطبيق الخيارات، إذا كان الحجم أكبر من واحد، يجب أن يكون مرتباً حسب المفتاح، بحيث يكون التوقيع ثابتاً.

JavaDoc: http://docs.i2p-projekt.de/javadoc/net/i2p/data/LeaseSet2.html

MetaLease

الوصف

يحدد التفويض لـ tunnel معين لتلقي الرسائل المستهدفة لـ Destination . نفس Lease2 ولكن مع العلامات والتكلفة بدلاً من معرف الـ tunnel. يُستخدم بواسطة MetaLeaseSet . محتوى في رسالة I2NP DatabaseStore من النوع 7. مدعوم اعتباراً من الإصدار 0.9.38؛ انظر المقترح 123 لمزيد من المعلومات.

المحتويات

Hash SHA256 لـ RouterIdentity الخاص بـ gateway router، ثم flags والتكلفة، وأخيراً تاريخ انتهاء من 4 بايت.

+----+----+----+----+----+----+----+----+
| tunnel_gw                             |
+                                       +
|                                       |
+                                       +
|                                       |
+                                       +
|                                       |
+----+----+----+----+----+----+----+----+
|    flags     |cost|      end_date     |
+----+----+----+----+----+----+----+----+

tunnel_gw :: Hash of the `RouterIdentity` of the tunnel gateway,
             or the hash of another `MetaLeaseSet`.
             length -> 32 bytes

flags :: 3 bytes of flags
         Bit order: 23 22 ... 3 2 1 0
         Bits 3-0: Type of the entry.
         If 0, unknown.
         If 1, a `LeaseSet`.
         If 3, a `LeaseSet2`.
         If 5, a `MetaLeaseSet`.
         Bits 23-4: set to 0 for compatibility with future uses
         length -> 3 bytes

cost :: 1 byte, 0-255. Lower value is higher priority.
        length -> 1 byte

end_date :: 4 byte date
            length -> 4 bytes
            Seconds since the epoch, rolls over in 2106.

ملاحظات

• الحجم الإجمالي: 40 بايت

JavaDoc: http://docs.i2p-projekt.de/javadoc/net/i2p/data/MetaLease.html

MetaLeaseSet

الوصف

موجود في رسالة I2NP DatabaseStore من النوع 7. تم تعريفه اعتباراً من الإصدار 0.9.38؛ ومجدول للعمل اعتباراً من الإصدار 0.9.40؛ انظر الاقتراح 123 لمزيد من المعلومات.

يحتوي على جميع MetaLease المعتمدة حاليًا لـ Destination معين، وPublicKey التي يمكن تشفير رسائل garlic إليها. LeaseSet هو أحد البنيتين المخزنتين في قاعدة بيانات الشبكة (والأخرى هي RouterInfo )، ويتم فهرسته تحت SHA256 الخاص بـ Destination المتضمن.

المحتويات

LeaseSet2Header ، متبوعًا بالخيارات، Integer يحدد عدد هياكل Lease2 الموجودة في المجموعة، متبوعًا بهياكل Lease2 الفعلية وأخيرًا Signature للبايتات السابقة موقعة بواسطة SigningPrivateKey الخاص بـ Destination أو المفتاح المؤقت.

+----+----+----+----+----+----+----+----+
|         ls2_header                    |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
|          options                      |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| num| MetaLease 0                      |
+----+                                  +
|                                       |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| MetaLease($num-1)                     |
+                                       +
|                                       |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
|numr|                                  |
+----+                                  +
|          revocation_0                 |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
|          revocation_n                 |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| signature                             |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+

ls2header :: `LeaseSet2Header`
             length -> varies

options :: `Mapping`
           length -> varies, 2 bytes minimum

num :: `Integer`
        length -> 1 byte
        Number of `MetaLease`s to follow
        value: 1 <= num <= max TBD

leases :: `MetaLease`s
          length -> $numr*40 bytes

numr :: `Integer`
        length -> 1 byte
        Number of `Hash`es to follow
        value: 0 <= numr <= max TBD

revocations :: [`Hash`]
               length -> $numr*32 bytes

signature :: `Signature`
             length -> 40 bytes or as specified in destination's key
                       certificate, or by the sigtype of the transient public key,
                       if present in the header

ملاحظات

• تم استخدام المفتاح العام للوجهة للتشفير القديم من I2CP إلى I2CP الذي تم تعطيله في الإصدار 0.6، وهو حالياً غير مستخدم.

• التوقيع يكون على البيانات أعلاه، مع إضافة البايت الواحد الذي يحتوي على نوع DatabaseStore (7) في المقدمة.

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

• انظر الملاحظة حول حقل ‘published’ في LeaseSet2Header

JavaDoc: http://docs.i2p-projekt.de/javadoc/net/i2p/data/MetaLeaseSet.html

EncryptedLeaseSet

الوصف

موجود في رسالة I2NP DatabaseStore من النوع 5. تم تعريفه اعتباراً من الإصدار 0.9.38؛ يعمل اعتباراً من الإصدار 0.9.39؛ راجع الاقتراح 123 للمزيد من المعلومات.

فقط المفتاح المُعمى وتاريخ انتهاء الصلاحية مرئيان كنص واضح. أما leaseSet الفعلي فهو مُشفر.

المحتويات

نوع توقيع من بايتين، SigningPrivateKey المُعمى، وقت النشر، انتهاء الصلاحية، والأعلام. ثم، طول من بايتين متبوعًا ببيانات مُشفرة. وأخيرًا، Signature للبايتات السابقة موقعة بواسطة SigningPrivateKey المُعمى أو المفتاح المؤقت.

+----+----+----+----+----+----+----+----+
| sigtype |                             |
+----+----+                             +
|        blinded_public_key             |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
|     published     | expires |  flags  |
+----+----+----+----+----+----+----+----+
| offline_signature (optional)          |
+                                       +
|                                       |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
|  len    |                             |
+----+----+                             +
|         encrypted_data                |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| signature                             |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+

sigtype :: A two byte signature type of the public key to follow
           length -> 2 bytes

blinded_public_key :: `SigningPublicKey`
                      length -> As inferred from the sigtype

published :: 4 byte date
             length -> 4 bytes
             Seconds since the epoch, rolls over in 2106.

expires :: 2 byte time
           length -> 2 bytes
           Offset from published timestamp in seconds, 18.2 hours max

flags :: 2 bytes
  Bit order: 15 14 ... 3 2 1 0
  Bit 0: If 0, no offline keys; if 1, offline keys
  Bit 1: If 0, a standard published leaseset.
         If 1, an unpublished leaseset. Should not be flooded, published, or
         sent in response to a query. If this leaseset expires, do not query the
         netdb for a new one.
  Bits 15-2: set to 0 for compatibility with future uses

offline_signature :: `OfflineSignature`
                     length -> varies
                     Optional, only present if bit 0 is set in the flags.

len :: `Integer`
        length -> 2 bytes
        length of encrypted_data to follow
        value: 1 <= num <= max TBD

encrypted_data :: Data encrypted
                  length -> len bytes

signature :: `Signature`
             length -> As specified by the sigtype of the blinded pubic key,
                       or by the sigtype of the transient public key,
                       if present in the header

ملاحظات

• المفتاح العام للوجهة كان يُستخدم لتشفير I2CP-to-I2CP القديم الذي تم تعطيله في الإصدار 0.6، وهو غير مستخدم حالياً.

• التوقيع يكون على البيانات أعلاه، مُسبوقة بالبايت الواحد الذي يحتوي على نوع DatabaseStore (5).

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

• التعمية والتشفير محددان في EncryptedLeaseSet

• هذا الهيكل لا يستخدم LeaseSet2Header .

• الحد الأقصى للوقت الفعلي للانتهاء هو حوالي 660 (11 دقيقة)، إلا إذا كان MetaLeaseSet مشفراً.

• انظر الاقتراح 123 للحصول على ملاحظات حول استخدام التوقيعات غير المتصلة مع leasesets المشفرة.

• انظر الملاحظة حول حقل ‘published’ في LeaseSet2Header (نفس المشكلة، حتى لو أننا لا نستخدم تنسيق LeaseSet2Header هنا)

JavaDoc: http://docs.i2p-projekt.de/javadoc/net/i2p/data/EncryptedLeaseSet.html

RouterAddress

الوصف

تحدد هذه البنية وسائل الاتصال مع router من خلال بروتوكول النقل.

المحتويات

1 بايت Integer يحدد التكلفة النسبية لاستخدام العنوان، حيث 0 يعني مجاني و 255 يعني مكلف، متبوعًا بتاريخ انتهاء الصلاحية Date الذي بعده يجب عدم استخدام العنوان، أو إذا كان فارغًا، فإن العنوان لا ينتهي أبدًا. بعد ذلك يأتي String يحدد بروتوكول النقل الذي يستخدمه عنوان router هذا. وأخيرًا يوجد Mapping يحتوي على جميع الخيارات المحددة للنقل اللازمة لإنشاء الاتصال، مثل عنوان IP ورقم المنفذ وعنوان البريد الإلكتروني وURL، إلخ.

+----+----+----+----+----+----+----+----+
|cost|           expiration
+----+----+----+----+----+----+----+----+
     |        transport_style           |
+----+----+----+----+-/-+----+----+----+
|                                       |
+                                       +
|               options                 |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+

cost :: `Integer`
        length -> 1 byte

        case 0 -> free
        case 255 -> expensive

expiration :: `Date` (must be all zeros, see notes below)
              length -> 8 bytes

              case null -> never expires

transport_style :: `String`
                   length -> 1-256 bytes

options :: `Mapping`

ملاحظات

• التكلفة عادة ما تكون 5 أو 6 لـ SSU، و 10 أو 11 لـ NTCP.

• انتهاء الصلاحية غير مستخدم حالياً، دائماً null (جميع الأصفار). اعتباراً من الإصدار 0.9.3، يُفترض أن انتهاء الصلاحية صفر ولا يتم تخزينه، لذا أي انتهاء صلاحية غير صفري سيفشل في التحقق من توقيع RouterInfo. تنفيذ انتهاء الصلاحية (أو استخدام آخر لهذه البايتات) سيكون تغييراً غير متوافق مع الإصدارات السابقة. يجب على الـ routers تعيين هذا الحقل إلى جميع الأصفار. اعتباراً من الإصدار 0.9.12، يتم التعرف على حقل انتهاء الصلاحية غير الصفري مرة أخرى، ومع ذلك يجب أن ننتظر عدة إصدارات لاستخدام هذا الحقل، حتى تتعرف عليه الغالبية العظمى من الشبكة.

• الخيارات التالية، رغم أنها غير مطلوبة، إلا أنها معيارية ومتوقع وجودها في معظم عناوين الـ router: “host” (عنوان IPv4 أو IPv6 أو اسم المضيف) و “port”.

JavaDoc: http://docs.i2p-projekt.de/javadoc/net/i2p/data/router/RouterAddress.html

RouterInfo

الوصف

يحدد جميع البيانات التي يريد router نشرها ليراها الشبكة. RouterInfo هو أحد البنيتين المخزنتين في قاعدة بيانات الشبكة (والأخرى هي LeaseSet )، ويتم فهرسته تحت SHA256 للـ RouterIdentity المحتوى.

المحتويات

RouterIdentity متبوعة بـ Date ، عندما تم نشر الإدخال

+----+----+----+----+----+----+----+----+
| router_ident                          |
+                                       +
|                                       |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| published                             |
+----+----+----+----+----+----+----+----+
|size| RouterAddress 0                  |
+----+                                  +
|                                       |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| RouterAddress 1                       |
+                                       +
|                                       |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| RouterAddress ($size-1)               |
+                                       +
|                                       |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+-/-+----+----+----+
|psiz| options                          |
+----+----+----+----+-/-+----+----+----+
| signature                             |
+                                       +
|                                       |
+                                       +
|                                       |
+                                       +
|                                       |
+                                       +
|                                       |
+----+----+----+----+----+----+----+----+

router_ident :: `RouterIdentity`
                length -> >= 387+ bytes

published :: `Date`
             length -> 8 bytes

size :: `Integer`
        length -> 1 byte
        The number of `RouterAddress`es to follow, 0-255

addresses :: [`RouterAddress`]
             length -> varies

peer_size :: `Integer`
             length -> 1 byte
             The number of peer `Hash`es to follow, 0-255, unused, always zero
             value -> 0

options :: `Mapping`

signature :: `Signature`
             length -> 40 bytes or as specified in router_ident's key
                       certificate

ملاحظات

• قد يتبع peer_size Integer قائمة تحتوي على عدد مماثل من hash قيم router. هذا غير مستخدم حاليًا. كان مخصصًا لشكل من أشكال المسارات المقيدة، والذي لم يتم تنفيذه. قد تتطلب تنفيذات معينة أن تكون القائمة مرتبة بحيث يكون التوقيع ثابتًا. يجب البحث في هذا قبل تمكين هذه الميزة.

• يمكن التحقق من التوقيع باستخدام المفتاح العام للتوقيع الخاص بـ router_ident.

• انظر صفحة قاعدة بيانات الشبكة NETDB-ROUTERINFO للاطلاع على الخيارات القياسية المتوقع وجودها في جميع معلومات router.

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

JavaDoc: http://docs.i2p-projekt.de/javadoc/net/i2p/data/router/RouterInfo.html

تعليمات التسليم

تعليمات تسليم رسائل الأنفاق معرّفة في مواصفات رسائل الأنفاق TUNNEL-DELIVERY .

يتم تعريف تعليمات تسليم رسائل Garlic في مواصفات رسائل I2NP GARLIC-DELIVERY .

المراجع

• ECIES
• ECIES-HYBRID
• ECIES-ROUTERS
• ELGAMAL
• ELGAMAL-AES
• GARLIC-DELIVERY
• I2CP
• I2NP
• NAMING
• NETDB-ROUTERINFO
• Prop134
• Prop169
• REGISTRY
• SSU
• TUNNEL-DELIVERY