เบนช์มาร์กต้องมีอุปกรณ์ ภาระงาน วิธีการ และความไม่แน่นอน ไม่ใช่เพียงตัวเลขที่ดูเร็ว
ไม่มีตัวเลขเปอร์เซ็นต์การใช้แบตเตอรี่ของ ML-KEM-768 บน Android ที่ใช้อ้างอิงได้กับทุกกรณี ต้นทุนขึ้นอยู่กับการนำไปใช้ โทรศัพท์ การเริ่มต้นเซสชัน ความถี่ในการรีเฟรชคีย์ และพฤติกรรมของเครือข่าย ผลเบนช์มาร์กการเข้ารหัสที่รวดเร็วบนคอมพิวเตอร์ตั้งโต๊ะไม่ได้พิสูจน์ระยะเวลาการใช้แบตเตอรี่ของแอปส่งข้อความบนมือถือทั้งแอป
บทความนี้อธิบายว่าสิ่งใดคำนวณได้จากมาตรฐาน และสิ่งใดต้องวัด ไม่ได้มีการทดสอบเบนช์มาร์กแบตเตอรี่ของ Livara บน Android สำหรับบทความนี้ ขั้นตอนด้านล่างเป็นแผนการทดสอบ ไม่ใช่การกล่าวอ้างผลที่วัดได้
มาตรฐานบอกอะไรเราได้บ้าง
ML-KEM เป็นกลไกการห่อหุ้มคีย์ โดยช่วยสร้างค่าลับร่วมกันที่โพรโทคอลสามารถนำไปใช้ในการเข้ารหัสแบบสมมาตร ตาม FIPS 203 ML-KEM-768 มีคีย์สำหรับการห่อหุ้มขนาด 1,184 ไบต์ และข้อความเข้ารหัสขนาด 1,088 ไบต์ วัตถุทั้งสองนี้รวมกันมีขนาด 2,272 ไบต์
ขนาดรวมนี้ไม่ใช่ขนาดทั้งหมดของการแฮนด์เชกในระบบส่งข้อความ และไม่จำเป็นต้องเท่ากับปริมาณข้อมูลเครือข่ายที่เพิ่มขึ้นด้วย ใบรับรอง ลายเซ็น ข้อมูลคีย์ของการเข้ารหัสแบบดั้งเดิม การจัดเฟรม การเข้ารหัสรูปแบบข้อมูล คีย์ที่แคชไว้ และการส่งซ้ำ ล้วนเปลี่ยนจำนวนไบต์ที่ส่งจริงได้ “768” เป็นตัวระบุชุดพารามิเตอร์ ไม่ใช่ความยาว 768 บิตของค่าลับร่วมกัน ชุดนี้มีเป้าหมายที่ระดับความปลอดภัย NIST หมวด 3
| ปริมาณ | อัลกอริทึมกำหนดไว้หรือต้องวัด? |
|---|---|
| ความยาวของคีย์สำหรับการห่อหุ้มและข้อความเข้ารหัส | กำหนดโดยชุดพารามิเตอร์ ML-KEM ที่เลือก |
| เวลาสร้างคีย์ ห่อหุ้มคีย์ และแกะห่อหุ้มคีย์ | วัดจากการนำไปใช้และอุปกรณ์จริง |
| จำนวนไบต์ทั้งหมดในการเริ่มต้นเซสชัน | วัดโพรโทคอล รวมการจัดเฟรมและการลองใหม่ |
| ความหน่วงในการส่งตั้งแต่ต้นทางถึงปลายทาง | วัดแอปและเครือข่ายร่วมกัน |
| พลังงานต่อภาระงาน | วัดด้วยการทดลองระดับอุปกรณ์ที่ควบคุมเงื่อนไข |
ต้นทุนเกิดขึ้นเพียงครั้งเดียวต่อเซสชันหรือไม่?
ไม่จำเป็น โพรโทคอลอาจใช้ KEM ตอนเริ่มต้น และใช้อีกครั้งเมื่ออัปเดตคีย์หลังควอนตัมเป็นระยะ การเปลี่ยนสมาชิกกลุ่ม อุปกรณ์ใหม่ เซสชันที่ล้มเหลว และการกู้คืน อาจทำให้ต้องทำงานเพิ่ม หน่วยที่ถูกต้องคือเหตุการณ์ในโพรโทคอล ไม่ใช่การสมมติว่าทุกการสนทนาเรียกใช้ KEM เพียงหนึ่งครั้งเสมอ
สถาปัตยกรรม LVR1 ที่ Livara เผยแพร่ อธิบายถึงรอบ ML-KEM เป็นระยะควบคู่กับขั้นตอนตามปกติของสายโซ่ข้อความ ดังนั้น เบนช์มาร์กที่มีประโยชน์ต้องครอบคลุมทั้งการส่งข้อความในสภาวะคงตัวและเหตุการณ์รีเฟรชคีย์ ไม่ควรกล่าวอ้างว่างานหลังควอนตัมไม่เกิดซ้ำอีกเลย
จำนวนไบต์ของข้อความเข้ารหัสที่จัดเก็บไว้เพียงอย่างเดียวก็บอกเรื่องพลังงานได้น้อย แพ็กเก็ตที่เพิ่มมาอีกหนึ่งแพ็กเก็ตอาจส่งผลต่อพฤติกรรมของวิทยุสื่อสารต่างจากการเพิ่มอีกไม่กี่ไบต์ในการรับส่งที่กำลังทำงานอยู่แล้ว
แผนการวัดบน Android ที่ทำซ้ำได้
1. บันทึกสภาพแวดล้อม
จดรุ่นโทรศัพท์ บิลด์ Android เวอร์ชันแอป เวอร์ชันไลบรารีการเข้ารหัส โหมดบิลด์ สถานะแบตเตอรี่ และสภาวะความร้อน บันทึกประเภทเครือข่ายและสภาพสัญญาณ อย่าเผยแพร่ข้อมูลบัญชีส่วนตัวหรือเนื้อหาในแพ็กเก็ตในรายงานเบนช์มาร์ก
2. แยกการทดสอบองค์ประกอบพื้นฐานออกจากการทดสอบแอป
การทดสอบองค์ประกอบพื้นฐานวัดการสร้างคีย์ การห่อหุ้ม หรือการแกะห่อหุ้มแยกกัน ส่วนการทดสอบทั้งแอปวัดการสร้างเซสชัน การส่งข้อความ และการฟื้นตัวหลังการเชื่อมต่อขาดหาย หากมีผลทั้งสองแบบให้รายงานทั้งคู่ อย่าเรียกผลแบบหนึ่งว่าเป็นอีกแบบหนึ่ง
ทดสอบซ้ำหลายรอบและรายงานการกระจาย เช่น ค่ามัธยฐานและค่าเปอร์เซ็นไทล์สูง แทนการเลือกเฉพาะรอบที่เร็วที่สุด การอุ่นเครื่อง การคอมไพล์ระหว่างรัน และการลดประสิทธิภาพเมื่อเครื่องร้อนอาจส่งผลต่อผลลัพธ์
3. กำหนดภาระงานที่สมจริง
- เริ่มต้นเซสชันข้อความส่วนตัวใหม่
- ส่งข้อความจำนวนและขนาดคงที่ในเซสชันที่เริ่มต้นไว้แล้ว
- ทดสอบการข้ามจุดรีเฟรชคีย์ที่ระบุไว้ในเอกสาร
- เพิ่มหรือลบสมาชิกในกลุ่มทดสอบ หากรองรับ
- ส่งไฟล์แนบเดียวกันภายใต้เงื่อนไขเดียวกัน
- ปล่อยแอปไว้นิ่งเป็นช่วงเวลาที่กำหนด แล้ววัดพฤติกรรมเบื้องหลังแยกต่างหาก
ใช้เนื้อหาสังเคราะห์และบัญชีทดสอบที่เจ้าของยินยอม การทดสอบกลุ่มควรระบุจำนวนสมาชิก ไม่สามารถนำผลของกลุ่มสองคนไปสรุปใช้กับกลุ่มใหญ่โดยไม่ชี้แจง
4. วัดพลังงานควบคู่กับเวลา
Power Profiler ของ Android Studio สามารถแสดงความสัมพันธ์ระหว่างกิจกรรมกับการวัดรางจ่ายไฟบนฮาร์ดแวร์ที่รองรับ Google เตือนว่านี่เป็นการวัดระดับอุปกรณ์ กิจกรรมอื่นจึงทำให้เกิดสัญญาณรบกวน วิธีการวัดที่รองรับแตกต่างกันตามอุปกรณ์
ควบคุมความสว่างหน้าจอ งานเบื้องหลัง สภาพเครือข่าย และระยะเวลาทดสอบ ทำภาระงานเดิมซ้ำและเปรียบเทียบสิ่งที่มีเงื่อนไขเหมือนกัน หากวิธีที่ใช้ไม่สามารถแยกส่วนที่เกิดจากการเข้ารหัสได้ ให้ระบุข้อจำกัดนี้แทนการโยนการใช้แบตเตอรี่ทั้งหมดให้เป็นผลจาก ML-KEM
ภาพประกอบการจัดชุดวัด ไม่ใช่ผลเบนช์มาร์กที่บันทึกไว้
ตารางผลลัพธ์ที่มีประโยชน์ควรมีอะไรบ้าง?
| ช่องผลลัพธ์ | ตัวอย่างข้อมูลที่ควรบันทึก |
|---|---|
| ภาระงาน | เซสชันใหม่ การส่งข้อความในเซสชันเดิม หรือการรีเฟรชคีย์ |
| สภาพแวดล้อม | อุปกรณ์ บิลด์แอป และเครือข่ายที่ใช้อย่างเจาะจง |
| รอบทดสอบ | จำนวนรอบและวิธีจัดการรอบอุ่นเครื่อง |
| เวลา | ค่ามัธยฐาน ความแปรผัน และหน่วย |
| ปริมาณข้อมูล | จำนวนไบต์ที่วัดได้และเงื่อนไขการส่งซ้ำ |
| พลังงาน | วิธีการ ช่วงเวลา และความไม่แน่นอน |
| ข้อจำกัด | สิ่งที่การทดสอบไม่ได้แยกวัดหรือไม่ครอบคลุม |
เว้นช่องที่ยังไม่ได้วัดให้ว่าง หรือระบุว่า “ไม่ได้วัด” แผนภูมิแท่งพลังงานเพื่อประกอบคำอธิบายที่แต่งสัดส่วนขึ้นมาไม่ใช่หลักฐาน
แล้วภาพถ่ายและวิดีโอล่ะ?
ไฟล์แนบขนาดใหญ่มักใช้การเข้ารหัสแบบสมมาตร แทนการใช้ ML-KEM กับเนื้อหาทุกบล็อก การสร้างคีย์ยังอาจส่งผลต่อการเริ่มต้น ขณะที่การประมวลผลไฟล์ การจัดเก็บ การส่งผ่านเครือข่าย และตรรกะการลองใหม่ส่งผลต่อการทำงานโดยรวม ต้องวัดสัดส่วนผลกระทบจากภาระงานจริง การกล่าวว่า “ไม่มีทางสังเกตเห็นได้เลย” ไม่ใช่ข้ออ้างสากลที่มีเหตุผลรองรับ
คำถามที่พบบ่อย
ML-KEM-768 ช้ากว่า P-256 เสมอหรือไม่?
ไม่มีผลเปรียบเทียบเดียวที่ใช้ได้กับทุกไลบรารีและฮาร์ดแวร์ เปรียบเทียบการทำงานแบบเดียวกันภายใต้เงื่อนไขเดียวกัน แล้ววัดโพรโทคอลไฮบริดแบบครบถ้วนแยกต่างหาก
เช็กซัม APK รับรองผลการวัดประสิทธิภาพหรือไม่?
เมื่อเทียบกับค่าอ้างอิงที่เชื่อถือได้ เช็กซัมสามารถระบุไฟล์ที่ใช้ทดสอบอย่างเจาะจงได้ แต่ไม่ได้รับรองวิธีทดสอบ ความปลอดภัยของการนำไปใช้ หรือการวัดพลังงาน
ผู้ใช้ควรปิดการเข้ารหัสเพื่อประหยัดแบตเตอรี่หรือไม่?
อย่าแลกข้อกำหนดด้านความปลอดภัยกับข้ออ้างด้านประสิทธิภาพที่ไม่มีหลักฐานรองรับ ให้ระบุสาเหตุที่แท้จริงของการใช้แบตเตอรี่ก่อน แล้วใช้การตั้งค่าหรืออัปเดตที่รองรับ
