Benchmark wymaga urządzenia, obciążenia, metody i określenia niepewności — nie tylko liczby, która sugeruje dużą szybkość.
Nie ma uzasadnionej, uniwersalnej wartości procentowej zużycia baterii przez ML-KEM-768 na Androidzie. Koszt zależy od implementacji, telefonu, zestawiania sesji, częstotliwości odświeżania kluczy i zachowania sieci. Szybki benchmark kryptograficzny na komputerze stacjonarnym nie pozwala ustalić czasu pracy na baterii całego komunikatora mobilnego.
Ten artykuł wyjaśnia, co można obliczyć na podstawie standardu, a co wymaga pomiarów. Na potrzeby tego artykułu nie przeprowadzono benchmarku zużycia baterii przez Livara na Androidzie. Poniższa procedura jest planem testów, a nie deklaracją uzyskanych wyników.
Co wynika ze standardu
ML-KEM to mechanizm enkapsulacji klucza: pomaga uzgodnić wspólny sekret, który protokół może wykorzystać do szyfrowania symetrycznego. Zgodnie z FIPS 203 ML-KEM-768 ma klucz enkapsulacji o długości 1184 bajtów i szyfrogram o długości 1088 bajtów. Łącznie te dwa obiekty zajmują 2272 bajty.
Ta suma nie jest pełnym rozmiarem uzgadniania połączenia w komunikatorze ani nie musi odpowiadać dodatkowemu ruchowi sieciowemu. Certyfikaty, podpisy, klasyczny materiał kluczowy, ramkowanie, kodowanie, klucze w pamięci podręcznej i retransmisje mogą zmieniać liczbę faktycznie wysyłanych bajtów. „768” jest identyfikatorem zestawu parametrów, a nie długością wspólnego sekretu wynoszącą 768 bitów; ten zestaw jest ukierunkowany na kategorię bezpieczeństwa 3 według NIST.
| Wielkość | Określona przez algorytm czy wymagająca pomiaru? |
|---|---|
| Długość klucza enkapsulacji i szyfrogramu | Określona przez wybrany zestaw parametrów ML-KEM |
| Czas generowania kluczy, enkapsulacji i dekapsulacji | Zmierzyć dla konkretnej implementacji i urządzenia |
| Liczba bajtów pełnego zestawienia sesji | Zmierzyć protokół, uwzględniając ramkowanie i ponowne próby |
| Opóźnienie wysyłania od końca do końca | Zmierzyć łącznie aplikację i sieć |
| Energia dla danego obciążenia | Zmierzyć w kontrolowanym eksperymencie na poziomie urządzenia |
Czy koszt jest ponoszony tylko raz na sesję?
Niekoniecznie. Protokół może korzystać z KEM podczas początkowej konfiguracji i ponownie przy okresowych postkwantowych aktualizacjach kluczy. Zmiany składu grupy, nowe urządzenia, nieudane sesje i odzyskiwanie po awarii mogą wywoływać dodatkowe operacje. Właściwą jednostką jest zdarzenie protokołu, a nie założenie, że każda rozmowa wykonuje dokładnie jedną operację KEM.
Opublikowana architektura LVR1 Livara opisuje okresowe epoki ML-KEM obok zwykłych kroków łańcucha wiadomości. Dlatego użyteczny benchmark musi obejmować zarówno wymianę wiadomości w stanie ustalonym, jak i zdarzenia odświeżania kluczy. Nie powinien sugerować, że operacje postkwantowe nigdy się nie powtarzają.
Sama liczba bajtów zapisanego szyfrogramu również niewiele mówi o energii. Dodatkowy pakiet może inaczej wpływać na działanie modułu radiowego niż kilka dodatkowych bajtów w już trwającej transmisji.
Powtarzalny plan pomiarów na Androidzie
1. Zapisz informacje o środowisku
Zanotuj model telefonu, kompilację Androida, wersję aplikacji, wersję biblioteki kryptograficznej, tryb kompilacji, stan baterii i warunki termiczne. Zapisz typ sieci i warunki sygnałowe. Nie publikuj prywatnych danych kont ani zawartości pakietów w raporcie z benchmarku.
2. Oddziel testy prymitywów od testów aplikacji
Test prymitywu kryptograficznego mierzy osobno generowanie kluczy, enkapsulację lub dekapsulację. Test całej aplikacji mierzy tworzenie sesji, wysyłanie wiadomości i odzyskiwanie po przerwaniu połączenia. Jeśli masz oba rodzaje wyników, przedstaw je oba; nie nazywaj jednego drugim.
Powtarzaj próby i podawaj rozrzut wyników, na przykład medianę i wysoki percentyl, zamiast wybierać najszybszy przebieg. Rozgrzewka, kompilacja w czasie wykonywania i ograniczanie wydajności wskutek temperatury mogą wpływać na wyniki.
3. Określ realistyczne obciążenia
- Zestaw nową sesję wiadomości bezpośrednich.
- Wyślij ustaloną liczbę wiadomości o ustalonej wielkości w istniejącej sesji.
- Przetestuj udokumentowany moment przejścia do odświeżenia kluczy.
- Dodaj lub usuń członka grupy testowej, jeśli jest to obsługiwane.
- Wyślij ten sam załącznik w tych samych warunkach.
- Pozostaw aplikację bez aktywności przez ustalony czas i osobno zmierz jej działanie w tle.
Używaj treści syntetycznych i kont testowych, których użytkownicy wyrazili zgodę. Test grupowy powinien podawać liczbę członków; wyniku dla dwóch osób nie wolno bez wyjaśnienia ekstrapolować na dużą grupę.
4. Mierz energię, a nie tylko czas
Power Profiler w Android Studio może korelować aktywność z pomiarami linii zasilania na obsługiwanym sprzęcie. Google ostrzega, że są to pomiary na poziomie całego urządzenia, więc inne działania wprowadzają szum. Obsługiwane metody pomiaru różnią się zależnie od urządzenia.
Kontroluj jasność ekranu, zadania w tle, warunki sieciowe i czas testu. Powtarzaj to samo obciążenie i porównuj porównywalne warunki. Jeśli twoja metoda nie pozwala wyodrębnić udziału kryptografii, napisz to zamiast przypisywać całe zużycie baterii ML-KEM.
Ilustracja stanowiska pomiarowego, a nie zarejestrowane wyniki benchmarku.
Co powinna zawierać użyteczna tabela wyników?
| Pole wyników | Przykład informacji do zapisania |
|---|---|
| Obciążenie | Nowa sesja, wymiana wiadomości w istniejącej sesji lub odświeżanie kluczy |
| Środowisko | Dokładne urządzenie, kompilacja aplikacji i sieć |
| Próby | Liczba prób i sposób traktowania przebiegów rozgrzewkowych |
| Czas | Mediana, zmienność i jednostki |
| Ruch | Zmierzone bajty i warunki retransmisji |
| Energia | Metoda, przedział pomiaru i niepewność |
| Ograniczenia | Czego test nie wyodrębnił lub nie objął |
Pozostaw niezmierzone komórki puste albo oznacz je jako „nie zmierzono”. Przykładowy wykres słupkowy energii z wymyślonymi udziałami względnymi nie jest dowodem.
A co ze zdjęciami i filmami?
Duże załączniki zazwyczaj korzystają z szyfrowania symetrycznego, a nie z ML-KEM dla każdego bloku treści. Uzgadnianie kluczy nadal może wpływać na przygotowanie operacji, natomiast przetwarzanie pliku, przechowywanie, transmisja sieciowa i logika ponownych prób wpływają na jej całość. Względny udział trzeba zmierzyć dla rzeczywistego obciążenia; „nigdy niezauważalne” nie jest rzetelnym twierdzeniem uniwersalnym.
Często zadawane pytania
Czy ML-KEM-768 jest zawsze wolniejszy niż P-256?
Nie ma uniwersalnego porównania obowiązującego dla wszystkich bibliotek i urządzeń. Porównaj te same operacje w tych samych warunkach, a następnie osobno zmierz cały protokół hybrydowy.
Czy suma kontrolna pliku APK potwierdza wyniki wydajności?
Porównanie z zaufanym wzorcem pozwala zidentyfikować dokładnie ten plik, który testowano. Nie potwierdza jednak poprawności metody testowej, bezpieczeństwa implementacji ani pomiaru energii.
Czy użytkownicy powinni wyłączyć szyfrowanie, by oszczędzać baterię?
Nie rezygnuj z wymaganego zabezpieczenia na podstawie niepopartego dowodami twierdzenia o wydajności. Najpierw ustal rzeczywiste źródło zużycia baterii i skorzystaj z obsługiwanych ustawień lub aktualizacji.
