ملاحظة
تم تنفيذ ECIES إلى ElG في الإصدار 0.9.46 وتمت إغلاق مرحلة الاقتراح. انظر I2NP للحصول على المواصفات الرسمية. قد يتم الرجوع إلى هذا الاقتراح للحصول على معلومات خلفية. تم تنفيذ ECIES إلى ECIES مع تضمين المفاتيح بدءاً من الإصدار 0.9.48. قد يتم إعادة فتح قسم ECIES-to-ECIES (المفاتيح المشتقة) أو دمجه في اقتراح مستقبلي.
نظرة عامة
تعاريف
- AEAD: ChaCha20/Poly1305
- DLM: رسالة بحث قاعدة بيانات I2NP
- DSM: رسالة تخزين قاعدة بيانات I2NP
- DSRM: رسالة رد بحث قاعدة بيانات I2NP
- ECIES: ECIES-X25519-AEAD-Ratchet (الاقتراح 144)
- ElG: ElGamal
- ENCRYPT(k, n, payload, ad): كما هو معرّف في ECIES
- LS: مجموعة التأجير
- lookup: رسالة DLM لـ I2NP
- reply: DSM أو DSRM لـ I2NP
الملخص
عند إرسال DLM لمجموعة تأجير إلى floodfill، فإن DLM يحدد بشكل عام أن الرد يكون موسومًا، مشفرًا بـ AES، ويتم إرساله عبر نفق إلى الوجهة. تم إضافة دعم الردود المشفرة بـ AES في الإصدار 0.9.7.
تم تحديد الردود المشفرة بـ AES في الإصدار 0.9.7 لتقليل العبء الكبير المشفر لـ ElG، ولأنها أعادت استخدام مكتبونات AES في ElGamal/AES+SessionTags. ومع ذلك، قد يتم التلاعب بردود AES في IBEP حيث لا يوجد مصادقة، والردود ليست سرية أمامية.
مع وجهات [ECIES]، كانت النية من الاقتراح 144 هي أن الوجهات لم تعد تدعم علامات بـ 32-بايت وفك تشفير AES. لم يتم تضمين التفاصيل عمدًا في ذلك الاقتراح.
يوثق هذا الاقتراح خيارًا جديدًا في DLM لطلب ردود مشفرة بـ ECIES.
الأهداف
- أعلام جديدة لـ DLM عند طلب رد مشفر عبر نفق إلى وجهة ECIES
- للرد، إضافة سرية أمامية ومصادقة المرسل المقاومة لانتحال شخصية (KCI) بمفتاح طالب الخدمة (الوجهة).
- الحفاظ على عدم الكشف عن هوية طالب الخدمة
- تقليل العبء المشفر
الأهداف غير المتعلقة
- لا تغيير لتشفير أو خصائص الأمان الخاصة بالبحث (DLM). البحث لديه سرية أمامية لانتحال شخصية مفتاح طالب الخدمة فقط. التشفير إلى مفتاح ثابت للـ floodfill.
- لا توجد مشكلات تتعلق بالسرية الأمامية أو مصادقة المرسل مقاومة لانتحال شخصية بمفتاح المجيب (floodfill). Floodfill هو قاعدة بيانات عامة وستستجيب للبحث من أي شخص.
- لا تصمم أجهزة التوجيه ECIES في هذا الاقتراح. مكان وكيفية نشر المفتاح العام X25519 الخاص بجهاز التوجيه هو TBD.
البدائل
في غياب طريقة محددة لتشفير الردود على وجهات ECIES، هناك عدة بدائل:
عدم طلب ردود مشفرة. ستكون الردود غير مشفرة. حاليًا يستخدم Java I2P هذا النهج.
إضافة دعم لعلامات بـ 32-بايت وردود مشفرة بـ AES إلى وجهات ECIES فقط، وطلب ردود مشفرة بـ AES كالمعتاد. يستخدم i2pd حاليًا هذا النهج.
طلب ردود مشفرة بـ AES كالمعتاد، ولكن إعادة توجيهها عبر الأنفاق الاستكشافية لجهاز التوجيه. حاليًا يستخدم Java I2P هذا النهج في بعض الحالات.
للوجهات المزدوجة ElG و ECIES، طلب ردود مشفرة بـ AES كالمعتاد. يستخدم Java I2P حاليًا هذا النهج. لم يقم i2pd بعد بتنفيذ وجهات مزدوجة التشفير.
التصميم
سيضيف تنسيق DLM الجديد بتًا إلى حقل الأعلام لتحديد الردود المشفرة بـ ECIES. ستستخدم الردود المشفرة بـ ECIES تنسيق الرسائل للدورة القائمة [ECIES]، مع علامة ملحقة وحمولة ChaCha/Poly وماك.
تحديد نوعين مختلفين. واحد لأجهزة التوجيه ElG، حيث لا يمكن إجراء عملية DH، وواحد لأجهزة التوجيه ECIES المستقبلية، حيث يمكن أن توفر عملية DH أمانًا إضافيًا. لدراسة لاحقة.
لا يمكن إجراء DH للردود من أجهزة التوجيه ElG لأنها لا تنشر مفتاح عام X25519.
المواصفات
في مواصفات DLM (بحث قاعدة البيانات) في [I2NP]، قم بإجراء التغييرات التالية.
أضف علم البت 4 “ECIESFlag” لخيارات التشفير الجديدة.
flags ::
bit 4: ECIESFlag
قبل الإصدار 0.9.46 غير محكمة
اعتبارًا من الإصدار 0.9.46:
0 => إرسال رد غير مشفر أو ElGamal
1 => إرسال رد مشفر بـ ChaCha/Poly باستخدام المفتاح المرفق
(سواء كانت العلامة مرفقة يعتمد على البت 1)
يستخدم علم البت 4 بالاشتراك مع البت 1 لتحديد وضع تشفير الرد. يجب تعيين علم البت 4 فقط عند الإرسال إلى أجهزة التوجيه بإصدار 0.9.46 أو أحدث.
في الجدول أدناه، “DH n/a” تعني أن الرد غير مشفر. “DH no” تعني أن مفاتيح الرد مضمنة في الطلب. “DH yes” تعني أن مفاتيح الرد مشتقة من عملية DH.
============= ========= ========= ====== === ======= Flag bits 4,1 From Dest To Router Reply DH? notes ============= ========= ========= ====== === ======= 0 0 أي أي بدون تشفير n/a الحالي 0 1 ElG ElG AES no الحالي 0 1 ECIES ElG AES no حل i2pd الاحتياطي 1 0 ECIES ElG AEAD no هذا الاقتراح 1 0 ECIES ECIES AEAD no إصدار 0.9.49 1 1 ECIES ECIES AEAD yes مستقبل ============= ========= ========= ====== === =======
ElG إلى ElG
تقوم وجهة ElG بإرسال بحث إلى جهاز توجيه ElG.
تغييرات طفيفة على المواصفات للتحقق من البت الجديد 4. لا توجد تغييرات على التنسيق الثنائي الحالي.
توليد مفتاح طالب الخدمة (إيضاح):
reply_key :: CSRNG(32) 32 بايت من البيانات العشوائية
reply_tags :: Each is CSRNG(32) 32 بايت من البيانات العشوائية
تنسيق الرسالة (أضف تحقق من ECIESFlag):
reply_key ::
32 بايت `SessionKey` بتسلسل كبير
فقط إذا كان encryptionFlag == 1 AND ECIESFlag == 0، فقط اعتبارًا من الإصدار 0.9.7
tags ::
1 بايت `Integer`
النطاق الصحيح: 1-32 (عادة 1)
عدد علامات الرد التالية
فقط إذا كان encryptionFlag == 1 AND ECIESFlag == 0، فقط اعتبارًا من الإصدار 0.9.7
reply_tags ::
واحدة أو أكثر من 32 بايت `SessionTag`s (عادة واحدة)
فقط إذا كان encryptionFlag == 1 AND ECIESFlag == 0، فقط اعتبارًا من الإصدار 0.9.7
ECIES إلى ElG
تقوم وجهة ECIES بإرسال بحث إلى جهاز توجيه ElG. يتم دعمه اعتبارًا من الإصدار 0.9.46.
يتم إعادة تعريف حقول reply_key و reply_tags لرد ECIES المشفر.
توليد مفتاح طالب الخدمة:
reply_key :: CSRNG(32) 32 بايت من البيانات العشوائية
reply_tags :: Each is CSRNG(8) 8 بايت من البيانات العشوائية
تنسيق الرسالة: أعد تعريف حقول reply_key و reply_tags كما يلي:
reply_key ::
32 بايت `SessionKey` ECIES بتسلسل كبير
فقط إذا كان encryptionFlag == 0 AND ECIESFlag == 1، فقط اعتبارًا من الإصدار 0.9.46
tags ::
1 بايت `Integer`
القيمة المطلوبة: 1
عدد علامات الرد التالية
فقط إذا كان encryptionFlag == 0 AND ECIESFlag == 1، فقط اعتبارًا من الإصدار 0.9.46
reply_tags ::
8 بايت `SessionTag` ECIES
فقط إذا كان encryptionFlag == 0 AND ECIESFlag == 1، فقط اعتبارًا من الإصدار 0.9.46
الرد هو رسالة جلسة قائمة على ECIES، كما هو معرّف في ECIES.
tag :: 8 بايت reply_tag
k :: 32 بايت مفتاح الجلسة
مفتاح الرد.
n :: 0
ad :: 8 بايت reply_tag
payload :: بيانات نصية عادية، DSM أو DSRM.
ciphertext = ENCRYPT(k, n, payload, ad)
ECIES إلى ECIES (0.9.49)
وجهة أو جهاز توجيه ECIES يرسل بحثًا إلى جهاز توجيه ECIES، مع مفاتيح رد مدمجة. يتم دعمه اعتبارًا من الإصدار 0.9.49.
تم تقديم أجهزة التوجيه ECIES في الإصدار 0.9.48، انظر Prop156. اعتبارًا من الإصدار 0.9.49، يمكن أن تستخدم وجهات وأجهزة توجيه ECIES نفس التنسيق كما في قسم “ECIES إلى ElG” أعلاه، مع تضمين مفاتيح الرد في الطلب. سوف يستخدم البحث “تنسيق المرة الواحدة” في ECIES نظرًا لأن طالب الخدمة مجهول.
لطريقة جديدة باستخدام المفاتيح المشتقة، انظر القسم التالي.
ECIES إلى ECIES (مستقبل)
وجهة أو جهاز توجيه ECIES يرسل بحثًا إلى جهاز توجيه ECIES، ويتم اشتقاق مفاتيح الرد من DH. لم يتم تعريفه بالكامل أو دعمه، التنفيذ TBD.
سوف يستخدم البحث “تنسيق المرة الواحدة” في ECIES نظرًا لأن طالب الخدمة مجهول.
إعادة تعريف حقل reply_key كما يلي. لا توجد علامات مرتبطة. سيتم توليد العلامات في KDF أدناه.
هذا القسم غير مكتمل ويتطلب دراسة أكبر.
reply_key ::
32 بايت X25519 `PublicKey` وقتي للطالب، بتسلسل صغير
فقط إذا كان encryptionFlag == 1 AND ECIESFlag == 1، فقط اعتبارًا من الإصدار 0.9.TBD
الرد هو رسالة جلسة ECIES قائمة، كما هو معرّف في ECIES. انظر ECIES لجميع التعريفات.
// مفاتيح X25519 المؤقتة لـ Alice
// aesk = مفتاح خاص وقتي لـ Alice
aesk = توليد_خاص()
// aepk = مفتاح عام وقتي لـ Alice
aepk = اشتقاق_عام(aesk)
// مفاتيح X25519 الثابتة لـ Bob
// bsk = مفتاح خاص ثابت لـ Bob
bsk = توليد_خاص()
// bpk = مفتاح عام ثابت لـ Bob
// bpk هو إما جزء من هوية جهاز التوجيه، أو منشور في معلومات جهاز التوجيه (TBD)
bpk = اشتقاق_عام(bsk)
// (DH()
//[chainKey, k] = مزج مفتاح(sharedSecret)
// chainKey من ???
sharedSecret = DH(aesk, bpk) = DH(bsk, aepk)
keydata = HKDF(chainKey, sharedSecret, "ECIES-DSM-Reply1", 32)
chainKey = keydata[0:31]
1) rootKey = chainKey من قسم الحمولة
2) k من KDF للجلسة الجديدة أو split()
// KDF_RK(rk, dh_out)
keydata = HKDF(rootKey, k, "KDFDHRatchetStep", 64)
// مخرجات 1: غير مستخدمة
غير مستخدمة = keydata[0:31]
// مخرجات 2: مفتاح السلسلة لتهيئة الجديد
// جلسة العلامة والمفاتيح المتناظرة للمسننة
// للرسائل من Alice إلى Bob
ck = keydata[32:63]
// مفاتيح سلسلة العلامة والمفاتيح المتناظرة
keydata = HKDF(ck, ZEROLEN, "TagAndKeyGenKeys", 64)
sessTag_ck = keydata[0:31]
symmKey_ck = keydata[32:63]
tag :: علامة بحجم 8 بايت كما تم توليدها من RATCHET_TAG() في [ECIES](/docs/specs/ecies/)
k :: مفتاح بحجم 32 بايت كما تم توليده من RATCHET_KEY() في [ECIES](/docs/specs/ecies/)
n :: فهرس العلامة. عادة 0.
ad :: العلامة بحجم 8 بايت
payload :: بيانات نصية عادية، DSM أو DSRM.
ciphertext = ENCRYPT(k, n, payload, ad)
تنسيق الرد
هذه هي رسالة الجلسة الحالية، نفسها في [ECIES]، منسوخة أدناه كمرجع.
+----+----+----+----+----+----+----+----+
| علامة الجلسة |
+----+----+----+----+----+----+----+----+
| |
+ قسم الحمولة +
| بيانات مشفرة بـ ChaCha20 |
~ ~
| |
+ +
| |
+----+----+----+----+----+----+----+----+
| رمز تحقق الرسائل بـ Poly1305 |
+ (MAC) +
| 16 بايت |
+----+----+----+----+----+----+----+----+
علامة الجلسة :: 8 بايت، نص واضح
بيانات قسم الحمولة المشفرة :: البيانات المتبقية ناقص 16 بايت
MAC :: رمز تحقق الرسائل بـ Poly1305، 16 بايت
التبرير
معلمات تشفير الرد في البحث، التي تم تقديمها لأول مرة في الإصدار 0.9.7، هي انتهاك إلى حد ما للطبقات. يتم ذلك بهذه الطريقة للأكثر فعالية. ولكن أيضًا لأن البحث مجهول.
يمكننا جعل تنسيق البحث عامًا، مثل مع حقل نوع التشفير، لكن هذا ربما يكون أكثر إزعاجًا مما يستحق.
الاقتراح أعلاه هو الأسهل ويقلل من التغيير في تنسيق البحث.
الملاحظات
يجب أن تكون عمليات البحث وتخزين قاعدة البيانات لأجهزة التوجيه ElG مشفرة بـ ElGamal/AES+SessionTag كالمعتاد.
القضايا
يتطلب مزيد من التحليل حول أمان الخيارين للردود الخاصة بـ ECIES.
الترحيل
لا توجد مشاكل توافق مع الإصدارات السابقة. يجب أن تدعم أجهزة التوجيه التي تعلن عن إصدار جهاز التوجيه 0.9.46 أو أحدث هذه الميزة. يجب ألا ترسل أجهزة التوجيه بحثًا عن قاعدة البيانات باستخدام الأعلام الجديدة إلى أجهزة التوجيه بإصدار أقل من 0.9.46. إذا تم إرسال رسالة بحث قاعدة بيانات مع بت 4 معين وبت 1 غير مضبوط إلى جهاز توجيه بدون دعم بالخطأ، فسيقوم على الأرجح بتجاهل المفتاح والعلامة المزودان، وسيتم إرسال الرد غير مشفر.