تم إنشاء هذه الترجمة باستخدام التعلم الآلي وقد لا تكون دقيقة بنسبة 100%. عرض النسخة الإنجليزية

التسمية ودفتر العناوين

كيف يربط I2P أسماء المضيفين القابلة للقراءة البشرية بالوجهات

Updated: 2025-01 Accurate for: 0.9.65

نظرة عامة

يأتي I2P مع مكتبة تسمية عامة وتطبيق أساسي مصمم للعمل من خلال ربط الأسماء المحلية بالوجهات، بالإضافة إلى تطبيق إضافي يُسمى دفتر العناوين . كما يدعم I2P أسماء المضيفين Base32 المشابهة لعناوين .onion في Tor.

دفتر العناوين هو نظام تسمية آمن وموزع وقابل للقراءة بشرياً يعتمد على شبكة الثقة، ويضحي فقط بمطلب أن تكون جميع الأسماء القابلة للقراءة بشرياً فريدة عالمياً من خلال فرض التفرد المحلي فقط. بينما جميع الرسائل في I2P تُعنون تشفيرياً حسب وجهتها، يمكن لأشخاص مختلفين أن يكون لديهم إدخالات محلية في دفتر العناوين لـ “Alice” تشير إلى وجهات مختلفة. لا يزال بإمكان الناس اكتشاف أسماء جديدة من خلال استيراد دفاتر العناوين المنشورة للأقران المحددين في شبكة ثقتهم، أو بإضافة الإدخالات المقدمة من طرف ثالث، أو (إذا نظم بعض الأشخاص سلسلة من دفاتر العناوين المنشورة باستخدام نظام تسجيل الأسبقية) يمكن للناس أن يختاروا التعامل مع دفاتر العناوين هذه كخوادم أسماء، محاكين DNS التقليدي.

ملاحظة: للاطلاع على الأسباب وراء نظام التسمية في I2P، والحجج الشائعة ضده والبدائل المحتملة، راجع صفحة مناقشة التسمية .

مكونات نظام التسمية

لا توجد سلطة تسمية مركزية في I2P. جميع أسماء المضيفين محلية.

نظام التسمية بسيط جداً ومعظمه مُطبق في تطبيقات خارجية عن الـ router، ولكنها مُجمعة مع توزيعة I2P. المكونات هي:

  1. خدمة التسمية المحلية التي تقوم بعمليات البحث وتتعامل أيضاً مع أسماء المضيفين Base32 .
  2. وكيل HTTP الذي يطلب من الموجه عمليات البحث ويوجه المستخدم إلى خدمات jump البعيدة للمساعدة في عمليات البحث الفاشلة.
  3. نماذج host-add الخاصة بـ HTTP والتي تسمح للمستخدمين بإضافة مضيفين إلى ملف hosts.txt المحلي الخاص بهم.
  4. خدمات jump الخاصة بـ HTTP والتي توفر عمليات البحث وإعادة التوجيه الخاصة بها.
  5. تطبيق دفتر العناوين الذي يدمج قوائم المضيفين الخارجية، المستردة عبر HTTP، مع القائمة المحلية.
  6. تطبيق SusiDNS وهو واجهة ويب بسيطة لتكوين دفتر العناوين وعرض قوائم المضيفين المحلية.

خدمات التسمية

