ملاحظة
نشر الشبكة والاختبارات قيد التقدم. عرضة للتعديلات الطفيفة. انظر SPEC للمواصفات الرسمية.
نظرة عامة
عناوين Base 32 القياسية (“b32”) تحتوي على تجزئة الوجهة. هذا لن يعمل مع LS2 المشفر (اقتراح 123).
لا يمكنك استخدام عنوان base 32 تقليدي لـ LS2 المشفر (اقتراح 123)، لأنه يحتوي فقط على تجزئة الوجهة. لا يوفّر المفتاح العام غير المحجب. يجب على العملاء معرفة المفتاح العام للوجهة، نوع التوقيع، نوع التوقيع المحجب، ومفتاح سري أو خاص اختياري لإحضار وفك تشفير مجموعة الإيجار. لذلك، فإن عنوان base 32 وحده غير كافٍ. يحتاج العميل إما الوجهة الكاملة (التي تحتوي على المفتاح العام)، أو المفتاح العام بمفرده. إذا كان لدى العميل الوجهة الكاملة في دفتر العناوين، وكان دفتر العناوين يدعم البحث العكسي بواسطة التجزئة، يمكن حينها استرداد المفتاح العام.
لذلك نحتاج إلى تنسيق جديد يضع المفتاح العام بدلاً من التجزئة في عنوان base32. يجب أن يحتوي هذا التنسيق أيضًا على نوع توقيع المفتاح العام، ونوع توقيع نظام التعتيم.
يوثق هذا الاقتراح صيغة b32 جديدة لهذه العناوين. بينما أشرنا إلى هذا التنسيق الجديد خلال المناقشات كعنوان “b33”، يحتفظ تنسيق الجديد الفعلي باللاحقة المعتادة “.b32.i2p”.
الأهداف
- تضمين نوعي التوقيع غير الحاجبة والحاجبة لدعم مستقبلي لأنظمة التعتيم
- دعم المفاتيح العامة الأكبر من 32 بايت
- ضمان أن تكون أحرف b32 كلها أو معظمها عشوائية، خاصة في البداية (لا نريد كل العناوين أن تبدأ بنفس الأحرف)
- قابلة للتحليل
- الإشارة إلى أن هناك حاجة لمفتاح التعتيم و/أو المفتاح الخاص للعميل
- إضافة مجموعة تحقق للكشف عن الأخطاء الإملائية
- تقليل الطول، والحفاظ على طول التسمية في DNS أقل من 63 حرفًا للاستخدام الطبيعي
- الاستمرار في استخدام base 32 لعدم الحاجة للتمييز بين الحروف الكبيرة والصغيرة
- الحفاظ على اللاحقة المعتادة “.b32.i2p”.
الأهداف غير المرادة
- لا تدعم الروابط “الخاصة” التي تتضمن مفتاح التعتيم و/أو مفتاح العميل الخاص؛ هذا سيكون غير آمن.
التصميم
- سيحتوي التنسيق الجديد على المفتاح العام غير المحجب، نوع التوقيع غير المحجب، ونوع التوقيع المحجب.
- تحتوي بشكل اختياري على مفتاح سري و/أو خاص، للروابط الخاصة فقط
- استخدام اللاحقة “.b32.i2p” الموجودة، ولكن بطول أطول.
- إضافة مجموعة تحقق.
- يتم تحديد العناوين لمجموعات الإيجار المشفرة عن طريق 56 حرفًا أو أكثر مشفرة (35 بايت أو أكثر غير مشفرة)، مقارنةً بـ52 حرفًا (32 بايت) للعناوين التقليدية في base 32.
المواصفات
الإنشاء والترميز
إنشاء اسم النطاق من {56+ حرفًا}.b32.i2p (35+ حرفًا في الثنائي) كما يلي:
علامة (1 بايت)
بت 0: 0 لأنواع التوقيع بأحد البايتات، 1 لأنواع التوقيع ببايتين
بت 1: 0 عند عدم وجود سر، 1 إذا تطلب السر
بت 2: 0 عند عدم وجود مصادقة لكل عميل،
1 إذا تطلب مفتاح خاص للعميل
بتات 7-3: غير مستخدمة، تتحدد بـ 0
نوع توقيع المفتاح العام (1 أو 2 بايت كما هو مبين في العلامات)
إذا كانت 1 بايت، يتم اعتبار البايت العلوي صفرًا
نوع توقيع المفتاح المحجب (1 أو 2 بايت كما هو مبين في العلامات)
إذا كانت 1 بايت، يتم اعتبار البايت العلوي صفرًا
المفتاح العام
عدد البايتات كما هو مبين بنوع التوقيع
المعالجة اللاحقة ومجموعة التحقق:
إنشاء البيانات الثنائية كما هو موضح أعلاه.
معاملة مجموعة التحقق كأقل بايت.
حساب مجموعة التحقق = CRC-32(data[3:end])
data[0] ^= (بايت) مجموعة التحقق
data[1] ^= (بايت) (مجموعة التحقق >> 8)
data[2] ^= (بايت) (مجموعة التحقق >> 16)
اسم النطاق = Base32.encode(data) || ".b32.i2p"
يجب أن تكون أي بتات غير مستخدمة في نهاية b32 بقيمة 0. لا توجد بتات غير مستخدمة لعنوان نموذجي بطول 56 حرفًا (35 بايت).
فك التشفير والتحقق
احذف ".b32.i2p" من اسم النطاق
data = Base32.decode(hostname)
حساب مجموعة التحقق = CRC-32(data[3:end])
معاملة مجموعة التحقق كأقل بايت.
العلامات = data[0] ^ (بايت) مجموعة التحقق
إذا كانت أنواع التوقيع ببايت واحد:
نوع توقيع المفتاح العام = data[1] ^ (بايت) (مجموعة التحقق >> 8)
نوع توقيع المحجب = data[2] ^ (بايت) (مجموعة التحقق >> 16)
وإلا (أنواع التوقيع ببايتين) :
نوع توقيع المفتاح العام = data[1] ^ ((بايت) (مجموعة التحقق >> 8)) || data[2] ^ ((بايت) (مجموعة التحقق >> 16))
نوع توقيع المحجب = data[3] || data[4]
تحليل البقية بناءً على العلامات للحصول على المفتاح العام
البتات الخاصة بالمفتاح السري والخاص
يتم استخدام بتات المفتاح السري والخاص للإشارة إلى العملاء، الوكلاء، أو التعليمات البرمجية الأخرى على جانب العميل بأن السر و/أو المفتاح الخاص سيكون مطلوبًا لفك تشفير مجموعة الإيجار. قد تطلب تطبيقات معينة من المستخدم تقديم البيانات المطلوبة، أو رفض محاولات الاتصال إذا كانت البيانات المطلوبة مفقودة.
التبرير
- توفر XORing لأول 3 بايتات مع التجزئة القدرة على التحقق المحدود، وتضمن أن تشفر جميع أحرف base32 في البداية بشكل عشوائي. فقط بضع تراكيب احتمالية ومزيج valid ممكنة، لذا من المحتمل أن يتسبب أي خطأ إملائي في إنشاء تركيبة غير صالحة وسيتم رفضها.
- في الحالة المعتادة (أنواع التوقيع ببايت واحد، لا سر، لا مصادقة لكل عميل)، سيكون اسم النطاق {56 حرفًا}.b32.i2p، ويفك تشفيره إلى 35 بايتًا، مثل Tor.
- يحتوي Tor على تحقق ببايتين بمعدل سلبي زائف 1/64K. مع 3 بايتات، والدقائق القليلة من البايتات المتجاهلة، يقترب معدل الفشل لدينا من 1 في المليون، حيث أن معظم تراكيب احتمالية الترسانة غير صالحة.
- يعد Adler-32 اختيارًا سيئًا للمدخلات الصغيرة، وللكشف عن التغييرات الطفيفة . استخدم CRC-32 بدلاً من ذلك. CRC-32 سريع ومتوافر على نطاق واسع.
التخزين المؤقت
بينما هو خارج نطاق هذا الاقتراح، يجب على أجهزة التوجيه و/أو العملاء تذكر وتخزين مؤقتًا (ربما بشكل دائم) تعيين المفتاح العام إلى الوجهة، والعكس بالعكس.
ملاحظات
- تمييز النكهات القديمة عن الجديدة حسب الطول. العناوين القديمة لـb32 هي دائمًا {52 حرفًا}.b32.i2p. الجديدة هي {56+ حرفًا}.b32.i2p.
- موضوع مناقشة Tor: https://lists.torproject.org/pipermail/tor-dev/2017-January/011816.html
- لا تتوقع أن تحدث أنواع التوقيع ببايتين أبدًا، وصلنا فقط إلى 13. لا داعي للتنفيذ الآن.
- يمكن استخدام التنسيق الجديد في روابط الارتداد (وتوفيرها بواسطة خوادم الارتداد) إذا رغب بها، مثل b32.
القضايا
- أي مفتاح سري، خاص، أو عام أطول من 32 بايت سيتجاوز الحد الأقصى لطول التسمية في DNS البالغ 63 حرفًا. ربما لا تهتم المتصفحات.
الهجرة
لا مشاكل توافق رجعي. ستفشل عناوين b32 الأطول في التحويل إلى تجزئة ذات 32 بايتًا في البرنامج القديم.