يحتاج اختبار الأداء إلى جهاز وعبء عمل وطريقة قياس وتقدير لعدم اليقين، لا إلى رقم يبدو سريعًا فحسب.
لا توجد نسبة موحّدة لاستهلاك البطارية يمكن تبريرها لـML-KEM-768 على أندرويد. تعتمد الكلفة على التنفيذ والهاتف وإعداد الجلسة وتكرار تحديث المفاتيح وسلوك الشبكة. ولا يثبت اختبار تشفير سريع على حاسوب مكتبي مدة عمل بطارية تطبيق مراسلة كامل على الهاتف.
يشرح هذا المقال ما يمكن حسابه من المعيار وما يحتاج إلى قياس. لم يُجرَ أي اختبار لبطارية Livara على أندرويد من أجل هذا المقال. الإجراء أدناه خطة اختبار، وليس نتيجة مزعومة.
ما الذي يخبرنا به المعيار؟
ML-KEM آلية لتغليف المفاتيح: تساعد على إنشاء سر مشترك يستطيع البروتوكول استخدامه في التشفير المتماثل. وفق معيار FIPS 203، يبلغ طول مفتاح التغليف في ML-KEM-768 مقدار 1,184 بايت، وطول النص المشفّر الناتج 1,088 بايت. ويبلغ مجموع هذين العنصرين 2,272 بايت.
هذا المجموع ليس الحجم الكامل لعملية المصافحة في تطبيق مراسلة، ولا يمثّل بالضرورة الكلفة الإضافية لحركة الشبكة. فقد تغيّر الشهادات والتوقيعات ومادة المفاتيح التقليدية والتأطير والترميز والمفاتيح المخزنة مؤقتًا وإعادة الإرسال عدد البايتات المرسلة فعلًا. أما «768» فهو معرّف لمجموعة معلمات، وليس طول سر مشترك مقداره 768 بت؛ وتستهدف هذه المجموعة الفئة الأمنية 3 لدى NIST.
| الكمية | هل يحددها تصميم الخوارزمية أم تحتاج إلى قياس؟ |
|---|---|
| طول مفتاح التغليف وطول النص المشفّر | تحددهما مجموعة معلمات ML-KEM المختارة |
| زمن توليد المفاتيح والتغليف وفك التغليف | يُقاس للتنفيذ والجهاز الفعليين |
| عدد بايتات إنشاء الجلسة بالكامل | يُقاس للبروتوكول، بما في ذلك التأطير والمحاولات المتكررة |
| زمن الإرسال من البداية إلى النهاية | يُقاس للتطبيق والشبكة معًا |
| الطاقة المستهلكة لكل عبء عمل | تُقاس بتجربة مضبوطة على مستوى الجهاز |
هل تقتصر الكلفة على مرة واحدة لكل جلسة؟
ليس بالضرورة. قد يستخدم البروتوكول آلية KEM عند الإعداد الأولي، ثم مجددًا خلال التحديثات الدورية للمفاتيح ما بعد الكمية. وقد تؤدي تغييرات عضوية المجموعة والأجهزة الجديدة والجلسات الفاشلة والاسترداد إلى عمل إضافي. وحدة القياس المناسبة هي حدث البروتوكول، لا افتراض أن كل محادثة تنفّذ عملية KEM واحدة بالضبط.
تصف بنية LVR1 المنشورة لدى Livara دورات ML-KEM دورية إلى جانب الخطوات المعتادة لسلسلة مفاتيح الرسائل. لذا يجب أن يشمل اختبار الأداء المفيد المراسلة المستقرة وأحداث تحديث المفاتيح معًا. ولا ينبغي أن يدّعي أن العمل المرتبط بالتشفير ما بعد الكمي لا يتكرر مطلقًا.
كذلك، لا يخبرنا عدد بايتات النص المشفّر المخزّن بالكثير عن الطاقة وحده. فقد تؤثر حزمة إضافية في سلوك الاتصال اللاسلكي بصورة مختلفة عن بضعة بايتات إضافية ضمن عملية نقل جارية بالفعل.
خطة قياس قابلة للتكرار على أندرويد
1. سجّل بيئة الاختبار
دوّن طراز الهاتف وبنية أندرويد وإصدار التطبيق وإصدار مكتبة التشفير ونمط البناء وحالة البطارية والحالة الحرارية. سجّل نوع الشبكة وظروف الإشارة. لا تنشر بيانات حساب خاصة أو محتويات الحزم ضمن تقرير اختبار الأداء.
2. افصل اختبارات العمليات الأساسية عن اختبارات التطبيق
يقيس اختبار عملية تشفير أساسية توليد المفاتيح أو التغليف أو فك التغليف بمعزل عن بقية التطبيق. أما اختبار التطبيق الكامل فيقيس إنشاء جلسة وإرسال رسائل والتعافي من انقطاع الاتصال. أبلغ عن النوعين إن توفرا؛ ولا تسمِّ أحدهما باسم الآخر.
كرّر التجارب وأبلغ عن تشتت النتائج، مثل الوسيط وقيمة مئينية مرتفعة، بدلًا من اختيار أسرع محاولة. فقد تؤثر مرحلة التهيئة والترجمة البرمجية أثناء التشغيل وخفض الأداء بسبب الحرارة في النتائج.
3. حدّد أعباء عمل واقعية
- أنشئ جلسة جديدة للمراسلة المباشرة.
- أرسل عددًا ثابتًا من الرسائل ذات حجم محدد داخل جلسة قائمة.
- اختبر الانتقال عند حدّ موثّق لتحديث المفاتيح.
- أضف عضوًا إلى مجموعة اختبار أو أزله منها، إذا كانت الميزة مدعومة.
- أرسل المرفق نفسه في الظروف نفسها.
- اترك التطبيق خاملًا لفترة محددة، وقِس سلوكه في الخلفية على نحو منفصل.
استخدم محتوى اصطناعيًا وحسابات اختبار بموافقة أصحابها. ينبغي أن يذكر اختبار المجموعة عدد أعضائها؛ فلا يجوز تعميم نتيجة تخص شخصين على مجموعة كبيرة من دون توضيح.
4. قِس الطاقة إلى جانب الزمن
يمكن لأداة Power Profiler في Android Studio ربط النشاط بقياسات مسارات تغذية الطاقة على الأجهزة المدعومة. وتنبّه Google إلى أن هذه القياسات تُجرى على مستوى الجهاز، ولذلك يُدخل النشاط الآخر ضوضاء في النتائج. وتختلف طرق القياس المدعومة من جهاز إلى آخر.
اضبط سطوع الشاشة والعمل في الخلفية وظروف الشبكة ومدة الاختبار. كرّر عبء العمل نفسه وقارن حالات متماثلة. إذا لم تستطع طريقتك عزل مساهمة التشفير، فاذكر ذلك بدلًا من نسبة استهلاك البطارية كله إلى ML-KEM.
صورة توضيحية لإعداد قياس، وليست نتائج مسجّلة لاختبار أداء.
ما الذي ينبغي أن يتضمنه جدول نتائج مفيد؟
| حقل النتيجة | مثال على المعلومات التي ينبغي تسجيلها |
|---|---|
| عبء العمل | جلسة جديدة أو مراسلة داخل جلسة قائمة أو تحديث مفاتيح |
| البيئة | الجهاز المحدد وبنية التطبيق والشبكة |
| التجارب | عددها وكيفية التعامل مع محاولات التهيئة |
| التوقيت | الوسيط والتفاوت ووحدات القياس |
| حركة البيانات | عدد البايتات المقاس وظروف إعادة الإرسال |
| الطاقة | الطريقة والفترة وعدم اليقين |
| الحدود | ما لم يعزله الاختبار أو يشمله |
اترك الخلايا التي لم تُقَس فارغة أو ضع فيها عبارة «لم يُقَس». فالرسم العمودي التوضيحي للطاقة، إذا تضمّن نسبًا مختلقة، ليس دليلًا.
ماذا عن الصور والفيديو؟
تستخدم المرفقات الكبيرة عادةً تشفيرًا متماثلًا، بدلًا من استخدام ML-KEM لكل كتلة من المحتوى. وقد يظل إنشاء المفاتيح مؤثرًا في مرحلة الإعداد، بينما تؤثر معالجة الملف والتخزين والنقل عبر الشبكة ومنطق إعادة المحاولة في العملية الكاملة. يجب قياس المساهمة النسبية على عبء العمل الفعلي؛ فعبارة «لا يُلاحظ أثره مطلقًا» ليست ادعاءً عامًا سليمًا.
الأسئلة الشائعة
هل ML-KEM-768 أبطأ دائمًا من P-256؟
لا تصلح مقارنة موحّدة لجميع المكتبات والأجهزة. قارن العمليات نفسها في الظروف نفسها، ثم قِس البروتوكول الهجين الكامل بصورة منفصلة.
هل تثبت بصمة APK صحة نتائج الأداء؟
يمكنها تحديد الملف نفسه الذي استُخدم في الاختبار عند مقارنته بمرجع موثوق. لكنها لا تثبت صحة طريقة الاختبار أو سلامة التنفيذ أو قياس الطاقة.
هل ينبغي للمستخدمين تعطيل التشفير لتوفير البطارية؟
لا تتخلَّ عن متطلب أمني بناءً على ادعاء أداء غير مدعوم. حدّد أولًا المصدر الفعلي لاستهلاك البطارية، واستخدم الإعدادات أو التحديثات المدعومة.