جميع الوجهات في I2P هي مفاتيح بطول 516 بايت (أو أكثر). (لتكون أكثر دقة، إنه مفتاح عام بحجم 256 بايت بالإضافة إلى مفتاح توقيع بحجم 128 بايت بالإضافة إلى شهادة بحجم 3 بايت أو أكثر، والتي في تمثيل Base64 تكون 516 بايت أو أكثر. الشهادات غير الفارغة مستخدمة الآن للإشارة إلى نوع التوقيع. لذلك، الشهادات في الوجهات المُولّدة مؤخراً تكون أكثر من 3 بايت.

إذا رغب تطبيق (i2ptunnel أو HTTP proxy) في الوصول إلى وجهة بالاسم، فإن router يقوم بعملية بحث محلية بسيطة جداً لحل ذلك الاسم.

خدمة تسمية Hosts.txt

خدمة التسمية hosts.txt تقوم ببحث خطي بسيط عبر الملفات النصية. كانت خدمة التسمية هذه هي الافتراضية حتى الإصدار 0.8.8 عندما تم استبدالها بخدمة التسمية Blockfile. أصبح تنسيق hosts.txt بطيئًا جدًا بعد أن نما الملف ليحتوي على آلاف الإدخالات.

يقوم بالبحث الخطي عبر ثلاثة ملفات محلية، بالترتيب، للبحث عن أسماء المضيفين وتحويلها إلى مفتاح وجهة بحجم 516 بايت. كل ملف بتنسيق ملف تكوين بسيط، مع hostname=base64، واحد في كل سطر. الملفات هي:

  1. privatehosts.txt
  2. userhosts.txt
  3. hosts.txt

خدمة تسمية Blockfile

يقوم Blockfile Naming Service بتخزين عدة “دفاتر عناوين” في ملف قاعدة بيانات واحد يسمى hostsdb.blockfile. هذا Naming Service هو الافتراضي منذ الإصدار 0.8.8.

blockfile هو ببساطة تخزين على القرص لخرائط مرتبة متعددة (أزواج مفتاح-قيمة)، مُنفذة كـ skiplists. تنسيق blockfile محدد في صفحة Blockfile . يوفر بحثاً سريعاً عن Destination بتنسيق مضغوط. بينما النفقات الإضافية لـ blockfile كبيرة، يتم تخزين destinations بالنظام الثنائي بدلاً من Base 64 كما في تنسيق hosts.txt. بالإضافة إلى ذلك، يوفر blockfile إمكانية تخزين بيانات وصفية تعسفية (مثل تاريخ الإضافة والمصدر والتعليقات) لكل إدخال لتنفيذ ميزات متقدمة لدفتر العناوين. متطلب التخزين لـ blockfile هو زيادة متواضعة عن تنسيق hosts.txt، ويوفر blockfile انخفاضاً يقارب 10 أضعاف في أوقات البحث.

عند الإنشاء، تستورد خدمة التسمية الإدخالات من الملفات الثلاثة المستخدمة بواسطة خدمة التسمية hosts.txt. يحاكي ملف البلوك التنفيذ السابق من خلال الحفاظ على ثلاث خرائط يتم البحث فيها بالترتيب، والمسماة privatehosts.txt و userhosts.txt و hosts.txt. كما يحتفظ بخريطة بحث عكسي لتنفيذ عمليات البحث العكسي السريعة.

مرافق خدمة التسمية الأخرى

البحث غير حساس لحالة الأحرف. يتم استخدام أول تطابق، ولا يتم اكتشاف التعارضات. لا يوجد فرض لقواعد التسمية في عمليات البحث. يتم تخزين عمليات البحث مؤقتاً لبضع دقائق. حل Base 32 موضح أدناه . للحصول على وصف كامل لـ API الخاص بخدمة التسمية راجع Naming Service Javadocs . تم توسيع هذا الـ API بشكل كبير في الإصدار 0.8.7 لتوفير عمليات الإضافة والحذف، وتخزين خصائص اختيارية مع اسم المضيف، وميزات أخرى.

خدمات التسمية البديلة والتجريبية

يتم تحديد خدمة التسمية باستخدام خاصية التكوين i2p.naming.impl=class. التطبيقات الأخرى ممكنة. على سبيل المثال، هناك مرفق تجريبي للبحث في الوقت الفعلي (مثل DNS) عبر الشبكة داخل router. لمزيد من المعلومات انظر البدائل في صفحة النقاش .

يقوم HTTP proxy بالبحث عبر router عن جميع أسماء المضيفين التي تنتهي بـ ‘.i2p’. وإلا، فإنه يعيد توجيه الطلب إلى HTTP outproxy مُكوَّن. وبالتالي، في الممارسة العملية، يجب أن تنتهي جميع أسماء مضيفي HTTP (مواقع I2P) بالنطاق العلوي الزائف ‘.i2p’.

إذا فشل الـ router في حل اسم المضيف، فإن بروكسي HTTP يُرجع صفحة خطأ للمستخدم تحتوي على روابط لعدة خدمات “انتقال”. راجع التفاصيل أدناه.

نطاق .i2p.alt

سبق أن تقدمنا بطلب لحجز نطاق .i2p العلوي باتباع الإجراءات المحددة في RFC 6761 . ومع ذلك، تم رفض هذا الطلب وجميع الطلبات الأخرى، وتم اعتبار RFC 6761 “خطأ”.

بعد سنوات عديدة من العمل من قِبل فريق GNUnet وآخرين، تم حجز النطاق .alt كنطاق مستوى أعلى للاستخدام الخاص في RFC 9476 اعتبارًا من أواخر عام 2023. بينما لا توجد جهات تسجيل رسمية معتمدة من IANA، قمنا بتسجيل النطاق .i2p.alt لدى جهة التسجيل غير الرسمية الأساسية GANA . هذا لا يمنع آخرين من استخدام النطاق، ولكن يجب أن يساعد في تثبيطهم عن ذلك.

إحدى الفوائد لنطاق .alt هي أنه، نظرياً، لن تقوم أجهزة حل DNS بإعادة توجيه طلبات .alt بمجرد تحديثها للامتثال لـ RFC 9476، وهذا سيمنع تسريبات DNS. للتوافق مع أسماء المضيفين .i2p.alt، يجب تحديث برامج وخدمات I2P للتعامل مع هذه الأسماء المضيفة عن طريق إزالة نطاق .alt TLD. من المقرر إجراء هذه التحديثات في النصف الأول من عام 2024.

في الوقت الحالي، لا توجد خطط لجعل .i2p.alt الشكل المفضل لعرض وتبادل أسماء المضيفين في I2P. هذا موضوع يتطلب المزيد من البحث والمناقشة.

دفتر العناوين

الاشتراكات الواردة والدمج

يقوم تطبيق دفتر العناوين بشكل دوري بجلب ملفات hosts.txt الخاصة بالمستخدمين الآخرين ودمجها مع ملف hosts.txt المحلي، بعد إجراء عدة فحوصات. يتم حل تعارض الأسماء على أساس الأولوية في الوصول.

الاشتراك في ملف hosts.txt الخاص بمستخدم آخر ينطوي على منحه قدرًا معينًا من الثقة. لا تريد منهم، على سبيل المثال، “اختطاف” موقع جديد عن طريق إدخال مفتاحهم الخاص بسرعة لموقع جديد قبل تمرير إدخال المضيف/المفتاح الجديد إليك.

لهذا السبب، الاشتراك الوحيد المكون افتراضياً هو http://i2p-projekt.i2p/hosts.txt (http://udhdrtrcetjm5sxzskjyr5ztpeszydbh4dpl3pl4utgqqw2v4jna.b32.i2p/hosts.txt)، والذي يحتوي على نسخة من ملف hosts.txt المدرج في إصدار I2P. يجب على المستخدمين تكوين اشتراكات إضافية في تطبيق دفتر العناوين المحلي الخاص بهم (عبر subscriptions.txt أو SusiDNS ).

بعض روابط الاشتراك الأخرى لدفتر العناوين العام:

قد يكون لدى مشغلي هذه الخدمات سياسات مختلفة لإدراج المضيفين. الوجود في هذه القائمة لا يعني التأييد.

قواعد التسمية

بينما لا توجد على الأرجح أي قيود تقنية داخل I2P على أسماء المضيفين، فإن دفتر العناوين يفرض عدة قيود على أسماء المضيفين المستوردة من الاشتراكات. يقوم بذلك من أجل السلامة الطباعية الأساسية والتوافق مع المتصفحات، وللأمان. القواعد هي نفسها الموجودة في RFC2396 Section 3.2.2. أي أسماء مضيفين تنتهك هذه القواعد قد لا يتم نشرها إلى router أخرى.

قواعد التسمية:

  • يتم تحويل الأسماء إلى أحرف صغيرة عند الاستيراد.
  • يتم فحص الأسماء للتأكد من عدم تعارضها مع الأسماء الموجودة في ملفات userhosts.txt و hosts.txt الحالية (ولكن ليس privatehosts.txt) بعد التحويل إلى أحرف صغيرة.
  • يجب أن تحتوي فقط على [a-z] [0-9] ‘.’ و ‘-’ بعد التحويل إلى أحرف صغيرة.
  • يجب ألا تبدأ بـ ‘.’ أو ‘-’.
  • يجب أن تنتهي بـ ‘.i2p’.
  • 67 حرف كحد أقصى، شاملة ‘.i2p’.
  • يجب ألا تحتوي على ‘..’.
  • يجب ألا تحتوي على ‘.-’ أو ‘-.’ (اعتباراً من 0.6.1.33).
  • يجب ألا تحتوي على ‘–’ إلا في ‘xn–’ لـ IDN.
  • أسماء المضيفين Base32 (*.b32.i2p) محجوزة لاستخدام base 32 وبالتالي غير مسموح باستيرادها.
  • أسماء مضيفين معينة محجوزة لاستخدام المشروع غير مسموحة (proxy.i2p, router.i2p, console.i2p, mail.i2p, *.proxy.i2p, *.router.i2p, *.console.i2p, *.mail.i2p، وأخرى)
  • أسماء المضيفين التي تبدأ بـ ‘www.’ محبطة ومرفوضة من قبل بعض خدمات التسجيل. بعض تطبيقات addressbook تزيل بادئات ‘www.’ تلقائياً من البحث. لذلك تسجيل ‘www.example.i 2p’ غير ضروري، وتسجيل وجهة مختلفة لـ ‘www.example.i 2p’ و ’example.i2p’ سيجعل ‘www.example.i 2p’ غير قابل للوصول لبعض المستخدمين.
  • يتم فحص المفاتيح لصحة base64.
  • يتم فحص المفاتيح للتأكد من عدم تعارضها مع المفاتيح الموجودة في hosts.txt (ولكن ليس privatehosts.txt).
  • الحد الأدنى لطول المفتاح 516 بايت.
  • الحد الأقصى لطول المفتاح 616 بايت (لاستيعاب شهادات تصل إلى 100 بايت).

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

لاحظ أن رموز ‘.’ في اسم المضيف لا تحمل أي أهمية، ولا تشير إلى أي تسلسل هرمي فعلي للتسمية أو الثقة. إذا كان الاسم ‘host.i2p’ موجوداً بالفعل، فلا يوجد ما يمنع أي شخص من إضافة اسم ‘a.host.i2p’ إلى ملف hosts.txt الخاص به، ويمكن استيراد هذا الاسم من قبل دفتر العناوين الخاص بالآخرين. طرق منع النطاقات الفرعية لغير ‘مالكي’ النطاق (الشهادات؟)، ومدى رغبة وجدوى هذه الطرق، هي مواضيع للمناقشة المستقبلية.

أسماء النطاقات الدولية (IDN) تعمل أيضاً في i2p (باستخدام نموذج punycode ‘xn–’). لرؤية أسماء نطاقات .i2p IDN معروضة بشكل صحيح في شريط العنوان في Firefox، أضف ’network.IDN.whitelist.i2p (boolean) = true’ في about:config.

نظراً لأن تطبيق دفتر العناوين لا يستخدم ملف privatehosts.txt على الإطلاق، فإن هذا الملف هو المكان الوحيد المناسب عملياً لوضع الأسماء المستعارة الخاصة أو “الأسماء المحببة” للمواقع الموجودة بالفعل في hosts.txt.

تنسيق موجز الاشتراك المتقدم

اعتباراً من الإصدار 0.9.26، قد تدعم مواقع الاشتراك والعملاء بروتوكول متقدم لتغذية hosts.txt يتضمن البيانات الوصفية بما في ذلك التوقيعات. هذا التنسيق متوافق مع الإصدارات السابقة لتنسيق hosts.txt القياسي hostname=base64destination. انظر المواصفات للتفاصيل.

الاشتراكات الصادرة

سيقوم دفتر العناوين بنشر ملف hosts.txt المدموج إلى موقع معين (تقليدياً hosts.txt في المجلد الرئيسي لموقع I2P المحلي) ليتم الوصول إليه من قبل الآخرين لاشتراكاتهم. هذه الخطوة اختيارية وهي معطلة افتراضياً.

مشاكل الاستضافة ونقل HTTP

تطبيق دفتر العناوين، مع eepget، يحفظ معلومات Etag و/أو Last-Modified التي يرجعها خادم الويب الخاص بالاشتراك. هذا يقلل بشكل كبير من عرض النطاق الترددي المطلوب، حيث سيرجع خادم الويب استجابة ‘304 Not Modified’ في الجلب التالي إذا لم يتغير شيء.

ومع ذلك يتم تحميل ملف hosts.txt بالكامل إذا تغير. راجع المناقشة أدناه حول هذه المسألة.

يُنصح بشدة للخوادم التي تقدم ملف hosts.txt ثابت أو تطبيق CGI مكافئ أن تقوم بتقديم رأس Content-Length، وإما رأس Etag أو Last-Modified. تأكد أيضاً من أن الخادم يقدم استجابة ‘304 Not Modified’ عند الحاجة. هذا سيقلل بشكل كبير من عرض النطاق الترددي للشبكة، ويقلل من فرص الفساد.

خدمات إضافة المضيف

خدمة إضافة المضيف هي تطبيق CGI بسيط يأخذ اسم المضيف ومفتاح Base64 كمعاملات ويضيفهما إلى ملف hosts.txt المحلي الخاص به. إذا اشترك routers أخرى في ذلك الملف hosts.txt، فسيتم نشر اسم المضيف/المفتاح الجديد عبر الشبكة.

يُوصى بأن تفرض خدمات إضافة المضيفين، كحد أدنى، القيود المفروضة من قبل تطبيق دفتر العناوين المذكور أعلاه. قد تفرض خدمات إضافة المضيفين قيوداً إضافية على أسماء المضيفين والمفاتيح، على سبيل المثال:

  • حد أقصى لعدد “النطاقات الفرعية”.
  • التفويض للـ “النطاقات الفرعية” من خلال طرق مختلفة.
  • Hashcash أو الشهادات الموقعة.
  • المراجعة التحريرية لأسماء المضيفين و/أو المحتوى.
  • تصنيف المضيفين حسب المحتوى.
  • حجز أو رفض أسماء مضيفين معينة.
  • قيود على عدد الأسماء المسجلة في فترة زمنية محددة.
  • تأخير بين التسجيل والنشر.
  • شرط أن يكون المضيف متاحاً للتحقق.
  • انتهاء الصلاحية و/أو الإلغاء.
  • رفض انتحال IDN.

خدمات القفز

خدمة الانتقال هي تطبيق CGI بسيط يأخذ اسم المضيف كمعامل ويعيد إعادة توجيه 301 إلى الرابط الصحيح مع إضافة نص ?i2paddresshelper=key. سيقوم وكيل HTTP بتفسير النص المُضاف واستخدام ذلك المفتاح كوجهة فعلية. بالإضافة إلى ذلك، سيقوم الوكيل بحفظ ذلك المفتاح مؤقتاً حتى لا تكون هناك حاجة لمساعد العنوان حتى إعادة التشغيل.

لاحظ أنه، مثل الاشتراكات، فإن استخدام خدمة القفز يتضمن قدراً معيناً من الثقة، حيث يمكن لخدمة القفز أن توجه المستخدم بشكل ضار إلى وجهة غير صحيحة.

لتقديم أفضل خدمة، يجب على خدمة القفز أن تشترك في عدة مزودي hosts.txt حتى تكون قائمة المضيفين المحلية محدثة.

SusiDNS

SusiDNS هو ببساطة واجهة ويب أمامية لتكوين اشتراكات دفتر العناوين والوصول إلى ملفات دفتر العناوين الأربعة. يتم تنفيذ جميع الأعمال الفعلية بواسطة تطبيق ‘دفتر العناوين’.

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

أسماء Base32

يدعم I2P أسماء المضيفين Base32 المشابهة لعناوين .onion في Tor. عناوين Base32 أقصر بكثير وأسهل في التعامل من Destinations Base64 الكاملة المكونة من 516 حرفاً أو addresshelpers. مثال: ukeu3k5oycgaauneqgtnvselmt4yemvoilkln7jpvamvfx7dnkdq.b32.i2p

في Tor، العنوان يتكون من 16 حرفاً (80 بت)، أو نصف hash SHA-1. I2P يستخدم 52 حرفاً (256 بت) لتمثيل hash SHA-256 الكامل. الشكل هو {52 chars}.b32.i2p. Tor لديه اقتراح للتحويل إلى تنسيق مطابق {52 chars}.onion لخدماتهم المخفية. Base32 مُطبق في خدمة التسمية، والتي تستعلم router عبر I2CP للبحث عن leaseSet للحصول على Destination الكامل. عمليات البحث Base32 ستنجح فقط عندما يكون Destination نشطاً وينشر leaseSet. لأن الحلول قد تتطلب البحث في قاعدة بيانات الشبكة، فقد تستغرق وقتاً أطول بكثير من البحث المحلي في دفتر العناوين.

يمكن استخدام عناوين Base32 في معظم الأماكن التي تُستخدم فيها أسماء المضيفين أو الوجهات الكاملة، ولكن هناك بعض الاستثناءات حيث قد تفشل إذا لم يتم حل الاسم فوراً. سيفشل I2PTunnel، على سبيل المثال، إذا لم يتم حل الاسم إلى وجهة.

أسماء Base32 الموسعة

تم تقديم أسماء الأساس 32 الموسعة في الإصدار 0.9.40 لدعم leaseSet المشفرة. يتم تحديد عناوين leaseSet المشفرة بـ 56 حرفاً مُرمزاً أو أكثر، لا يشمل “.b32.i2p” (35 بايت مفكوك أو أكثر)، مقارنة بـ 52 حرفاً (32 بايت) لعناوين الأساس 32 التقليدية. راجع المقترحات 123 و 149 للحصول على معلومات إضافية.

عناوين Standard Base 32 (“b32”) تحتوي على hash الخاص بالوجهة. هذا لن يعمل مع encrypted ls2 (اقتراح 123).

لا يمكنك استخدام عنوان base 32 تقليدي لـ encrypted LS2 (اقتراح 123)، حيث أنه يحتوي فقط على hash الوجهة. لا يوفر المفتاح العام غير المُعمى. يجب على العملاء معرفة المفتاح العام للوجهة، ونوع التوقيع، ونوع التوقيع المُعمى، ومفتاح سري أو خاص اختياري لجلب وفك تشفير الـ leaseset. لذلك، عنوان base 32 وحده غير كافٍ. يحتاج العميل إما إلى الوجهة الكاملة (التي تحتوي على المفتاح العام)، أو المفتاح العام بذاته. إذا كان لدى العميل الوجهة الكاملة في دفتر العناوين، ودفتر العناوين يدعم البحث العكسي بواسطة الـ hash، فيمكن عندئذ استرداد المفتاح العام.

لذا نحتاج إلى تنسيق جديد يضع المفتاح العام بدلاً من القيمة المجزأة (hash) في عنوان base32. يجب أن يحتوي هذا التنسيق أيضاً على نوع التوقيع للمفتاح العام، ونوع التوقيع لمخطط التعمية (blinding scheme).

يوثق هذا القسم تنسيق b32 جديد لهذه العناوين. بينما أشرنا إلى هذا التنسيق الجديد أثناء المناقشات كعنوان “b33”، فإن التنسيق الجديد الفعلي يحتفظ باللاحقة المعتادة “.b32.i2p”.

الإنشاء والترميز

أنشئ اسم مضيف من {56+ حرف}.b32.i2p (35+ حرف في النظام الثنائي) كما يلي. أولاً، أنشئ البيانات الثنائية التي سيتم ترميزها بـ base 32:

flag (1 byte)
  bit 0: 0 for one-byte sigtypes, 1 for two-byte sigtypes
  bit 1: 0 for no secret, 1 if secret is required
  bit 2: 0 for no per-client auth,
         1 if client private key is required
  bits 7-3: Unused, set to 0

public key sigtype (1 or 2 bytes as indicated in flags)
  If 1 byte, the upper byte is assumed zero

blinded key sigtype (1 or 2 bytes as indicated in flags)
  If 1 byte, the upper byte is assumed zero

public key
  Number of bytes as implied by sigtype

المعالجة اللاحقة والمجموع التحققي:

Construct the binary data as above.
Treat checksum as little-endian.
Calculate checksum = CRC-32(data[3:end])
data[0] ^= (byte) checksum
data[1] ^= (byte) (checksum >> 8)
data[2] ^= (byte) (checksum >> 16)

hostname = Base32.encode(data) || ".b32.i2p"

أي بتات غير مستخدمة في نهاية b32 يجب أن تكون 0. لا توجد بتات غير مستخدمة لعنوان قياسي مكون من 56 حرفاً (35 بايت).

فك التشفير والتحقق

Strip the ".b32.i2p" from the hostname
data = Base32.decode(hostname)
Calculate checksum = CRC-32(data[3:end])
Treat checksum as little-endian.
flags = data[0] ^ (byte) checksum
if 1 byte sigtypes:
  pubkey sigtype = data[1] ^ (byte) (checksum >> 8)
  blinded sigtype = data[2] ^ (byte) (checksum >> 16)
else (2 byte sigtypes) :
  pubkey sigtype = data[1] ^ ((byte) (checksum >> 8)) || data[2] ^ ((byte) (checksum >> 16))
  blinded sigtype = data[3] || data[4]
parse the remainder based on the flags to get the public key

بتات المفتاح السري والخاص

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

ملاحظات

  • عملية XOR للبايتات الثلاثة الأولى مع الـ hash توفر قدرة محدودة على التحقق من الصحة، وتضمن أن جميع رموز base32 في البداية عشوائية. فقط عدد قليل من تركيبات العلم و sigtype صالحة، لذا أي خطأ إملائي من المحتمل أن ينشئ تركيبة غير صالحة وسيتم رفضه.
  • في الحالة المعتادة (1 بايت sigtypes، لا secret، لا per-client auth)، سيكون اسم المضيف {56 chars}.b32.i2p، يُفكك إلى 35 بايت، نفس Tor.
  • معدل النتائج السلبية الخاطئة لـ checksum بايتين في Tor هو 1/64K. مع 3 بايتات، ناقصاً بعض البايتات المتجاهلة، معدلنا يقترب من 1 في المليون، حيث أن معظم تركيبات flag/sigtype غير صالحة.
  • Adler-32 خيار سيء للمدخلات الصغيرة، ولاكتشاف التغييرات الصغيرة. نستخدم CRC-32 بدلاً من ذلك. CRC-32 سريع ومتاح على نطاق واسع.
  • بينما هذا خارج نطاق هذه المواصفة، يجب على الـ routers و/أو العملاء تذكر وتخزين (ربما بشكل دائم) ربط المفتاح العام بالوجهة، والعكس.
  • التمييز بين النكهات القديمة والجديدة بالطول. عناوين b32 القديمة دائماً {52 chars}.b32.i2p. الجديدة {56+ chars}.b32.i2p
  • موضوع نقاش Tor موجود هنا
  • لا تتوقع أن تحدث sigtypes بايتين أبداً، نحن وصلنا فقط إلى 13. لا حاجة للتنفيذ الآن.
  • يمكن استخدام التنسيق الجديد في jump links (وتقديمها بواسطة jump servers) إذا أردت، تماماً مثل b32.
  • أي secret أو مفتاح خاص أو مفتاح عام أطول من 32 بايت سيتجاوز الحد الأقصى لطول تسمية DNS البالغ 63 حرفاً. المتصفحات ربما لا تهتم.
  • لا توجد مشاكل التوافق مع الإصدارات السابقة. عناوين b32 الأطول ستفشل في التحويل إلى hashes بطول 32 بايت في البرامج القديمة.

Was this page helpful?