نظرة عامة
هذا الاقتراح يضيف نوع توقيع جديد باستخدام BLAKE2b-512 مع سلاسل التخصيص والأملاح، لاستبدال SHA-512. هذا سيقضي على ثلاث فئات من الهجمات المحتملة.
الدافع
أثناء المناقشات والتصميم الخاص بـ NTCP2 (الاقتراح 111) و LS2 (الاقتراح 123)، نظرنا بإيجاز في هجمات مختلفة كانت ممكنة، وكيفية منعها. ثلاث من هذه الهجمات هي هجمات تمديد الطول، والهجمات عبر البروتوكولات، وتحديد الرسائل المكررة.
بالنسبة لكل من NTCP2 و LS2، قررنا أن هذه الهجمات لم تكن ذات صلة مباشرة بالمقترحات المطروحة، وأن أي حلول تتعارض مع هدف تقليل البدائيات الجديدة إلى أدنى حد. كما حددنا أن سرعة دوال التشفير (hash functions) في هذه البروتوكولات لم تكن عاملاً مهماً في قراراتنا. لذلك، أجلنا في الغالب الحل إلى مقترح منفصل. وبينما أضفنا بعض ميزات التخصيص إلى مواصفات LS2، لم نطلب أي دوال تشفير جديدة.
العديد من المشاريع، مثل ZCash، تستخدم دوال التشفير وخوارزميات التوقيع القائمة على خوارزميات أحدث غير معرضة للهجمات التالية.
Length Extension Attacks
SHA-256 و SHA-512 معرضان لـ هجمات تمديد الطول (LEA). هذا هو الحال عندما يتم توقيع البيانات الفعلية، وليس hash البيانات. في معظم بروتوكولات I2P (streaming، datagrams، netdb، وأخرى)، يتم توقيع البيانات الفعلية. الاستثناء الواحد هو ملفات SU3، حيث يتم توقيع الـ hash. والاستثناء الآخر هو datagrams الموقعة لـ DSA (sig type 0) فقط، حيث يتم توقيع الـ hash. بالنسبة لأنواع datagram sig الأخرى الموقعة، يتم توقيع البيانات.
Cross-Protocol Attacks
البيانات الموقعة في بروتوكولات I2P قد تكون معرضة لهجمات البروتوكول المتقاطع (CPA) بسبب عدم وجود فصل بين النطاقات. هذا يسمح للمهاجم باستخدام البيانات المستلمة في سياق واحد (مثل datagram موقع) وتقديمها كبيانات صالحة وموقعة في سياق آخر (مثل streaming أو قاعدة بيانات الشبكة). بينما من غير المحتمل أن يتم تحليل البيانات الموقعة من سياق واحد كبيانات صالحة في سياق آخر، فإنه من الصعب أو المستحيل تحليل جميع الحالات للتأكد من ذلك. بالإضافة إلى ذلك، في بعض السياقات، قد يكون من الممكن للمهاجم حث الضحية على توقيع بيانات مصممة خصيصاً والتي يمكن أن تكون بيانات صالحة في سياق آخر. مرة أخرى، من الصعب أو المستحيل تحليل جميع الحالات للتأكد من ذلك.
هجمات تمديد الطول
بروتوكولات I2P قد تكون عرضة لهجمات تحديد الرسائل المكررة (DMI). قد يسمح هذا للمهاجم بتحديد أن رسالتين موقعتين لهما نفس المحتوى، حتى لو كانت هذه الرسائل وتوقيعاتها مشفرة. بينما هذا غير محتمل نظراً لطرق التشفير المستخدمة في I2P، إلا أنه من الصعب أو المستحيل تحليل جميع الحالات للتأكد من ذلك. باستخدام دالة hash توفر طريقة لإضافة salt عشوائي، ستكون جميع التوقيعات مختلفة حتى عند توقيع نفس البيانات. بينما Red25519 كما هو معرف في المقترح 123 يضيف salt عشوائي لدالة الـ hash، هذا لا يحل المشكلة بالنسبة لمجموعات leaseSet غير المشفرة.
هجمات البروتوكولات المتقاطعة
بينما هذا ليس دافعاً أساسياً لهذا الاقتراح، إلا أن SHA-512 بطيء نسبياً، وتتوفر دوال hash أسرع.
Goals
- منع الهجمات المذكورة أعلاه
- تقليل استخدام primitives التشفير الجديدة
- استخدام primitives التشفير القياسية والمثبتة
- استخدام المنحنيات القياسية
- استخدام primitives أسرع إذا كانت متاحة
Design
قم بتعديل نوع التوقيع RedDSA_SHA512_Ed25519 الحالي لاستخدام BLAKE2b-512 بدلاً من SHA-512. أضف سلاسل تخصيص فريدة لكل حالة استخدام. يمكن استخدام نوع التوقيع الجديد لكل من leasesets غير المحجوبة والمحجوبة.
Justification
- BLAKE2b غير معرض لهجمات LEA.
- يوفر BLAKE2b طريقة معيارية لإضافة نصوص التخصيص لفصل النطاقات
- يوفر BLAKE2b طريقة معيارية لإضافة ملح عشوائي لمنع DMI.
- BLAKE2b أسرع من SHA-256 و SHA-512 (و MD5) على الأجهزة الحديثة، وفقاً لـ مواصفات BLAKE2.
- Ed25519 لا يزال أسرع نوع توقيع لدينا، أسرع بكثير من ECDSA، على الأقل في Java.
- Ed25519 يتطلب دالة تشفير تجميعية بحجم 512 بت. لا يحدد SHA-512. BLAKE2b مناسب تماماً لدالة التجميع.
- BLAKE2b متاح على نطاق واسع في مكتبات العديد من لغات البرمجة، مثل Noise.
Specification
استخدم BLAKE2b-512 غير المُفتاح كما في مواصفات BLAKE2 مع salt وpersonalization. جميع استخدامات توقيعات BLAKE2b ستستخدم سلسلة personalization مكونة من 16 حرف.
عند الاستخدام في توقيع RedDSA_BLAKE2b_Ed25519، يُسمح بملح عشوائي، ولكنه ليس ضرورياً، حيث أن خوارزمية التوقيع تضيف 80 بايت من البيانات العشوائية (انظر الاقتراح 123). إذا رغبت في ذلك، عند تجزئة البيانات لحساب r، قم بتعيين ملح BLAKE2b عشوائي جديد بحجم 16 بايت لكل توقيع. عند حساب S، أعد تعيين الملح إلى الافتراضي وهو كله أصفار.
عند الاستخدام في التحقق من RedDSA_BLAKE2b_Ed25519، لا تستخدم salt عشوائي، استخدم الافتراضي وهو كله أصفار.
ميزات الملح والتخصيص غير محددة في RFC 7693؛ استخدم تلك الميزات كما هو محدد في مواصفات BLAKE2.
تحديد الرسائل المكررة
بالنسبة لـ RedDSA_BLAKE2b_Ed25519، استبدل دالة التجزئة SHA-512 في RedDSA_SHA512_Ed25519 (نوع التوقيع 11، كما هو محدد في الاقتراح 123) بـ BLAKE2b-512. لا توجد تغييرات أخرى.
لا نحتاج إلى بديل لـ EdDSA_SHA512_Ed25519ph (نوع التوقيع 8) لملفات su3، لأن الإصدار المُهاش مسبقاً من EdDSA غير معرض لـ LEA. EdDSA_SHA512_Ed25519 (نوع التوقيع 7) غير مدعوم لملفات su3.
| Type | Type Code | Since | Usage |
|---|---|---|---|
| RedDSA_BLAKE2b_Ed25519 | 12 | TBD | For Router Identities, Destinations and encrypted leasesets only; never used for Router Identities |
السرعة
ينطبق ما يلي على نوع التوقيع الجديد.
| Data Type | Length |
|---|---|
| Hash | 64 |
| Private Key | 32 |
| Public Key | 32 |
| Signature | 64 |
Personalizations
لتوفير فصل النطاقات للاستخدامات المختلفة للتوقيعات، سنستخدم ميزة التخصيص في BLAKE2b.
جميع استخدامات توقيعات BLAKE2b ستستخدم سلسلة تخصيص مكونة من 16 حرف. أي استخدامات جديدة يجب إضافتها إلى الجدول هنا، مع تخصيص فريد.
عملية المصافحة لـ NTCP 1 و SSU المستخدمة أدناه مخصصة للبيانات الموقعة المُعرَّفة في المصافحة نفسها. RouterInfos الموقعة في رسائل DatabaseStore ستستخدم تخصيص إدخال NetDb، تماماً كما لو كانت مُخزنة في NetDB.
| Usage | 16 Byte Personalization |
|---|---|
| I2CP SessionConfig | “I2CP_SessionConf” |
| NetDB Entries (RI, LS, LS2) | “network_database” |
| NTCP 1 handshake | “NTCP_1_handshake” |
| Signed Datagrams | “sign_datagramI2P” |
| Streaming | “streaming_i2psig” |
| SSU handshake | “SSUHandshakeSign” |
| SU3 Files | n/a, not supported |
| Unit tests | “test1234test5678” |
الأهداف
التصميم
- البديل 1: الاقتراح 146؛ يوفر مقاومة LEA
- البديل 2: Ed25519ctx في RFC 8032؛ يوفر مقاومة LEA والتخصيص. موحد معياريًا، لكن هل يستخدمه أحد؟ انظر RFC 8032 وهذه المناقشة.
- هل التقطيع “المفاتيحي” مفيد لنا؟
المبرر
نفس الأمر كما هو الحال مع طرح أنواع التوقيع السابقة.
نخطط لتغيير routers الجديدة من النوع 7 إلى النوع 12 كافتراضي. نخطط لترحيل routers الموجودة في النهاية من النوع 7 إلى النوع 12، باستخدام عملية “إعادة تكوين المفاتيح” المستخدمة بعد تقديم النوع 7. نخطط لتغيير الوجهات الجديدة من النوع 7 إلى النوع 12 كافتراضي. نخطط لتغيير الوجهات المشفرة الجديدة من النوع 11 إلى النوع 13 كافتراضي.
سندعم التشويش (blinding) من الأنواع 7 و 11 و 12 إلى النوع 12. لن ندعم تشويش النوع 12 إلى النوع 11.
يمكن لـ routers الجديدة أن تبدأ في استخدام نوع التوقيع الجديد افتراضياً بعد بضعة أشهر. يمكن للوجهات الجديدة أن تبدأ في استخدام نوع التوقيع الجديد افتراضياً بعد عام تقريباً.
بالنسبة لأدنى إصدار router 0.9.TBD، يجب على أجهزة router أن تضمن:
- لا تخزن (أو تغرق) RI أو LS مع نوع التوقيع الجديد إلى routers أقل من الإصدار 0.9.TBD.
- عند التحقق من تخزين netDb، لا تجلب RI أو LS مع نوع التوقيع الجديد من routers أقل من الإصدار 0.9.TBD.
- قد لا تتصل routers التي تحتوي على نوع توقيع جديد في RI الخاص بها بـ routers أقل من الإصدار 0.9.TBD، سواء باستخدام NTCP أو NTCP2 أو SSU.
- لن تعمل اتصالات Streaming والـ datagrams الموقعة مع routers أقل من الإصدار 0.9.TBD، ولكن لا توجد طريقة لمعرفة ذلك، لذا يجب عدم استخدام نوع التوقيع الجديد افتراضياً لفترة من الأشهر أو السنوات بعد إصدار 0.9.TBD.