الخلاصة

  • RFC 10042 وثيقة معلوماتية صادرة عن IETF شارك في تأليفها Panos Kampanakis وDouglas Stebila وTorben Hansen، وتعرّف ثلاث طرق تجمع ML-KEM مع P-256 أو P-384 أو X25519 في تبادل مفاتيح SSH.
  • لا تزال استجابة الخادم الهجينة تحمل مفتاح المضيف العام وتوقيعاً على ملخص التبادل. وبعد تشغيل مفاتيح النقل يبدأ بروتوكول آخر لمصادقة المستخدم، لذلك يحتاج KEX وهوية الخادم وهوية المستخدم إلى أدلة مستقلة.
  • يفصل سجل SFTP نشرته AWS بين الخوارزمية الهجينة وخوارزمية مفتاح المضيف وبصمته، ثم يسجل لاحقاً مصادقة المستخدم بالمفتاح العام.

تعرض شاشة SSH في النهاية نتيجة قصيرة: اتصل العميل، أو بدأت عملية نقل الملف. أما السجل التفصيلي فيروي ثلاث قصص أمنية متتابعة.

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

تعالج RFC 10042 القصة الأولى. نُشرت في أغسطس 2026 ضمن الفئة Informational، وتحدد mlkem768nistp256-sha256 وmlkem1024nistp384-sha384 وmlkem768x25519-sha256. تجمع كل طريقة سراً من ML-KEM مع سر من تبادل تقليدي على منحنى إهليلجي.

الهدف هو تقليل خطر جمع المرور المشفر اليوم لفكّه في المستقبل. قد يحتفظ خصم بالجلسة وينتظر قدرة كمّية تكسر إنشاء المفاتيح التقليدي. يربط البناء الهجين سر النقل بعائلتين بدلاً من عائلة واحدة. هذه نتيجة مهمة، لكن مجالها يظل محدداً.

مفتاح المضيف لم يختفِ

تُظهر صيغة الرسالة الحد بوضوح. يرسل العميل مواده العامة المؤقتة التقليدية وبعد-الكمّية. ويرد الخادم بنص ML-KEM المشفر وقيمته التقليدية، إضافة إلى K_S، أي مفتاح المضيف العام، وتوقيع على ملخص التبادل.

يُشتق السر K من ملخص ربط السر بعد-الكمّي بالسر التقليدي. ويشمل ملخص التبادل معرفات البرنامج لدى الطرفين ورسائل SSH_MSG_KEXINIT ومفتاح المضيف وقيم التبادل الهجين وK. يوقع الخادم هذا الملخص بمفتاح المضيف الخاص.

تربط هذه البنية العمليتين داخل transcript واحد من دون دمجهما. ينشئ KEX أسرار النقل الجديدة؛ أما التوقيع فيربط النص بمفتاح خادم. ويبقى على العميل أن يعرف سبب ثقته في أن المفتاح يخص الخادم المطلوب.

تفصل RFC 4253 بين قائمتي kex_algorithms وserver_host_key_algorithms. يمكن أن تأتي الثقة من ملف known_hosts أو بصمة تم التحقق منها خارج القناة أو شهادة. وتحذر الوثيقة من أن قبول المفتاح من دون تحقق يبقي الاتصال معرضاً للهجوم النشط. لا تعالج ML-KEM قرار هوية تم تجاوزه.

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

المستخدم يمر من بوابة أخرى

بعد إنشاء النقل تتغير جهة السؤال. كان العميل يتحقق من الخادم؛ الآن يتحقق الخادم من المستخدم. تعرّف RFC 4252 بروتوكول المصادقة فوق طبقة النقل. يجب على التطبيقات دعم publickey، ويمكنها دعم كلمة المرور وhostbased وطرق إضافية.

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

هذه ليست إعادة لمفتاح المضيف. مفتاح المضيف يساعد العميل على التعرف إلى الخادم؛ ومفتاح المستخدم يساعد الخادم على التعرف إلى شخص أو عملية آلية. ملفات authorized_keys ودليل الهوية والحسابات المعطلة والمصادقة المتعددة والعناوين المقيدة وصلاحيات SFTP كلها تقع خارج اسم ML-KEM.

