الحالة
تم تنفيذه في 0.9.57. تركنا هذا الاقتراح مفتوحًا حتى نتمكن من تحسين ومناقشة الأفكار في قسم “التخطيط المستقبلي”.
نظرة عامة
ملخص
لم يتم استخدام مفتاح ElGamal العام في الوجهات منذ الإصدار 0.6 (2005). على الرغم من أن مواصفاتنا تشير إلى أنه غير مستخدم، إلا أنها لا تقول بوضوح أن الإصدارات يمكن أن تتجنب توليد زوج مفتاح ElGamal وملء الحقل ببساطة ببيانات عشوائية.
نقترح تغيير المواصفات لتقول إن الحقل يتم تجاهله وأن الإصدارات يمكن أن تملأ الحقل ببيانات عشوائية. هذا التغيير متوافق إلى الوراء. لا يوجد تنفيذ معروف يتحقق من صحة مفتاح ElGamal العام.
بالإضافة إلى ذلك، يقدم هذا الاقتراح توجيهًا للمطورين حول كيفية إنتاج البيانات العشوائية لوسادة الوجهة وهوية الراوتر بحيث تكون قابلة للضغط وفي نفس الوقت آمنة، ودون أن تظهر التعبيرات في شكل Base 64 وكأنها تالفة أو غير آمنة. هذا يوفر معظم فوائد إزالة حقول الوسادة دون أي تغييرات بروتوكول مدمرة. تقلل الوجهات القابلة للضغط من حجم تدفقات الـSYN والتدفقات القابلة للرد؛ تقلل الهويات القابلة للضغط من رسائل قاعدة البيانات المخزنة، ورسائل تأكيد الجلسات SSU2، وملفات reseed.
أخيرًا، يناقش الاقتراح الإمكانيات لأشكال جديدة من الوجهات وهويات الراوتر التي يمكن أن تلغي الوسادة بالكامل. وهناك أيضًا مناقشة مختصرة حول تشفير ما بعد الكم وكيف يمكن لذلك أن يؤثر على التخطيط المستقبلي.
الأهداف
- إلغاء الحاجة لتوليد أزواج مفاتيح ElGamal للوجهات
- التوصية بأفضل الممارسات لتكون الوجهات وهويات الراوتر قابلة للضغط بشكل كبير، لكنها لا تعرض أنماط واضحة في تمثيلات Base 64.
- تشجيع اعتماد أفضل الممارسات من قبل جميع الإصدارات بحيث لا تكون الحقول متميزة
- تقليل حجم تدفقات SYN
- تقليل حجم الحزم القابلة للرد
- تقليل حجم كتلة RI في SSU2
- تقليل حجم رسائل تأكيد الجلسات SSU2 وتكرار التجزئة
- تقليل حجم رسائل قاعدة البيانات المخزنة (مع RI)
- تقليل حجم ملفات الـreseed
- الحفاظ على التوافق في جميع البروتوكولات وواجهات برمجة التطبيقات
- تحديث المواصفات
- مناقشة البدائل لأشكال جديدة من الوجهات وهويات الراوتر
من خلال إلغاء الحاجة لتوليد مفاتيح ElGamal، يمكن للإصدارات إزالة رمز ElGamal بالكامل، مع مراعاة اعتبارات التوافق الورائي في بروتوكولات أخرى.
التصميم
بالحديث الصارم، فإن مفتاح التوقيع العام 32 بايت فقط (في كل من الوجهات وهويات الراوتر) ومفتاح التشفير العام 32 بايت (في هويات الراوتر فقط) هو عدد عشوائي يوفر كل العشوائية اللازمة لعمليات التجزئة SHA-256 لهذه الهياكل لتكون قوية تشفيرياً وموزعة عشوائيًا في قاعدة بيانات الشبكة DHT.
ومع ذلك، من باب الحذر الشديد، نوصي باستخدام حد أدنى من 32 بايت من البيانات العشوائية في حقل مفتاح ElG العام والوسادة. بالإضافة إلى ذلك، لو كانت الحقول كلها صفراً فسوف تتضمن الوجهات بتنسيق Base 64 تسلسلات طويلة من أحرف AAAA، مما قد يسبب انذاراً أو ارتباكًا لدى المستخدمين.
لنوع توقيع Ed25519 ونوع تشفير X25519: ستحتوي الوجهات على 11 نسخة (352 بايت) من البيانات العشوائية. ستحتوي هويات الراوتر على 10 نسخ (320 بايت) من البيانات العشوائية.
التوفير المتوقع
تتضمن الوجهات في كل تدفق SYN و الحزم القابلة للرد. تتضمن معلومات الراوتر (التي تحتوي على هويات الراوتر) في رسائل قاعدة البيانات المخزنة وفي رسائل تأكيد الجلسات في NTCP2 و SSU2.
لا يضغط NTCP2 معلومات الراوتر. تكون هويات الراوتر في رسائل قاعدة البيانات المخزنة ورسائل تأكيد الجلسات SSU2 مضغوطة بالـgzip. تكون معلومات الراوتر مضغوطة في ملفات reseed SU3.
لا تكون الوجهات في رسائل قاعدة البيانات المخزنة مضغوطة. تكون رسائل SYN مضغوطة بالـgzip في طبقة I2CP.
لنوع توقيع Ed25519 ونوع تشفير X25519، التوفير المتوقع:
| نوع البيانات | الحجم الكلي | المفاتيح والشهادة | البيانات غير المضغوطة | البيانات المضغوطة | الحجم | التوفير |
|---|---|---|---|---|---|---|
| الوجهة | 391 | 39 | 352 | 32 | 71 | 320 بايت (82%) |
| هوية الراوتر | 391 | 71 | 320 | 32 | 103 | 288 بايت (74%) |
| معلومة الراوتر | 1000 typ. | 71 | 320 | 32 | 722 typ. | 288 بايت (29%) |
ملاحظات: يفترض أن الشهادة 7 بايت غير قابلة للضغط، وبدون أي الحمل الـgzip إضافي. لا شيء صحيح، لكن التأثيرات ستكون قليلة. تجاهل الأجزاء القابلة للضغط الأخرى من معلومة الراوتر.
المواصفات
التغييرات المقترحة على مواصفاتنا الحالية موثقة أدناه.
الهياكل المشتركة
تغيير مواصفات الهياكل المشتركة لتحديد أن حقل المفتاح العام 256 بايت للوجهة يتم تجاهله وقد يحتوي على بيانات عشوائية.
إضافة قسم إلى مواصفات الهياكل المشتركة يوصي بأفضل الممارسات لحقل المفتاح العام للوجهة و حقول الوسادة في الوجهة وهوية الراوتر، كما يلي:
توليد 32 بايت من البيانات العشوائية باستخدام مولد أرقام زائف قوي للتشفير (PRNG) وتكرار تلك الـ32 بايت حسب الضرورة لملء حقل المفتاح العام (للوجهات) وحقل الوسادة (للوجهات وهوية الراوتر).
ملف المفتاح الخاص
صيغة ملف المفتاح الخاص (eepPriv.dat) ليست جزءًا رسميًا من مواصفاتنا لكنها موثقة في Java I2P javadocs وتقوم تطبيقات أخرى بدعمها. هذا يمكّن من قابلية نقل المفاتيح الخاصة إلى إصدارات مختلفة. إضافة ملاحظة إلى javadoc تشير إلى أن المفتاح العام للتشفير قد يكون وسادة عشوائية ويمكن أن يكون المفتاح الخاص للتشفير جميعها صفر أو بيانات عشوائية.
SAM
ملاحظة في مواصفات SAM أن المفتاح الخاص للتشفير غير مستخدم ويمكن تجاهله. يمكن لأي بيانات عشوائية أن تعاد بواسطة العميل. قد يرسل جسر SAM بيانات عشوائية عند الإنشاء (مع DEST GENERATE أو SESSION CREATE DESTINATION=TRANSIENT) بدلاً من جميع الأصفار، لذا فإن التمثيل Base 64 لا يحتوي على سلسلة من الأحرف AAAA ويظهر وكأنه معطل.
I2CP
لا تغييرات مطلوبة لـ I2CP. المفتاح الخاص للمفتاح العام للتشفير في الوجهة لا يُرسل إلى الراوتر.
التخطيط المستقبلي
تغييرات البروتوكول
بتكلفة تغييرات البروتوكول وعدم وجود توافق خلفي، يمكننا تغيير بروتوكولاتنا ومواصفاتنا لإزالة حقل الوسادة في الوجهة، الهوية الراوترية، أو كليهما.
يُظهر الاقتراح بعض التشابه مع شكل “b33” لسجل التشفير الذي يحتوي فقط على مفتاح وحقل نوع.
للحفاظ على بعض التوافق، يمكن لطبقات بروتوكول معينة أن “توسع” حقل الوسادة بكل الأصفار لتقديمها إلى طبقات بروتوكول أخرى.
للوجهات، يمكننا أيضًا إزالة حقل نوع التشفير في الشهادة المفتاحية، بتوفير قدرتين. بدلاً من ذلك، يمكن للوجهات الحصول على نوع تشفير جديد في الشهادة المفتاحية، يُشير إلى مفتاح عام صفري (ووسادة).
إذا لم يتم تضمين تحويل التوافق بين الأشكال القديمة والجديدة في بعض طبقات البروتوكول، ستتأثر المواصفات وواجهات برمجة التطبيقات والبروتوكولات والتطبيقات التالية:
- مواصفات الهياكل المشتركة
- I2NP
- I2CP
- NTCP2
- SSU2
- Ratchet
- Streaming
- SAM
- Bittorrent
- إعادة البذور
- ملف المفتاح الخاص
- واجهة برمجة التطبيقات الأساسية والراوتر الخاصة بجاڤا
- واجهة برمجة التطبيقات الخاصة بـi2pd
- مكتبات SAM الخاصة بالأطراف الثالثة
- الأدوات المدمجة والأطراف الثالثة
- عدة إضافات جاڤا
- واجهات المستخدم
- تطبيقات P2P مثل MuWire، بيتكوين، مونيرو
- hosts.txt، addressbook، والاشتراكات
إذا تم تحديد التحويل في بعض الطبقات، ستقل القائمة.
تكاليف وفوائد هذه التغييرات غير واضحة.
اقتراحات محددة TBD:
مفاتيح PQ
مفاتيح Post-quantum (PQ) العامة للتشفير، لأي خوارزمية متوقعة، أكبر من 256 بايت. وهذا من شأنه القضاء على أي وسادة وأي توفير من التغييرات المقترحة أعلاه، لهويات الراوتر.
في مقاربة PQ الهجينة، مثل ما يقوم به SSL، ستكون المفاتيح PQ مؤقتة فقط، ولن تظهر في هوية الراوتر.
مفاتيح التوقيع PQ غير قابلة للتطبيق، ولا تحتوي الوجهات على مفاتيح التشفير. المفاتيح الثابتة للratchet تكون في مجموعة الإيجار، وليس الوجهة. لذلك قد نستبعد الوجهات من المناقشة التالية.
لذلك فإن PQ يؤثر فقط على معلومات الراوتر، وفقط لمفاتيح ثابتة (وليس مؤقتة)، وليس لمفاتيح هجينة PQ. هذا سيكون لنوع تشفير جديد وسيؤثر على NTCP2، SSU2، و الرسائل في قاعدة البيانات المشفرة والردود. الإطار الزمني المقدر للتصميم والتطوير وطرح ذلك سيكون ؟؟؟؟؟ ولكن سيكون بعد الأجهزة الهجينة أو ratchet ؟؟؟؟؟؟؟؟
للمزيد من المناقشة راجع this topic.
القضايا
قد يكون من المرغوب فيه إعادة توليد الشبكة بمعدل بطيء، لتوفير تغطية للراوترات الجديدة. قد تعني “إعادة التوليد” مجرد تغيير الوسادة، وليس تغيير المفاتيح فعليًا.
لا يمكن إعادة توليد الوجهات الموجودة.
هل يجب تحديد هويات الراوتر مع الوسادة في حقل المفتاح العام بنوع تشفير مختلف في الشهادة الرئيسية؟ سيسبب هذا مشكلات توافق.
التحويل
لا توجد مشكلات توافق خلفي لاستبدال مفتاح ElGamal بوسادة.
إعادة التوليد، إذا تم تنفيذه، سيكون مشابهًا لما تم في ثلاث انتقالات هوية الراوتر السابقة: من DSA-SHA1 إلى توقيعات ECDSA، ثم إلى توقيعات EdDSA، ثم إلى تشفير X25519.
رهناً بمشكلات التوافق الخلفي، وبعد إلغاء تمكين SSU، قد تزيل الإصدارات كود ElGamal بالكامل. حوالي 14٪ من الراوترات في الشبكة هي من نوع تشفير ElGamal، بما في ذلك العديد من floodfills.
طلب دمج مسودة لجاڤا I2P في git.idk.i2p.