TLS 1.3 ما بعد الكم: أي إعداد هجين لآلية KEM يقلل من عبء المصافحة (handshake) في OpenSSL؟

يجري ترحيل TLS 1.3 نحو تبادل مفاتيح مقاوم للحوسبة الكمومية لأن دييفي-هيلمان (Diffie-Hellman) الكلاسيكي وX25519 لن يصمدا أمام حاسوب كمومي كبير. اختارت NIST خوارزمية ML-KEM كآلية تغليف مفاتيح (KEM) مقاومة للكم [9]. سيؤثر تبادل المفاتيح والمصادقة لما بعد الكم باستخدام ML-KEM وML-DSA على أداء TLS 1.3 في الويب وتطبيقات أخرى [9]. ركزت الدراسات حتى الآن على عبء هذه الخوارزميات المقاومة للكم على زمن الوصول لأول بايت (time-to-first-byte) في TLS، أي زمن المصافحة [9]. هذا التركيز منطقي بالنسبة لتكلفة إنشاء الاتصال، لكنه يترك حجم الشيفرة، وهو الاهتمام الثاني المذكور صراحة في سؤال البحث، شبه مهمل في أدبيات القياس التي جُمعت هنا.

تُظهر بيانات النشر أن التحول جارٍ بالفعل لكنه غير مكتمل. وجدت دراسة قياس أُجريت عام 2026 أن 49.3% من النطاقات (domains) تدعم آليات تبادل مفاتيح هجينة لما بعد الكم مثل MLKEM768 مع X25519، بينما لا تزال 50.7% من النطاقات تستخدم تبادل مفاتيح كلاسيكيًا [14]. وجدت الدراسة نفسها اعتمادًا بنسبة 0% لشهادات هجينة لما بعد الكم، مما يترك طبقة المصادقة عرضة لهجمات ممكّنة كموميًا مثل تزوير الشهادات [14]. كما وجدت أن 15.70% من النطاقات، لا سيما في قطاعات حساسة مثل البنوك والحكومة، لا تزال تعتمد على TLS 1.2 [14]. هذا الوضع المختلط هو سبب حاجة المطورين إلى أرقام أداء ملموسة الآن، وليس بعد اكتمال الترحيل.

الدافع الأمني قابل للقياس. توفر مادة المفتاح المتماثل عند مستوى أمان كلاسيكي 128 بت أمانًا فعليًا يبلغ نحو 64 بت أمام مهاجم كمومي [14]. هذا التنصيف هو السبب في معاملة ترحيل KEM على أنه أمر عاجل وليس اختياريًا، وهو ما يوضح لماذا تُعد المفاضلات بين زمن الاستجابة وحجم الشيفرة لإعدادات KEM معينة أمرًا مهمًا تشغيليًا، لا أكاديميًا فقط.

يسأل سؤال البحث تحديدًا عن OpenSSL 3.4+ والإعدادات المسماة مثل X25519Kyber768 وX25519MLKEM512. تصف الادعاءات المتوفرة تجارب على OpenSSL 3.x المدمج مع liboqs [1] [8] وعلى معايير مقارنة (benchmarks) عبر منصات متعددة لعائلات PQC ذات صلة [12]، لكن لا يربط أي مصدر قياساته بإصدار OpenSSL 3.4+ الدقيق أو بمقياس حجم الشيفرة المذكور في السؤال. ينبغي على القارئ أن يقرأ بقية هذه المذكرة كإجابة عن نصف السؤال المتعلق بزمن الاستجابة، مع الإشارة الصريحة إلى فجوة في النصف المتعلق بحجم الشيفرة.

مذكورة بوضوح ومرة واحدة، منذ البداية: لا يوجد ادعاء موثّق يربط بين ميزة حجم الحزمة لـ ML-KEM-512، أو أي أداء لأي إعداد KEM، وبين حجم الشيفرة. كل ادعاء يناقش ميزة ML-KEM-512 يتحدث فقط عن حجم الحزمة وزمن استجابة المصافحة تحت ضغط الشبكة، ولا يتحدث أبدًا عن حجم الشيفرة المُصرَّفة أو المرتبطة (linked)، أو بصمة الملف الثنائي، أو حجم المكتبة [1]. لا يوجد ادعاء يقارن حجم الشيفرة بين ML-KEM-512 وML-KEM-768 وKyber768 أو أي مزيج هجين. على القارئ الذي يحتاج إلى إجابة حول حجم الشيفرة أن يعتبر هذه المذكرة صامتة على هذا البُعد؛ لا شيء هنا يوحي بأن ميزة حجم الحزمة تُترجَم إلى ميزة في حجم الشيفرة، لأن لا مصدر يقيم هذا الربط.

