الخلاصة

  • يعرّف RFC 10024 ثلاث مجموعات نهائية في TLS 1.3، تجمع سر ECDHE وسر ML-KEM وفق ترتيب وأطوال وفحوص محددة.
  • صمود التركيب ما دام أحد المكوّنين آمناً لا يعني أن التنفيذين مستقلان؛ فالمعيار نفسه يحذّر من استخدام مولّد عشوائي واحد غير آمن لكليهما.
  • لا يكتمل الإثبات عند اختيار المجموعة، بل يحتاج إلى transcript، وخريطة لمصدر الإنتروبيا والعملية والمكتبة والوحدة ونقطة الإنهاء وحدود FIPS وتوقيع الشهادة.

عقد الإنهاء جمع سلطة لم يجمعها البروتوكول

تشتري مؤسسة خدمة TLS مُدارة موزّعة على عشرات المواقع. يعلن المزوّد أن المجموعة X25519MLKEM768 مفعّلة، وتؤكد عيّنة من ServerHello اختيار القيمة 4588. يبدو أن المؤسسة حصلت على تنويع بين مسألة رياضية تقليدية وأخرى مصممة لعصر ما بعد الحوسبة الكمّية.

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

لا يعني ذلك أن الإنهاء المُدار غير صالح، ولا أن CSPRNG مشتركاً سليماً يسبب خللاً تلقائياً. المعنى أدق: لقد نوّع البروتوكول الافتراضات التشفيرية، بينما أبقت المؤسسة سلطة التشغيل والإثبات في يد واحدة. وهما قراران مختلفان.

نُشر RFC 10024 على مسار معايير IETF في أغسطس 2026. وهو يعرّف ثلاث آليات هجينة Post-Quantum Traditional لتبادل المفاتيح في TLS 1.3، تجمع تبادلاً مؤقتاً على منحنى إهليلجي مع ML-KEM. الهدف أن يبقى سر الجلسة محمياً إذا ظل واحد على الأقل من آليتي المكوّنين آمناً.

هذه خاصية قوية، لكنها لا تنقل سلطة التدقيق من الواقع التشغيلي إلى اسم الخوارزمية.

المجموعة الواحدة تحمل ترتيباً لا قائمة مشتريات

بحسب إطار RFC 9954، لا يتفاوض TLS على إضافتين منفصلتين ثم يترك للتطبيق طريقة الجمع. كل تركيب هو NamedGroup معتم واحد. تُوصل القيم العامة أو النصوص المشفّرة للمكوّنين بترتيب ثابت، وتُوصل الأسرار ثابتة الطول بترتيب ثابت أيضاً، ثم تحل النتيجة محل سر (EC)DHE المعتاد في جدول مفاتيح TLS 1.3.

في X25519MLKEM768 ذي قيمة IANA 4588، يأتي ML-KEM أولاً. يرسل العميل 1,184 بايت لمفتاح تغليف ML-KEM-768 ثم 32 بايت لـX25519، أي 1,216 بايت. يعيد الخادم 1,088 بايت من النص المشفّر و32 بايت لـX25519، أي 1,120. والسر هو 32 بايت من ML-KEM ثم 32 من X25519.

أما SecP256r1MLKEM768 بالقيمة 4587 فيبدأ بـP-256: نقطة غير مضغوطة من 65 بايت ثم مفتاح ML-KEM من 1,184 بايت لدى العميل، و65 بايت ثم نص مشفّر من 1,088 لدى الخادم. السر 32 بايت ECDHE ثم 32 بايت ML-KEM.

وفي SecP384r1MLKEM1024 بالقيمة 4589، تُجمع نقطة P-384 من 97 بايت مع قيمة ML-KEM-1024 من 1,568 بايت. يبلغ key share لدى كل من العميل والخادم 1,665 بايت، والسر النهائي 48 بايت ECDHE ثم 32 بايت ML-KEM.

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

الـtranscript هو ما يربط التركيب بجلسة TLS

يحدّد RFC 9846 النسخة الحالية من TLS 1.3. يضم transcript رسالة ClientHello، وأي HelloRetryRequest، وClientHello الثانية، وServerHello، ثم رسائل المصادقة. يحدد key share الذي اختاره الخادم السر الداخل إلى جدول المفاتيح؛ ويوقّع CertificateVerify على transcript؛ ويبرهن Finished امتلاك المفاتيح المشتقة.

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

يضبط RFC 9794 اللغة أيضاً. المخطط الهجين PQ/T يضم مكوّناً واحداً على الأقل لما بعد الكم وآخر تقليدياً. وصف «ما بعد الكم» خاصية مقصودة، وليس وعداً بألا يظهر هجوم كلاسيكي أو كمّي مستقبلاً.

وعليه، يجب أن يحتفظ المشغّل بالمجموعات المعروضة، وkey shares المرسلة، وإعادة المحاولة، واختيار ServerHello، ونتائج فحوص المكوّنين، ومخطط توقيع CertificateVerify، واكتمال Finished. تفعيل خيار في لوحة التحكم يثبت النية، لا يثبت ما جرى في اتصال بعينه.

