الحالة
تم التنفيذ في الإصدار 0.9.57. نترك هذا الاقتراح مفتوحًا حتى نتمكن من تحسين الأفكار والنقاش حولها في قسم “التخطيط المستقبلي”.
نظرة عامة
الملخص
لم يتم استخدام المفتاح العمومي ElGamal في الـ Destinations منذ الإصدار 0.6 (2005). بينما تنص مواصفاتنا على أن هذا الحقل غير مستخدم، فإنها لا تقول إن التنفيذ يمكنه تجنب توليد زوج مفاتيح ElGamal وببساطة ملء الحقل ببيانات عشوائية.
نقترح تغيير المواصفات لتشير إلى أن الحقل يتم تجاهله، وأنه يجوز للتنفيذات ملء الحقل ببيانات عشوائية. هذا التغيير متوافق مع الإصدارات السابقة. لا يوجد تنفيذ معروف يتحقق من صحة المفتاح العمومي ElGamal.
بالإضافة إلى ذلك، يقدم هذا الاقتراح توجيهات للمُنفِّذين حول كيفية توليد البيانات العشوائية لحقل التعبئة (padding) في الـ Destination وRouter Identity بحيث تكون قابلة للضغط مع الحفاظ على الأمان، ودون أن تبدو التمثيلات Base 64 فاسدة أو غير آمنة. وهذا يوفر معظم فوائد إزالة حقول التعبئة دون أي تغييرات بروتوكولية مزعجة. الـ Destinations القابلة للضغط تقلل من حجم رسائل SYN في البث، وحجم حزم البيانات القابلة للإجابة؛ والـ Router Identities القابلة للضغط تقلل من رسائل Database Store، ورسائل SSU2 Session Confirmed، ومن ملفات إعادة التهيئة (reseed) بصيغة su3.
وأخيرًا، يناقش الاقتراح إمكانية صيغ جديدة لـ Destination وRouter Identity التي قد تلغي حقول التعبئة تمامًا. كما يتناول بشكل موجز موضوع التشفير المقاوم للحوسبة الكمية (post-quantum crypto) وكيف قد يؤثر ذلك على التخطيط المستقبلي.
الأهداف
- إزالة متطلب توليد زوج مفاتيح ElGamal للـ Destinations
- التوصية بأفضل الممارسات لجعل الـ Destinations وRouter Identities قابلة للضغط بشدة، دون أن تُظهر أنماطًا واضحة في التمثيلات Base 64.
- تشجيع اعتماد أفضل الممارسات من قبل جميع التنفيذات بحيث لا يمكن التمييز بين الحقول
- تقليل حجم رسائل البث SYN
- تقليل حجم حزم البيانات القابلة للإجابة
- تقليل حجم كتلة RI في SSU2
- تقليل حجم رسالة SSU2 Session Confirmed وتكرار التجزئة
- تقليل حجم رسالة Database Store (مع RI)
- تقليل حجم ملفات إعادة التهيئة (reseed)
- الحفاظ على التوافق في جميع البروتوكولات وواجهات برمجة التطبيقات (APIs)
- تحديث المواصفات
- مناقشة البدائل لصيغ جديدة لـ Destination وRouter Identity
من خلال إزالة متطلب توليد مفاتيح ElGamal، قد تتمكن التنفيذات من إزالة كود ElGamal بالكامل، رهناً باعتبارات التوافق مع الإصدارات السابقة في بروتوكولات أخرى.
التصميم
من الناحية الفنية، فإن المفتاح العمومي للتوقيع (32 بايت) وحده (في كل من Destinations وRouter Identities) والمفتاح العمومي للتشفير (32 بايت) (في Router Identities فقط) هو رقم عشوائي يوفر كل الإنتروبيا اللازمة لجعل تجزئات SHA-256 لهذه الهياكل قوية تشفيريًا وموزعة عشوائيًا في قاعدة بيانات الشبكة (DHT).
ومع ذلك، وحرصًا على الحيطة، نوصي باستخدام 32 بايت كحد أدنى من البيانات العشوائية في حقل المفتاح العمومي ElG وحقل التعبئة. بالإضافة إلى ذلك، إذا كانت الحقول عبارة عن أصفار فقط، فستحتوي الـ Destinations بصيغة Base 64 على سلاسل طويلة من أحرف AAAA، مما قد يسبب قلقًا أو حيرة للمستخدمين.
لنوع التوقيع Ed25519 ونوع التشفير X25519: ستحتوي الـ Destinations على 11 نسخة (352 بايت) من البيانات العشوائية. وستحتوي الـ Router Identities على 10 نسخ (320 بايت) من البيانات العشوائية.
التوفير المقدر
تُضمَّن الـ Destinations في كل رسالة SYN بث وكل حزمة بيانات قابلة للإجابة. تُضمَّن الـ Router Infos (التي تحتوي على Router Identities) في رسائل Database Store وفي رسائل Session Confirmed في بروتوكولي NTCP2 وSSU2.
لا يقوم NTCP2 بضغط الـ Router Info. تُضغط الـ RIs في رسائل Database Store ورسائل SSU2 Session Confirmed باستخدام gzip. تُضغط الـ Router Infos في ملفات إعادة التهيئة SU3.
لا تُضغط الـ Destinations في رسائل Database Store. تُضغط رسائل البث SYN باستخدام gzip على مستوى I2CP.
لنوع التوقيع Ed25519 ونوع التشفير X25519، التوفير المقدر:
| نوع البيانات | الحجم الكلي | المفاتيح والشهادات | التعبئة غير المضغوطة | التعبئة المضغوحة | الحجم | التوفير |
|---|---|---|---|---|---|---|
| Destination | 391 | 39 | 352 | 32 | 71 | 320 بايت (82%) |
| Router Identity | 391 | 71 | 320 | 32 | 103 | 288 بايت (74%) |
| Router Info | 1000 تقريبًا | 71 | 320 | 32 | 722 تقريبًا | 288 بايت (29%) |
ملاحظات: يفترض أن شهادة 7 بايت غير قابلة للضغط، ولا يوجد أي تكلفة إضافية من gzip. لا ينطبق أي من ذلك تمامًا، لكن التأثيرات ستكون ضئيلة. يتجاهل الأجزاء الأخرى القابلة للضغط في الـ Router Info.
المواصفات
التغييرات المقترحة على مواصفاتنا الحالية موثقة أدناه.
الهياكل المشتركة
تغيير مواصفات الهياكل المشتركة لتشير إلى أن حقل المفتاح العمومي للـ Destination (256 بايت) يتم تجاهله وقد يحتوي على بيانات عشوائية.
إضافة قسم إلى مواصفات الهياكل المشتركة لتوصية بأفضل الممارسات لحقل المفتاح العمومي للـ Destination وحقول التعبئة في الـ Destination وRouter Identity، كالتالي:
توليد 32 بايت من البيانات العشوائية باستخدام مولد أرقام عشوائية تشفيري قوي (PRNG) وإعادة تكرار هذه الـ 32 بايت حسب الحاجة لملء حقل المفتاح العمومي (للـ Destinations) وحقل التعبئة (للـ Destinations وRouter Identities).
ملف المفتاح الخاص
تنسيق ملف المفتاح الخاص (eepPriv.dat) ليس جزءًا رسميًا من مواصفاتنا لكنه موثق في Java I2P javadocs وتدعمه التنفيذات الأخرى. وهذا يتيح نقل المفاتيح الخاصة بين التنفيذات المختلفة. إضافة ملاحظة إلى تلك الوثائق تشير إلى أن المفتاح العمومي للتشفير قد يكون تعبئة عشوائية وأن المفتاح الخاص للتشفير قد يكون أصفارًا أو بيانات عشوائية.
SAM
ملاحظة في مواصفات SAM أن المفتاح الخاص للتشفير غير مستخدم ويمكن تجاهله. يمكن للعميل إرجاع أي بيانات عشوائية. قد يقوم جسر SAM بإرسال بيانات عشوائية عند الإنشاء (مع DEST GENERATE أو SESSION CREATE DESTINATION=TRANSIENT) بدلًا من الأصفار، بحيث لا تحتوي التمثيلات Base 64 على سلسلة من أحرف AAAA وتبدو غير تالفة.
I2CP
لا توجد تغييرات مطلوبة في I2CP. لا يتم إرسال المفتاح الخاص للمفتاح العمومي للتشفير في الـ Destination إلى الراوتر.
التخطيط المستقبلي
تغييرات البروتوكول
بتكلفة تغييرات بروتوكول وفقدان التوافق مع الإصدارات السابقة، يمكننا تغيير بروتوكولاتنا ومواصفاتنا لإزالة حقل التعبئة في الـ Destination، أو Router Identity، أو كليهما.
يتشابه هذا الاقتراح إلى حد ما مع تنسيق الـ leaseset المشفر “b33”، الذي يحتوي فقط على حقل مفتاح وحقل نوع.
للحفاظ على بعض التوافق، يمكن لطبقات بروتوكول معينة “توسيع” حقل التعبئة بأصفار لعرضه على طبقات بروتوكول أخرى.
بالنسبة للـ Destinations، يمكننا أيضًا إزالة حقل نوع التشفير في شهادة المفتاح، بتوفر اثنين من البايتات. بديلًا، يمكن للـ Destinations الحصول على نوع تشفير جديد في شهادة المفتاح، يشير إلى مفتاح عمومي صفري (وتعبئة).
إذا لم يتم تضمين تحويل التوافق بين التنسيقات القديمة والجديدة في طبقة بروتوكول ما، فستتأثر المواصفات وواجهات برمجة التطبيقات والبروتوكولات والتطبيقات التالية:
- مواصفات الهياكل المشتركة
- I2NP
- I2CP
- NTCP2
- SSU2
- Ratchet
- Streaming
- SAM
- Bittorrent
- إعادة التهيئة (Reseeding)
- ملف المفتاح الخاص
- واجهة برمجة التطبيقات الأساسية للـ Java والراوتر
- واجهة برمجة التطبيقات i2pd
- مكتبات SAM من طرف ثالث
- الأدوات المدمجة وأدوات الطرف الثالث
- العديد من الإضافات (plugins) الخاصة بـ Java
- واجهات المستخدم
- تطبيقات الند للند مثل MuWire، البيتكوين، المونرو
إذا تم تحديد التحويل في طبقة ما، فستقل القائمة.
ليست واضحة التكاليف والفوائد من هذه التغييرات.
الاقتراحات المحددة قيد التحديد:
المفاتيح الكمية (PQ Keys)
مفاتيح التشفير العمومية المقاومة للحوسبة الكمية (PQ)، لأي خوارزمية متوقعة، أكبر من 256 بايت. وهذا سيزيل أي تعبئة وأي توفير من التغييرات المقترحة أعلاه، بالنسبة لـ Router Identities.
في نهج “هجين” (hybrid) لـ PQ، مثل ما تفعله SSL، تكون مفاتيح PQ مؤقتة فقط، ولا تظهر في الـ Router Identity.
مفاتيح التوقيع PQ ليست قابلة للتطبيق، ولا تحتوي الـ Destinations على مفاتيح عمومية للتشفير. المفاتيح الثابتة لـ ratchet موجودة في الـ Lease Set، وليس في الـ Destination. لذلك قد نستبعد الـ Destinations من المناقشة التالية.
إذًا، تؤثر PQ فقط على الـ Router Infos، وفقط للمفاتيح الثابتة (وليس المؤقتة)، وليس للنهج الهجين. سيكون ذلك لـ نوع تشفير جديد وسيؤثر على NTCP2 وSSU2، وإلى رسائل البحث المشفرة في قاعدة البيانات والردود عليها. الإطار الزمني المقدر لتصميم وتطوير ونشر ذلك سيكون ???????? لكن سيكون بعد النهج الهجين أو ratchet ????????????
لمزيد من المناقشة انظر هذا الموضوع .
القضايا
قد يكون من المستحسن إعادة توليد مفاتيح الشبكة بمعدل بطيء، لتوفير غطاء للراوترات الجديدة. “إعادة التوليد” قد تعني ببساطة تغيير التعبئة، وليس تغيير المفاتيح فعليًا.
ليس من الممكن إعادة توليد مفاتيح الـ Destinations الحالية.
هل ينبغي تمييز الـ Router Identities التي تحتوي على تعبئة في حقل المفتاح العمومي بنوع تشفير مختلف في شهادة المفتاح؟ هذا سيسبب مشكلات في التوافق.
الهجرة
لا توجد مشكلات في التوافق مع الإصدارات السابقة عند استبدال مفتاح ElGamal بالتعبئة.
إعادة التوليد، إذا تم تنفيذها، ستكون مشابهة لما تم في ثلاث انتقالات سابقة لهوية الراوتر: من التوقيعات DSA-SHA1 إلى التوقيعات ECDSA، ثم إلى التوقيعات EdDSA، ثم إلى تشفير X25519.
رهناً بمشكلات التوافق مع الإصدارات السابقة، وبعد تعطيل SSU، يمكن للتنفيذات إزالة كود ElGamal بالكامل. حوالي 14% من الراوترات في الشبكة تستخدم نوع التشفير ElGamal، بما في ذلك العديد من الراوترات floodfill.
يوجد طلب دمج أولي لـ Java I2P في git.idk.i2p .