هذا مهم في عمليات النشر المضمّنة (embedded) والمقيّدة، حيث غالبًا ما يكون حجم الشيفرة هو القيد الملزِم بدلًا من زمن الاستجابة. وبما أن الأدبيات المستعرَضة هنا لا تقيسه، فإن أي قرار في المشتريات أو الهندسة يعتمد على حجم الشيفرة لا يمكن حسمه بهذه الادعاءات وحدها. لذا تعامل بقية هذه المذكرة مع زمن الاستجابة باعتباره النصف القابل للإجابة من السؤال، وتعامل مع حجم الشيفرة باعتباره سؤالًا مفتوحًا لم تُعالَج.

ML-KEM هو أحد اختيارات NIST لخوارزميات ما بعد الكم لتبادل المفاتيح، إلى جانب ML-DSA للمصادقة [9]. تُقيّم التجارب الأكثر صلة بأداء OpenSSL خوارزميات ML-KEM مباشرة وأيضًا إعدادًا هجينًا، X25519+ML-KEM-768، يجمع بين تبادل المنحنى الإهليلجي الكلاسيكي X25519 وآلية ML-KEM-768 المقاومة للكم [1]. هذا التصميم الهجين شائع في النشر الفعلي: آليات تبادل المفاتيح الهجينة لما بعد الكم المُلاحَظة في الواقع، مثل MLKEM768 مع X25519، تتبع النمط نفسه المتمثل في إقران خوارزمية كلاسيكية وأخرى مقاومة للكم في مفاوضة واحدة [14].

تدرس أعمال أخرى في هذا المجال عائلات KEM ذات صلة لكنها متمايزة. تبحث إحدى الدراسات في أثر إدماج آليات KEM مقاومة للكم، وتحديدًا المعياريْن CRYSTALS-Kyber وHQC، إلى جانب المرشح المعياري BIKE، ضمن مصافحة TLS 1.3 [8]. تقدّم دراسة أخرى ما تصفه بأنه أوسع تقييم تجريبي عبر منصات متعددة حتى تاريخه لخوارزميات PQC المختارة من NIST، بما فيها CRYSTALS-Kyber وNTRU لآليات KEM، إلى جانب BIKE كبديل قائم على الشيفرات (code-based)، وCRYSTALS-Dilithium وFalcon للتوقيعات [12]. توسّع هذه الدراسات الصورة إلى ما هو أبعد من ML-KEM وحدها، لكنها لا تُبلِغ عن أرقام لأسماء الإعدادات الدقيقة X25519MLKEM512 أو X25519Kyber768 المذكورة في السؤال؛ وعلى المطور الذي يريد ربط هذه العائلات بأسماء المجموعات (group names) في OpenSSL أن يفعل ذلك بحذر، إذ لا تنص الادعاءات هنا على أن Kyber وML-KEM قابلان للتبادل أو متطابقان.

جانب التوقيع في TLS 1.3 آلية منفصلة عن تبادل المفاتيح لكنها تشترك في ضغط الترحيل نفسه. يتفوق Dilithium 2 وFalcon 512 على RSA 4096 من حيث مدة زمن مصافحة TLS [13]. هذا سياق مفيد للمطور الذي يجمّع مكدسًا كاملًا لـ TLS 1.3 مقاومًا للكم، إذ يسهم كل من اختيار آلية تبادل المفاتيح واختيار خوارزمية التوقيع في التكلفة الإجمالية للمصافحة، لكنها نتيجة منفصلة عن مقارنات KEM التي هي محور هذه المذكرة.