الفحوص ترفض القيم التالفة ولا تراجع مصنعها

يفرض RFC 10024 على الخادم فحص مفتاح تغليف ML-KEM الوارد وفق FIPS 203، وإن فشل فعليه الإنهاء بـillegal_parameter. ويتحقق العميل من طول النص المشفّر. وتطبق مكوّنات ECDHE فحوص الصلاحية، ومنها رفض السر الصفري بالكامل في X25519. وينتج عن نوع آخر من فشل فك تغليف ML-KEM تنبيه internal_error.

هذه الرفضات خواص أمنية ضرورية. لكنها لا تثبت مصدر العشوائية، ولا مقاومة القنوات الجانبية، ولا انفصال الذاكرة، ولا هوية البرمجية التي تعمل في كل موقع إنهاء.

يوحّد NIST FIPS 203 المعلمات ML-KEM-512 و768 و1024، ويصف ML-KEM بأنه يُعتقد أنه آمن أمام خصم يملك حاسوباً كمّياً. كلمة «يُعتقد» منضبطة: التوحيد لا يلغي أخطاء التنفيذ والعشوائية والمعلمات والتحليل المستقبلي.

ويقدّم NIST SP 800-227 توصيات أوسع للتنفيذ والاستخدام الآمنين لـKEM، بما فيها التركيبات. ذكر الوثيقة في سياسة لا يبيّن أي توصية طبقتها برمجية الإنتاج فعلاً.

المعيار نفسه يذكر العشوائية كفشل مشترك

أثناء تغليف ML-KEM، يسحب الخادم قيمة عشوائية m، ويمكن للعميل استعادتها عند فك التغليف. يلاحظ RFC 10024 أن أي معلومة تحملها m عن مخرجات أخرى للمولّد تصبح متاحة للعميل. كما تعتمد القيم المؤقتة في ECDHE على عشوائية تشفيرية آمنة، وإن لم تُرسل القيمة السرية مباشرة.

ثم تأتي الحدود التشغيلية صريحة: إذا استخدمت الخوارزميتان مولّد RNG واحداً غير آمن، فإن كشف حالته عن طريق إحداهما يؤثر في أمن الأخرى.

لا يجوز حذف وصف «غير آمن». لا ينكسر CSPRNG مصمم ومُبذر ومُعاد البذر ومحمي على نحو صحيح لمجرد أن مكوّنين يستدعيانه. ولا يفرض RFC جهازَي إنتروبيا ماديين. المطلوب فهم المصدر والبذرة وإعادة البذر وfork واللقطات والاستعادة واختبارات الصحة والذاكرة والمخرجات التي يراها الخصم.

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

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

ترتيب FIPS يعيّن عبئاً محدداً

يشرح RFC 10024 شرط NIST لتزويد HKDF بسرّين مختلفين: يجب أن يأتي الأول من مخطط إنشاء مفاتيح معتمد وفق FIPS. في SecP256r1MLKEM768 وSecP384r1MLKEM1024 يأتي سر ECDHE أولاً؛ لذا يجب اعتماد تنفيذ ECDHE للاستخدام الموصوف، ولا يفرض شرط الترتيب وحده اعتماد تنفيذ ML-KEM. وفي X25519MLKEM768 يأتي ML-KEM أولاً، فيقع عبء الاعتماد على تنفيذه.

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

تسجيل IANA ليس إيصال تشغيل

يخصص سجل IANA لمجموعات TLS القيم 4587 و4588 و4589 للمجموعات النهائية. وحدها X25519MLKEM768 تحمل Recommended Y، بينما تحمل مجموعتا secp القيمة N. وتوضح IANA أن N لا يعني بالضرورة وجود عيب؛ فقد تكون الخوارزمية لاستخدام محدود أو خاص.

أما قيمتا مسودات Kyber التجريبيتان 25497 و25498 فأصبحتا obsolete وdiscouraged. القياس الذي يعرض «PQC» فقط يخفي الفرق بين دلالة مسودة على السلك والمجموعة النهائية.

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

لم يعرض بحث تصويبات RFC 10024 سجلاً في 30 أغسطس 2026. هذه ملاحظة مؤرخة عن السجل، وليست ضماناً لصحة كل تنفيذ.

انتقال اتفاق المفاتيح لا ينقل توقيع الشهادة

يستبعد RFC 9954 مصادقة الجيل التالي من نطاقه. يفصل TLS 1.3 اتفاق المفاتيح عن Certificate وCertificateVerify. يمكن لاتصال أن يختار X25519MLKEM768 بصورة صحيحة، ثم يستخدم توقيعاً تقليدياً لمصادقة الخادم.

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

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

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

يستطيع TLS جمع سرّين على نحو صحيح. ولا يستطيع أن يوزّع سلطة تشغيلهما نيابة عن المؤسسة.