الخلاصة

  • تعرّف RFC 10024 ثلاث مجموعات في TLS 1.3 هي X25519MLKEM768 وSecP256r1MLKEM768 وSecP384r1MLKEM1024، وتجمع كل مجموعة ML-KEM مع مكوّن تقليدي لإنشاء المفاتيح بالمنحنيات الإهليلجية.
  • يشتق اتفاق المفاتيح سر الجلسة، بينما تصادق سلسلة الشهادة وتوقيع CertificateVerify على الخادم. انتقال العملية الأولى لا يحوّل الثانية ولا المسار اللاحق إلى مقاوم للكمّ.
  • شارك Bas Westerbaan في تأليف الوثيقة مع Krzysztof Kwiatkowski وPanos Kampanakis وDouglas Stebila. تتيح الوثيقة قياس مرحلة محددة من الانتقال، لا إطلاق حكم شامل على الخدمة.

قد تسجل أداة فحص الاتصال أن المجموعة المتفاوض عليها هي X25519MLKEM768، فتعلن أن الاتصال «مشفّر بعد-كمياً». الوصف مفيد إذا بقي مرتبطاً باتفاق المفاتيح. لكنه يصبح أوسع من الدليل عندما يُفهم منه أن شهادة الخادم وتوقيعه وكل قفزة لاحقة قد انتقلت أيضاً.

نُشرت RFC 10024 معياراً مقترحاً من IETF في أغسطس 2026. وهي تمنح TLS 1.3 رموزاً وصيغاً ثابتة لثلاثة تراكيب: X25519 مع ML-KEM-768، وsecp256r1 مع ML-KEM-768، وsecp384r1 مع ML-KEM-1024. يتبادل الطرفان المواد اللازمة للمكوّنين ويكوّنان سراً مشتركاً وفق الترتيب والقواعد المحددة.

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

هذه نتيجة أمنية قوية. لكنها نتيجة لعملية محددة.

وظيفتان داخل سجل مصافحة واحد

يستخدم TLS 1.3 ناتج تبادل المفاتيح في جدول اشتقاق أسرار الحركة. وفي المصافحة المعتمدة على الشهادات، تستخدم سلسلة الثقة وتوقيع CertificateVerify لإثبات هوية الخادم وسيطرته على المفتاح الخاص المرتبط بالشهادة. تدخل العمليتان في transcript واحد، لكنهما لا تجيبان السؤال نفسه.

يسأل اتفاق المفاتيح: كيف كوّن الطرفان سر الاتصال؟ وتسأل المصادقة: من هو الطرف الذي وقّع سجل المصافحة، وهل تثق جهة التحقق في سلسلته؟ لا يتضمن الجواب الأول الجواب الثاني.

تساعد RFC 9794 على منع الخلط. فهي تفصل بين إنشاء المفاتيح الهجين PQ/T، وآليات KEM الهجينة، والتشفير الهجين بالمفتاح العام، والتواقيع الرقمية الهجينة. يمكن لمؤسسة أن تنشر فئة قبل أخرى. كما أن RFC 9935، التي تحدد معرّفات ML-KEM في X.509، لا تنشئ بمفردها منظومة إصدار موثوقة، ولا تجعل ML-KEM خوارزمية توقيع.

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

قيمة الانتقال المرحلي الصريح

تعرّف Cloudflare Research Bas Westerbaan بأنه Research Engineer يعمل على دفع اعتماد التشفير المقاوم للكمّ، من هندسة التشفير والتقييس إلى التجارب واسعة النطاق ثم النشر. ويعرض سجل IETF الرسمي RFC 10024 وأعمالاً أخرى مرتبطة بالمجال.

ينبغي ألا يحجب الملف الشخصي التأليف الجماعي. الوثيقة من تأليف Krzysztof Kwiatkowski وPanos Kampanakis وBas Westerbaan وDouglas Stebila. كما تعتمد على البناء العام في RFC 9954، والمصطلحات في RFC 9794، وبروتوكول TLS 1.3، ومعيار ML-KEM الصادر عن NIST. أهمية Westerbaan هنا هي وصل طبقات المعيار والهندسة والنشر، لا نسب كل الطبقات إليه وحده.

قدمت Cloudflare في سبتمبر 2025 مثالاً واضحاً على الانتقال المرحلي. قالت إن أكثر من ثلث الحركة التي يولدها البشر إلى شبكتها كان يستخدم TLS 1.3 مع اتفاق مفاتيح هجين بعد-كمّي. وفي المقال نفسه أوضحت أن التواقيع والشهادات بعد-الكمّية ما زالت قيد التقييس لاستخدامها في TLS والبنية العامة لمفاتيح الإنترنت، وأن WARP لم يكن قد رُقّي إليها بعد.

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

ما الذي تثبته المجموعة المتفاوض عليها؟

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

اكتمال المصافحة يضيف دليلاً على أن الطرفين اشتقا مفاتيح حركة قابلة للاستخدام. ولتقييم المصادقة يجب تسجيل سلسلة الشهادة وخوارزمية التوقيع. ولتقييم التغطية يجب معرفة موضع إنهاء TLS، والوسطاء، والاتصال بالخادم الأصلي، واستئناف الجلسة، و0-RTT، والأنفاق الداخلية.

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

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

وتجمد RFC 9851 إضافة مزايا جديدة إلى TLS 1.2، فتوجه التطوير إلى TLS 1.3. اختيار جيل البروتوكول الصحيح ضروري، لكنه لا يزامن الشهادات والمكتبات والعتاد والوسطاء والتخزين.

تحويل العبارة إلى إيصال قابل لإعادة الاختبار

يوفر مبدأ أولوية الشيفرة العاملة لدى Heng Lu معياراً عملياً: العبارة ليست النتيجة. يجب أن يستطيع فريق آخر إعادة ملاحظة الخاصية من سجل واضح.

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

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

تجعل RFC 10024 خطوة حاسمة قابلة للتسمية والنشر والتحقق. الاستخدام الدقيق لها يثبت تلك الخطوة، ثم يسأل فوراً: ما الشهادة والتوقيع والمسار اللذان ما زالا تقليديين؟

المصادر