قد تختار المؤسسة ترقية KEX أولاً، ثم توقيعات المضيف، ثم بيانات اعتماد المستخدم. المراحل ليست عيباً. العيب أن تُحتسب نتيجة المرحلة الأولى دليلاً على اكتمال المرحلتين الأخريين.

سجل AWS يقسم النتيجة إلى ثلاثة أعمدة

توفر مقالة AWS عن SFTP الهجين مثالاً تشغيلياً مفيداً. استخدم المثال الأصلي لعام 2023 أسماء تجريبية مبنية على Kyber. ثم أوضح تحديث مؤرخ في 5 سبتمبر 2025 أن سياستين في AWS Transfer Family انتقلتا إلى ML-KEM، وسرد الطرق الثلاث التي ظهرت لاحقاً في RFC 10042.

لا يجوز وصف السجل القديم بأنه جلسة RFC 10042. قيمته أنه يكشف ترتيب الأدلة. يذكر أولاً KEX الهجين، ثم يسجل ssh-ed25519 بوصفه خوارزمية مفتاح المضيف ويعرض بصمة الخادم. وبعد ذلك فقط تظهر مصادقة المستخدم بطريقة publickey، ثم تُفتح جلسة SFTP.

يمكن للمشغل بناء ثلاث أسئلة قابلة للتكرار:

  1. ما الطرق المعروضة، وما الطريقة المختارة فعلياً، وهل دخلت المفاتيح الجديدة الخدمة؟
  2. أي مفتاح مضيف وقّع التبادل، وبأي قاعدة وثق فيه العميل؟
  3. أي طريقة مستخدم نجحت، ولأي حساب وبأي حدود تفويض؟

تثبت كلمة «متصل» أن قناة فُتحت. لكنها لا تثبت أن صلاحيات الملف محدودة أو أن البيانات مشفرة عند التخزين أو أن السجلات والنسخ الاحتياطية والاستعادة سليمة.

كما يكشف الانتقال من أسماء Kyber التجريبية إلى ML-KEM عن مشكلة دورة حياة البرمجيات. لا تُحدّث الخوادم والعملاء والأجهزة المضمنة والبرامج الآلية في الوقت نفسه. يحدد الإصدار وترتيب الأفضلية والرجوع التوافقي ما يحدث في كل جلسة. تسجيل IANA مع SHOULD ينسق التطبيقات ولا يقيس الانتشار العالمي.

قوة المعيار في حدوده

تعرّف Amazon Science Kampanakis بأنه principal security engineer في AWS يعمل في التشفير التطبيقي وأتمتة الأمن والمعايير. وفي مقابلة AWS لعام 2023 دعا إلى جرد استخدام التشفير غير المتماثل، واختبار أثر الخوارزميات الجديدة في حالات مثل SSH، والحفاظ على مرونة تغيير الخوارزمية. كما فصل بين نموذج تجريبي مضبوط والتزام طويل الأمد على نطاق واسع.

يوضح هذا السياق طبيعة العمل ولا يمنحه ملكية فردية. Stebila وHansen مؤلفان مشاركان. وتشكر الوثيقة مساهمات في التطبيق والمراجعة من AWS وOpenSSH وPuTTY وغيرهم. وضع NIST معيار ML-KEM، بينما يوفر IETF وسجل IANA الإحداثيات المشتركة.

تحدد RFC 10042 الحد الأدنى القابل للاختبار: الرسائل، وطريقة جمع الأسرار، والترميز ثابت الطول، والتحقق من المدخلات، والمفاتيح المؤقتة لكل اتصال، وعدم إعادة استخدام عشوائية ciphertext، والانقطاع عند الفشل. بهذا تصبح نية الهجرة عقداً للتشغيل البيني.

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

يشمل الإيصال العملي إصدارات الطرفين، والطرق المعروضة والمختارة، وخوارزمية المضيف وبصمته، وقرار الثقة، والتشفير وMAC، وNEWKEYS، وطريقة المستخدم، والتفويض، والقناة المفتوحة، وإعادة توليد المفاتيح، والرجوع، والفشل وحدود القياس.

تعزز RFC 10042 الإيصال الأول. أما احترام الإنجاز فيعني إبقاء إيصالَي الهوية مفتوحين حتى يقدما أدلتهما الخاصة.

المصادر