أكثر منهج تفصيلي للأرقام ذات الصلة بـ OpenSSL هو دراسة ARM64. أُجريت التجارب باستخدام OpenSSL 3.x مدمجًا مع liboqs [1]. كان الإعداد الهجين X25519+ML-KEM-768 أحد الإعدادات التي جرى تقييمها [1]. أُجريت 100 تكرار لكل إعداد [1]. استُخدمت خمسة سيناريوهات شبكة: loopback، وLAN (زمن رحلة ذهاب وإياب 10 مللي ثانية)، وWAN (زمن رحلة ذهاب وإياب 50 مللي ثانية)، ونسب فقدان حزم 1% و5% [1]. إذا قُرئت كخمسة ظروف مستقلة، loopback وLAN وWAN وفقدان 1% وفقدان 5%، فهذا يتطابق مع العدد المذكور في الادعاء وهو خمسة؛ وعلى المطور الذي يعيد إنتاج الإعداد أن يتعامل معها على هذا الأساس بدلًا من اعتبارها أربعة سيناريوهات.

هناك دراسة ذات صلة لكنها منفصلة على أرضية مشابهة تبحث في Kyber وHQC وBIKE ضمن TLS 1.3، وأجرت تقييمًا تجريبيًا شاملًا لقياس زمن استجابة المصافحة تحت ظروف شبكة محاكاة مع احتمالات فقدان حزم متفاوتة [8]. هذا يوازي منهجيًا تصميم دراسة ARM64 القائم على ضغط الشبكة لكنه يغطي عائلة KEM مختلفة، لذا لا ينبغي دمج أرقامه مع أرقام ML-KEM دون حذر.

قاست دراسة معايرة (benchmarking) ثالثة وأكبر زمن الاستجابة الحسابي، واستخدام الذاكرة، وأحجام المفاتيح، وعبء البروتوكول عبر مستويات أمان متعددة، مستويات NIST 1 و3 و5، في ثلاث بيئات عتاد مختلفة وظروف شبكة متنوعة [12]. هذا هو الادعاء الوحيد في هذه المجموعة الذي يذكر أحجام المفاتيح واستخدام الذاكرة كمتغيرات مقيسة، وهو قريب من حجم الشيفرة لكنه لا يزال متمايزًا عنه؛ فهو لا يُبلِغ عن رقم لحجم الشيفرة لأي إعداد في OpenSSL، وبالتالي لا يسد الفجوة المذكورة أعلاه.

تتبنى دراسة رابعة زاوية مختلفة، إذ تفكك مصافحة TLS إلى مراحل وتقيس أحجام الأثر (effect sizes) بدلًا من الأزمنة الخام. يتيح هذا النهج الطبقي عزل الموضع الذي يهم فيه اختيار KEM فعليًا ضمن المصافحة، بدلًا من معاملة المصافحة ككتلة قياس واحدة؛ وتُناقَش نتيجتها المركزية مرة واحدة، بالكامل، في القسم التالي.

تأتي الأرقام الرئيسية لزمن الاستجابة من دراسة ARM64. تُدخل خوارزميات ML-KEM عبئًا حسابيًا ضئيلًا مقارنة بـ X25519 الكلاسيكي تحت ظروف زمن انتقال منخفض [1]. تتراوح أزمنة مصافحة 1-RTT في الحالة الأساسية لخوارزميات ML-KEM بين 11.3 و13.3 مللي ثانية [1]؛ هذا هو النطاق الوحيد المرجعي والموثوق لتوقيت الحالة الأساسية في هذه المذكرة، ويُشار إليه من أقسام أخرى بدلًا من إعادة ذكره. تحت فقدان الحزم، تتسع الفجوة: بلغ ML-KEM 180 مللي ثانية مع فقدان حزم بنسبة 5%، بينما بلغ X25519 281 مللي ثانية [1]، وبالتالي كان ML-KEM عند أعلى نسبة فقدان مختبَرة أسرع بشكل مطلق، لا مجرد مضاهٍ. أدت أزمنة إعادة تشغيل الجلسة (session restart) إلى تقليل زمن استجابة المصافحة باستمرار لجميع الخوارزميات المختبَرة [1]، مما يعني أن الاتصالات المستأنَفة كانت أسرع من مصافحات 1-RTT الجديدة عبر جميع الحالات، بغض النظر عن آلية KEM المستخدمة.

