الخلاصة

  • يسجل RFC 10042 ثلاث طرق SSH تجمع ML-KEM مع P-256 أو P-384 أو X25519 وتشتق سراً واحداً من النتيجتين.
  • دعم البرنامج لا يثبت الاستخدام؛ الدليل هو الطريقة التي اختارتها كل جلسة ونتيجة الفشل وحالة المصادقة.

خوارزميتان وطريقة واحدة متفاوض عليها

يعالج RFC 10042 خطر جمع المرور الآن لفك تشفيره لاحقاً. ويعرّف mlkem768nistp256-sha256 وmlkem1024nistp384-sha384 وmlkem768x25519-sha256. يمثل كل اسم طريقة SSH واحدة، لكنها تنفذ تبادل ECDH التقليدي وتغليف ML-KEM معاً.

يرسل العميل المواد العامة ما بعد الكمّية والتقليدية بعد وصلها. ويرد الخادم بنص ML-KEM المشفر ومفتاحه التقليدي العام ومفتاح المضيف وتوقيع التبادل. يجب التحقق من الأطوال المتوقعة، وتؤدي حالات الفشل المحددة إلى إنهاء التبادل. ويُدمج السرّان وفق K = HASH(K_PQ || K_CL) بترميز ثابت الطول.

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

الهجين لا يستبدل المصادقة

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

يشترط RFC إنشاء أزواج مفاتيح مؤقتة جديدة لـ ECDH وML-KEM لكل اتصال، ويحظر إعادة استخدام العشوائية عند إنشاء نصوص ML-KEM المشفرة. كما يحدد ترميزاً ثابت الطول للأسرار للحد من التسرب الزمني المرتبط بتغير الطول.

الحجم مضبوط لكن التشغيل ليس مجانياً

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

المستفيدون هم الجلسات التي يلزم أن تستمر سريتها بعد عمر الافتراضات التقليدية الحالية. تتحمل فرق العملاء والخوادم وبوابات الإدارة والأتمتة والمكتبات التكلفة. البديل التقليدي أبسط لكنه بلا ML-KEM؛ والبديل ما بعد الكمّي وحده يزيل التحوط التقليدي وليس ما يحدده RFC 10042.

المصادر