نظرة عامة
يتم استخدام ElGamal/AES+SessionTags للتشفير من طرف إلى طرف.
كنظام غير موثوق وغير مرتب يعتمد على الرسائل، يستخدم I2P مزيجاً بسيطاً من خوارزميات التشفير غير المتماثل والمتماثل لتوفير سرية وسلامة البيانات لرسائل garlic. كمجموعة كاملة، يُشار إلى هذا المزيج باسم ElGamal/AES+SessionTags، لكن هذا وصف مفرط في الإطالة لوصف استخدام ElGamal بـ 2048 بت، وAES256، وSHA256، ونونسات (nonces) بـ 32 بايت.
في المرة الأولى التي يريد فيها router تشفير رسالة garlic إلى router آخر، يقوم بتشفير مواد المفاتيح لمفتاح جلسة AES256 باستخدام ElGamal ويلحق الحمولة المشفرة بـ AES256/CBC بعد ذلك الكتلة المشفرة بـ ElGamal. بالإضافة إلى الحمولة المشفرة، يحتوي القسم المشفر بـ AES على طول الحمولة، وتجزئة SHA256 للحمولة غير المشفرة، بالإضافة إلى عدد من “علامات الجلسة” - وهي nonces عشوائية بحجم 32 بايت. في المرة التالية التي يريد فيها المرسل تشفير رسالة garlic إلى router آخر، بدلاً من تشفير مفتاح جلسة جديد بـ ElGamal، يقوم ببساطة باختيار إحدى علامات الجلسة المسلمة مسبقاً ويشفر الحمولة بـ AES كما هو الحال من قبل، باستخدام مفتاح الجلسة المستخدم مع تلك علامة الجلسة، مسبوقاً بعلامة الجلسة نفسها. عندما يستقبل router رسالة مشفرة بـ garlic، يتحقق من الـ 32 بايت الأولى لمعرفة ما إذا كانت تطابق علامة جلسة متاحة - إذا كانت كذلك، يقوم ببساطة بفك تشفير الرسالة بـ AES، ولكن إذا لم تكن كذلك، يقوم بفك تشفير الكتلة الأولى بـ ElGamal.
يمكن استخدام كل session tag مرة واحدة فقط لمنع الخصوم الداخليين من ربط الرسائل المختلفة بلا داع على أنها بين نفس routers. يختار مرسل الرسالة المشفرة بـ ElGamal/AES+SessionTag متى وكم عدد العلامات التي سيتم تسليمها، مما يؤمن للمستقبِل مخزوناً كافياً من العلامات لتغطية وابل من الرسائل. قد تكتشف رسائل garlic نجاح تسليم العلامة من خلال تجميع رسالة إضافية صغيرة كـ clove (“رسالة حالة التسليم”) - عندما تصل رسالة garlic إلى المستقبِل المقصود ويتم فك تشفيرها بنجاح، تكون رسالة حالة التسليم الصغيرة هذه واحدة من cloves المكشوفة وتحتوي على تعليمات للمستقبِل لإرسال clove مرة أخرى إلى المرسل الأصلي (عبر inbound tunnel طبعاً). عندما يتلقى المرسل الأصلي رسالة حالة التسليم هذه، يعرف أن session tags المجمعة في رسالة garlic تم تسليمها بنجاح.
علامات الجلسة نفسها لها عمر قصير، وبعدها يتم التخلص منها إذا لم يتم استخدامها. بالإضافة إلى ذلك، الكمية المخزنة لكل مفتاح محدودة، كما هو الحال مع عدد المفاتيح نفسها - إذا وصل عدد كبير جداً منها، قد يتم إسقاط الرسائل الجديدة أو القديمة. المرسل يتتبع ما إذا كانت الرسائل التي تستخدم علامات الجلسة تصل بنجاح، وإذا لم يكن هناك تواصل كافٍ قد يسقط تلك التي كان يفترض سابقاً أنها تم تسليمها بشكل صحيح، والعودة إلى تشفير ElGamal الكامل والمكلف. ستستمر الجلسة في الوجود حتى يتم استنفاد جميع علاماتها أو تنتهي صلاحيتها.
الجلسات أحادية الاتجاه. يتم تسليم العلامات من أليس إلى بوب، ثم تستخدم أليس العلامات، واحدة تلو الأخرى، في الرسائل اللاحقة إلى بوب.
يمكن إنشاء الجلسات بين Destinations، أو بين routers، أو بين router و Destination. كل router و Destination يحتفظ بمدير مفاتيح الجلسة الخاص به لتتبع مفاتيح الجلسة وعلامات الجلسة. مديرو مفاتيح الجلسة المنفصلون يمنعون الخصوم من ربط عدة Destinations ببعضها البعض أو بـ router.
استقبال الرسائل
كل رسالة مستقبلة لها إحدى حالتين محتملتين:
- إنها جزء من جلسة موجودة وتحتوي على Session Tag وكتلة مشفرة بـ AES
- إنها لجلسة جديدة وتحتوي على كتل مشفرة بـ ElGamal و AES
عندما يتلقى router رسالة، سيفترض أولاً أنها من جلسة موجودة ويحاول البحث عن Session Tag وفك تشفير البيانات التالية باستخدام AES. إذا فشل ذلك، سيفترض أنها لجلسة جديدة ويحاول فك تشفيرها باستخدام ElGamal.
مواصفات رسالة الجلسة الجديدة
تحتوي رسالة ElGamal للجلسة الجديدة على جزأين، كتلة ElGamal مشفرة وكتلة AES مشفرة.
تحتوي الرسالة المشفرة على:
+----+----+----+----+----+----+----+----+
| |
+ +
| ElGamal Encrypted Block |
~ ~
| |
+ +----+----+----+----+----+----+
| | |
+----+----+ +
| |
+ +
| AES Encrypted Block |
~ ~
| |
+ +----+----+----+----+----+----+
| +
+----+----+
كتلة ElGamal
كتلة ElGamal المشفرة يبلغ طولها دائماً 514 بايت.
بيانات ElGamal غير المشفرة طولها 222 بايت، وتحتوي على:
+----+----+----+----+----+----+----+----+
| |
+ +
| Session Key |
+ +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
| |
+ +
| Pre-IV |
+ +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
+ +
| |
+ +
| 158 bytes random padding |
~ ~
| |
+ +----+----+
| |
+----+----+----+----+----+----+
مفتاح الجلسة Session Key المكون من 32 بايت هو المعرف للجلسة. سيتم استخدام Pre-IV المكون من 32 بايت لإنتاج IV لكتلة AES التي تتبعها؛ IV هو أول 16 بايت من SHA-256 Hash الخاص بـ Pre-IV.
يتم تشفير الحمولة البالغة 222 بايت باستخدام ElGamal والكتلة المشفرة يبلغ طولها 514 بايت.
كتلة AES
تحتوي البيانات غير المشفرة في كتلة AES على ما يلي:
+----+----+----+----+----+----+----+----+
|tag count| |
+----+----+ +
| |
+ +
| Session Tags |
~ ~
| |
+ +
| |
+ +----+----+----+----+----+----+
| | payload size | |
+----+----+----+----+----+----+ +
| |
+ +
| Payload Hash |
+ +
| |
+ +----+----+
| |flag| |
+----+----+----+----+----+----+----+ +
| |
+ +
| New Session Key (opt.) |
+ +
| |
+ +----+
| | |
+----+----+----+----+----+----+----+ +
| |
+ +
| Payload |
~ ~
| |
+ +----//---+----+
| | |
+----+----+----//---+----+ +
| Padding to 16 bytes |
+----+----+----+----+----+----+----+----+
التعريف
tag count:
2-byte Integer, 0-200
Session Tags:
That many 32-byte SessionTags
payload size:
4-byte Integer
Payload Hash:
The 32-byte SHA256 Hash of the payload
flag:
A one-byte value. Normally == 0. If == 0x01, a Session Key follows
New Session Key:
A 32-byte SessionKey,
to replace the old key, and is only present if preceding flag is 0x01
Payload:
the data
Padding:
Random data to a multiple of 16 bytes for the total length.
May contain more than the minimum required padding.
الحد الأدنى للطول: 48 بايت
يتم بعد ذلك تشفير البيانات بـ AES ، باستخدام مفتاح الجلسة و IV (المحسوب من pre-IV) من قسم ElGamal. طول كتلة AES المشفرة متغير لكنه دائماً مضاعف للـ 16 بايت.
ملاحظات
- الطول الفعلي الأقصى للحمولة، والطول الأقصى للكتلة، أقل من 64 كيلوبايت؛ انظر نظرة عامة على I2NP .
- مفتاح الجلسة الجديد غير مستخدم حاليًا ولا يكون موجودًا أبدًا.
مواصفات رسالة الجلسة الموجودة
يتم تذكر session tags التي تم تسليمها بنجاح لفترة قصيرة (15 دقيقة حالياً) حتى يتم استخدامها أو التخلص منها. يتم استخدام العلامة عن طريق تعبئتها في رسالة جلسة موجودة تحتوي فقط على كتلة مشفرة بـ AES، ولا تكون مسبوقة بكتلة ElGamal.
رسالة الجلسة الحالية كما يلي:
+----+----+----+----+----+----+----+----+
| |
+ +
| Session Tag |
+ +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
| |
+ +
| AES Encrypted Block |
~ ~
| |
+ +
| |
+----+----+----+----+----+----+----+----+
التعريف
Session Tag:
A 32-byte SessionTag
previously delivered in an AES block
AES Encrypted Block:
As specified above.
يعمل session tag أيضاً كـ pre-IV. الـ IV هو أول 16 بايت من SHA-256 Hash للـ sessionTag.
لفك تشفير رسالة من جلسة موجودة، يبحث الـ router عن Session Tag للعثور على Session Key مرتبط. إذا تم العثور على Session Tag، يتم فك تشفير كتلة AES باستخدام Session Key المرتبط. إذا لم يتم العثور على العلامة، يُفترض أن الرسالة هي New Session Message .
خيارات تكوين علامة الجلسة
اعتباراً من الإصدار 0.9.2، يمكن للعميل تكوين العدد الافتراضي من Session Tags المراد إرسالها وحد العلامات المنخفض للجلسة الحالية. بالنسبة للاتصالات المتدفقة المختصرة أو البيانات المجمعة، يمكن استخدام هذه الخيارات لتقليل عرض النطاق الترددي بشكل كبير. راجع مواصفات خيارات I2CP للحصول على التفاصيل. يمكن أيضاً تجاوز إعدادات الجلسة على أساس كل رسالة على حدة. راجع مواصفات I2CP Send Message Expires للحصول على التفاصيل.
العمل المستقبلي
ملاحظة: يتم استبدال ElGamal/AES+SessionTags بـ ECIES-X25519-AEAD-Ratchet (اقتراح 144). تم دمج القضايا والأفكار المشار إليها أدناه في تصميم البروتوكول الجديد. لن يتم معالجة العناصر التالية في ElGamal/AES+SessionTags.
هناك العديد من المجالات المحتملة لضبط خوارزميات مدير مفاتيح الجلسة؛ بعضها قد يتفاعل مع سلوك مكتبة التدفق، أو يكون له تأثير كبير على الأداء العام.
عدد العلامات المُسلمة قد يعتمد على حجم الرسالة، مع الأخذ في الاعتبار الحشو النهائي إلى 1KB في طبقة رسائل tunnel.
يمكن للعملاء إرسال تقدير لمدة حياة الجلسة إلى الـ router، كنصيحة استشارية حول عدد العلامات المطلوبة.
تسليم عدد قليل جداً من العلامات يجعل الـ router يعود إلى استخدام تشفير ElGamal المكلف.
قد يفترض الـ router تسليم Session Tags، أو ينتظر الإقرار قبل استخدامها؛ هناك مقايضات لكل استراتيجية.
للرسائل القصيرة جداً، يمكن استخدام ما يقارب كامل الـ 222 بايت من حقول pre-IV والحشو في كتلة ElGamal للرسالة بأكملها، بدلاً من إنشاء جلسة.
تقييم استراتيجية الحشو (padding)؛ حالياً نحن نضيف حشواً بحد أدنى 128 بايت. سيكون من الأفضل إضافة بعض العلامات (tags) للرسائل الصغيرة بدلاً من الحشو.
ربما يمكن أن تكون الأمور أكثر كفاءة إذا كان نظام Session Tag ثنائي الاتجاه، بحيث يمكن استخدام العلامات المرسلة في المسار ‘الأمامي’ في المسار ‘العكسي’، وبالتالي تجنب ElGamal في الاستجابة الأولية. يقوم الـ router حالياً ببعض الحيل مثل هذه عند إرسال رسائل اختبار tunnel إلى نفسه.
التغيير من Session Tags إلى PRNG متزامن .
قد تتطلب عدة من هذه الأفكار نوع رسالة I2NP جديد، أو تعيين علامة في تعليمات التسليم ، أو تعيين رقم سحري في البايتات القليلة الأولى من حقل Session Key وقبول مخاطرة صغيرة بأن يطابق Session Key العشوائي الرقم السحري.