ضمن دراسة ARM64 هذه، أظهر ML-KEM-512 أفضل أداء، ويُعزى ذلك بشكل خاص إلى صغر حجم حزمته [1]. هذا هو الادعاء الوحيد في هذه المجموعة الذي يرتّب الإعدادات مقابل بعضها بناءً على آلية مسمّاة، وهو أقرب ما تصل إليه الأدلة للإجابة المباشرة عن نصف السؤال المتعلق بزمن الاستجابة.

يُفكك تحليل طبقي منفصل مصافحة TLS 1.3 إلى مراحل بدلًا من معاملتها كرقم واحد، وهذا هو أهم مُحدِّد وحيد على نتائج ARM64 أعلاه. نتيجته المركزية، المذكورة هنا مرة واحدة والمُشار إليها بدلًا من تكرارها في أي مكان آخر من هذه المذكرة: تبادل مصافحة TLS، أي المرحلة من ClientHello إلى Finished، محايد فعليًا تجاه الخوارزمية، حيث أظهرت جميع الإعدادات المختبَرة، الكلاسيكية والهجينة وML-KEM الخالصة، أحجام أثر ضئيلة، دلتا غلاس (Glass's Δ) أقل من 0.2 إلى 0.33 [4]. اتساقًا مع ذلك، لم يُعثَر على أي عقوبة أو ميزة ذات دلالة عملية تُعزى إلى خوارزمية تبادل المفاتيح في تبادل مصافحة TLS [4]. بدلًا من ذلك، تنحصر التكلفة الحساسة تجاه الخوارزمية في بناء ClientHello تحديدًا [4]، وليس في التبادل ذهابًا وإيابًا ككل.

هذا يعيد صياغة أرقام ARM64 بدلًا من تناقضها. يصف النطاق الأساسي وأرقام فقدان الحزم المذكورة أعلاه [1] زمن المصافحة الفعلي (wall-clock) تحت ضغط الشبكة؛ فيما تصف نتيجة الدراسة الطبقية عن ضآلة حجم الأثر [4] الحجم الإحصائي للفرق المُعزى إلى الخوارزمية ضمن مرحلة تبادل المصافحة، تحت ظروف ومقاييس مفترَض أنها مختلفة. الاثنان لا يقيسان الكمية نفسها، لذا لا ينبغي للقارئ أن يفسر أحدهما على أنه يبطل الآخر؛ بل يُظهر أحدهما ما يحدث تحت ظروف شبكة معاكسة تحديدًا، بينما يُظهر التحليل الطبقي أن الفرق المُعزى إلى الخوارزمية، عند حساب المتوسط عبر الإعدادات، ضئيل ضمن مرحلة التبادل نفسها، وأن الحساسية الحقيقية تكمن قبل ذلك في بناء ClientHello.

إذا جُمع كل ذلك، فإن القراءة العملية هي: إذا كان هدف النشر يهيمن عليه ضغط الشبكة، فقدان الحزم وزمن الرحلة ذهابًا وإيابًا، فإن أرقام ARM64 هي ذات الصلة، وقد أُبلِغ عن ML-KEM-512 باعتباره الأفضل أداءً هناك [1]. أما إذا كان هدف النشر شبكة مستقرة وذات فقدان منخفض، فتُشير نتيجة الدراسة الطبقية إلى أن الاختيار بين الإعدادات المختبَرة لن ينتج، بحد ذاته، فرقًا ذا دلالة عملية في زمن استجابة مرحلة التبادل [4]، وإن كانت تكلفة بناء ClientHello تستحق اهتمامًا منفصلًا.

ليس زمن المصافحة هو المكان الوحيد الذي يمكن أن يظهر فيه عبء ما بعد الكم. تُجادِل إحدى الدراسات بأن الدراسات حتى الآن ركزت على عبء الخوارزميات المقاومة للكم على زمن الوصول لأول بايت في TLS، أي زمن المصافحة [9]، وتحدد فجوة تسعى لسدها: تقيس أثر ML-KEM وML-DSA على اتصالات TLS 1.3 النمطية التي تنقل بضع مئات من الكيلوبايت من الخادم إلى العميل، بدراسة التباطؤ في زمن الوصول لآخر بايت (time-to-last-byte) [9]. تفيد نتيجتها بأنه تحت ظروف شبكة مستقرة، يكون أثر ML-KEM وML-DSA على زمن الوصول لآخر بايت في TLS 1.3 أقل من أثرهما على زمن الوصول لأول بايت، ويتضاءل هذا الأثر مع ازدياد حجم البيانات المنقولة [9]. بالنسبة للمطور، يعني هذا أن أرقام زمن استجابة المصافحة المذكورة أعلاه هي الأكثر صلة بالاتصالات القصيرة العمر أو التي تهيمن عليها المصافحة؛ أما بالنسبة لعمليات نقل الحمولات الأكبر، فإن الخوارزميات نفسها تهم بشكل أقل نسبيًا في زمن الاتصال الإجمالي.

يشمل مشهد المعايرة الأوسع أيضًا أعمالًا أوسع نطاقًا لكن غير مركّزة على OpenSSL تحديدًا. يغطي تقييم تجريبي عبر منصات متعددة CRYSTALS-Kyber وNTRU وBIKE وCRYSTALS-Dilithium وFalcon، ويقيس زمن الاستجابة الحسابي، واستخدام الذاكرة، وأحجام المفاتيح، وعبء البروتوكول عبر مستويات أمان NIST 1 و3 و5 في ثلاث بيئات عتاد مختلفة وظروف شبكة متنوعة [12]. تبحث دراسة أخرى في CRYSTALS-Kyber وHQC وBIKE تحديدًا داخل مصافحة TLS 1.3، بتقييم تجريبي شامل لزمن استجابة المصافحة تحت فقدان حزم محاكى [8]. لا تُذكر أي من هاتين الدراستين هنا بأرقام مرتبطة بـ OpenSSL 3.4+ أو بالإعدادات المسماة X25519Kyber768 أو X25519MLKEM512، لذا ينبغي قراءتهما كسياق لمشهد KEM لا كإجابات مباشرة عن سؤال هذه المذكرة.

على جانب المصادقة، الذي يتفاعل مع تكلفة المصافحة رغم كونه آلية منفصلة، يتفوق Dilithium 2 وFalcon 512 على RSA 4096 من حيث مدة زمن مصافحة TLS [13]. يحتاج المطور الذي يجمّع إعدادًا كاملًا لـ TLS 1.3 مقاومًا للكم في OpenSSL إلى اختيار آلية KEM وخوارزمية توقيع كليهما، وهذه النتيجة هي ذات الصلة بجانب التوقيع، بصرف النظر عن آلية KEM المختارة.

لا تكون أي نتيجة تتعلق بزمن الاستجابة أو الحجم مفيدة إلا إذا قابلت ما هو قابل للنشر وما هو منشور فعليًا. هدفت دراسة القياس لعام 2026 إلى تحديد بدائيات (primitives) تشفيرية عرضة للكم، والكشف عن وجود خوارزميات ما بعد الكم أو هجينة، وتحليل النشر الفعلي لـ TLS عبر قطاعات مختلفة [14]. أرقامها الرئيسية، المذكورة أعلاه بالفعل، هي أن 49.3% من النطاقات تدعم تبادل مفاتيح هجينًا لما بعد الكم مثل MLKEM768 مع X25519، وأن 50.7% من النطاقات لا تزال تستخدم تبادل مفاتيح كلاسيكيًا فقط [14]. يعني هذا الانقسام أن المطور الذي يستهدف توافقًا واسعًا يجب أن يدعم مفاوضة كلاسيكية فقط كخيار احتياطي لنحو نصف النطاقات المرصودة، على الأقل وقت إجراء ذلك القياس.

الأكثر إثارة للقلق بالنسبة لمن يفكر في الأمان طويل الأمد بدلًا من زمن الاستجابة فقط: لوحظ اعتماد بنسبة 0% لشهادات هجينة لما بعد الكم، مما يترك طبقة المصادقة عرضة لهجمات ممكّنة كموميًا مثل تزوير الشهادات [14]. يعني هذا أنه حتى حيث يُنشَر تبادل المفاتيح الهجين، فإن سلسلة الشهادات التي تصادق على ذلك التبادل لم تُرحَّل بعد في أي مكان ضمن المجموعة المقيسة. علاوة على ذلك، لا تزال 15.70% من النطاقات، لا سيما في قطاعات حساسة مثل البنوك والحكومة، تعتمد على TLS 1.2 [14]، وهو إصدار بروتوكول يسبق آليات PQC الهجينة المذكورة في هذه المذكرة كليًا.

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

القيد الأهم ذُكِر بالفعل قرب البداية: لا يقيس أي ادعاء في هذه المجموعة حجم الشيفرة لأي إعداد KEM في OpenSSL، لذا يبقى نصف سؤال البحث المتعلق بحجم الشيفرة دون إجابة من هذه الأدلة [1]. هذه ليست فجوة ثانوية؛ فهي إحدى الكميتين اللتين يسأل عنهما السؤال، وعلى المطور الذي يحتاج رقمًا لحجم الشيفرة أن يبحث خارج هذه المذكرة.

ثانيًا، نتيجة دراسة ARM64 القائلة بأن ML-KEM-512 أظهر أفضل أداء بفضل صغر حجم الحزمة [1] مُبلَّغ عنها من دراسة واحدة على منصة عتاد واحدة، ARM64، بواقع 100 تكرار لكل إعداد عبر خمسة سيناريوهات شبكة [1]. إنه الادعاء الوحيد في هذه المجموعة الذي يرتّب إعدادات KEM مقابل بعضها بناءً على أداء مقيس مباشرة؛ ولم يُقارَن هنا بتكرار مستقل على منصة مختلفة أو إصدار فرعي مختلف من OpenSSL.

ثالثًا، نتيجة الدراسة الطبقية القائلة بأن تبادل المصافحة محايد فعليًا تجاه الخوارزمية [4] ونتيجة دراسة ARM64 القائلة بوجود فجوة 180 مللي ثانية مقابل 281 مللي ثانية تحت فقدان حزم بنسبة 5% [1] أُنتجتا من قِبل مجموعتي بحث مختلفتين، على الأرجح تحت ظروف دقيقة مختلفة، ولم تُقدَّم في هذه المذكرة أي نتيجة توفّق بين مقاييسهما في مقياس واحد قابل للمقارنة. على المطور أن يعاملهما كأدلة متكاملة على مستويين مختلفين من التفصيل: حجم أثر مرحلة التبادل مقابل الزمن الفعلي الخام تحت ضغط الشبكة، بدلًا من رقم موحد واحد.

رابعًا، عدد من دراسات المعايرة الأوسع، التي تغطي Kyber وHQC وBIKE وNTRU وDilithium وFalcon [8] [12] [13]، لا تُذكر هنا بأرقام مرتبطة بأسماء الإعدادات الدقيقة في سؤال البحث، X25519Kyber768 أو X25519MLKEM512، أو بـ OpenSSL 3.4+ تحديدًا. أهميتها سياقية، وليست إجابة مباشرة. أخيرًا، تصف أرقام النشر [14] الاعتماد على مستوى الإنترنت وقت إجراء تلك الدراسة وقد لا تعكس الاعتماد الحالي؛ كما أنها لا تقيس الأداء، بل فقط وجود أو غياب الدعم.

1. أعدّ OpenSSL 3.x مدمجًا مع liboqs كمكدس أساسي، مطابقًا للبيئة التي أُنتِجَت فيها أرقام زمن الاستجابة المرجعية [1]؛ هذا شرط مسبق لإعادة إنتاج تلك الأرقام أو توسيعها بدلًا من التخمين.
2. عدّد إعدادات KEM المراد اختبارها: على الأقل، X25519 الخالص كخط أساس كلاسيكي، وإعداد ML-KEM خالص، والإعداد الهجين X25519+ML-KEM-768، حيث كان هذا الهجين أحد الإعدادات التي جرى تقييمها مباشرة في التجارب المصدرية [1].
3. جهّز المصافحة لتسجيل زمن إنشاء 1-RTT بشكل منفصل عن زمن إعادة تشغيل الجلسة (الاستئناف)، لأن أزمنة إعادة تشغيل الجلسة قللت زمن استجابة المصافحة باستمرار لجميع الخوارزميات في الدراسة المرجعية [1]، ومزج المصافحات الجديدة والمستأنَفة في قياس واحد سيشوّش المقارنة.
4. ابنِ خمس بيئات اختبار لظروف شبكة مطابقة للتصميم المرجعي: loopback، وLAN عند زمن رحلة ذهاب وإياب 10 مللي ثانية، وWAN عند زمن رحلة ذهاب وإياب 50 مللي ثانية، وفقدان حزم بنسبة 1%، وفقدان حزم بنسبة 5% [1]. تأكد أن بيئة اختبارك تنتج خمس حالات متمايزة فعلًا لتكون إعادة إنتاج أمينة.
5. شغّل 100 تكرار لكل إعداد لكل حالة شبكة، مطابقًا للبروتوكول المرجعي [1]، وسجّل التوزيع الكامل، لا المتوسط فقط، لكي تظهر القيم الشاذة تحت فقدان الحزم.
6. قارن أداء كل إعداد KEM في الحالة الأساسية مع النطاق المرجعي لمصافحات ML-KEM في الحالة الأساسية 1-RTT [1] كفحص سلامة يضمن سلوك بيئة الاختبار بشكل متسق مع الأرقام المنشورة قبل استخلاص استنتاجات جديدة.
7. تحت حالة فقدان الحزم بنسبة 5% تحديدًا، تحقق مما إذا كانت إعدادات عائلة ML-KEM تبقى أقرب إلى الأرقام المرجعية المذكورة لـ ML-KEM مقابل X25519 تحت تلك الحالة [1]؛ فإذا أدى إعداد ما أداءً بعيدًا كثيرًا عن كلا الرقمين فذلك يشير إلى اختلاف في بيئة الاختبار أو البيئة التشغيلية يستوجب التحقيق قبل مقارنة الإعدادات ببعضها.
8. بشكل منفصل، جهّز وقِس زمن بناء ClientHello بمفرده، متمايزًا عن زمن تبادل المصافحة الكامل، لأن التكلفة الحساسة تجاه الخوارزمية تقع في بناء ClientHello وليس في مرحلة التبادل نفسها [4]. تجاوز هذا الفصل هو نقطة فشل شائعة: قياس زمن المصافحة الإجمالي فقط سيُخفي مكان أي تكلفة فعلية تعتمد على الخوارزمية.
9. إذا كان حجم الشيفرة يهم لهدف النشر، عامله كمهمة قياس منفصلة غير معالَجة: صرّف بناء OpenSSL/liboqs لكل إعداد وسجّل حجم الملف الثنائي أو المكتبة مباشرة. لا يوفر أي ادعاء في هذه المذكرة خط أساس أو نطاقًا متوقعًا لهذا، لذا فإن أي رقم يُنتَج هنا هو عمل جديد، لا إعادة إنتاج لنتائج سابقة.
10. إذا تضمّن النشر عمليات نقل حمولات أكبر بدلًا من اتصالات قصيرة تهيمن عليها المصافحة، قِس أيضًا زمن الوصول لآخر بايت لعملية نقل نموذجية بحجم بضع مئات من الكيلوبايت، إذ وجدت إحدى الدراسات أن أثر ما بعد الكم على زمن الوصول لآخر بايت أقل من أثره على زمن الوصول لأول بايت ويتضاءل مع ازدياد البيانات المنقولة [9]؛ هذا يغيّر أي إعداد يهم أكثر تبعًا لحجم الاتصال النموذجي في هدف النشر.
11. أبلغ عن النتائج مع تحديد صريح لحالة الشبكة وعدد التكرارات ومنصة العتاد لكل رقم، متبعًا نمط الدراسات المرجعية [1] [12]، حتى يستطيع أي قارئ الحكم على مدى إمكانية تعميم النتيجة خارج البيئة المختبَرة.

for config in [X25519, ML-KEM-512, ML-KEM-768, X25519+ML-KEM-768]:
  for scenario in [loopback, LAN_10ms, WAN_50ms, loss_1pct, loss_5pct]:
    for i in 1..100:
      measure(ClientHello_construction_time)
      measure(full_handshake_time)
      measure(session_restart_time)
    record distribution, not just mean
compare each config's numbers against reference ranges [1]
if code_size_required: compile and measure binary size separately (no reference baseline exists)