ثماني حزم MLS تغيّر مفتاح التشفير وتترك توقيع الباب القديم

Summary

• تطلب المراجعة 07 المؤرخة 1 نوفمبر تسجيل إحدى عشرة حزمة في بروتوكول Messaging Layer Security. تجمع الحزم الثماني الأولى بين تغليف مفاتيح مقاوم للكم أو هجين وتوقيع تقليدي، بينما تستخدم الثلاث الأخيرة توقيعات ML-DSA أيضاً.
• تنص المراجعة على إرسال المفتاح العام لـML-DSA بوصفه ناتج pkEncode، وإرسال التوقيع بصيغته المباشرة، وترك معامل ctx فارغاً لأن تسمية MLS موجودة في SignContent الموقّع.

يمكن أن تعني عبارة «MLS مقاوم للكم» عقدين أمنيين مختلفين. نسخة يوليو كانت قد قسمت الحزم إلى ثمانٍ وثلاث. أما نسخة نوفمبر فتشرح كلفة هذا التقسيم. الحزم من 0x0010 إلى 0x0017 تستخدم ML-KEM أو تغليفاً هجيناً لتأسيس السر، لكنها تُبقي توقيعات Ed25519 أو ECDSA. هي تعالج خطر خصم يجمع النصوص المشفرة اليوم كي يفكها لاحقاً.

باب إدارة المجموعة له قفل آخر. إذا استطاع المهاجم تزوير توقيع تقليدي، أو اعتماد يربط مفتاح التوقيع بهوية، فقد يُدخل KeyPackage أو عملية ضمن المجموعة. بذلك يستطيع الإضرار بسرية حقب MLS اللاحقة. حماية الرسائل التي سُجلت بالأمس لا تمنح وحدها ضماناً بشأن من يحدد عضوية المجموعة غداً.

الحزم من 0x0020 إلى 0x0022 تضيف ML-DSA. تجمع الأولى ML-DSA-44 مع ML-KEM/X25519 الهجين وChaCha20-Poly1305، فيما تستخدم الحزمتان الأخريان ML-DSA-65 أو ML-DSA-87 مع ML-KEM خالص. وتضيف المراجعة 07 قاعدة دقيقة للتبادل. حقل SignaturePublicKey في مواصفة MLS، ‏RFC 9420 يحمل بايتات pkEncode نفسها، من دون غلاف SubjectPublicKeyInfo. توقع SignWithLabel محتوى SignContent بعد تسلسله، ويظل ctx فارغاً لأن تسمية MLS داخله تفصل غرض التوقيع. اختلاف الغلاف أو السياق بين المرسل والمتحقق يكسر التحقق، حتى حين يتفقان على اسم الحزمة.

يسجل متتبع IETF المراجعة 07 مسودة نشطة في مرحلة Publication Requested، وغايتها Proposed Standard. لم يُدرج سجله بعد RFC معتمداً أو قياساً لنشرها في تطبيقات. اسم تنفيذ محدد وتجربة توافق بين تطبيقين سيكشفان مدى ثبات هذه القاعدة في البرمجيات.