Ein Benchmark braucht ein Gerät, eine Arbeitslast, eine Methode und Angaben zur Unsicherheit – nicht nur eine Zahl, die schnell aussieht.
Für den Akkuverbrauch von ML-KEM-768 unter Android gibt es keine belastbare, allgemeingültige Prozentangabe. Der Aufwand hängt von der Implementierung, dem Smartphone, dem Sitzungsaufbau, der Häufigkeit von Schlüsselaktualisierungen und dem Netzwerkverhalten ab. Ein schneller Kryptografie-Benchmark auf einem Desktoprechner belegt nicht die Akkulaufzeit eines vollständigen mobilen Messengers.
Dieser Artikel erklärt, was sich aus dem Standard berechnen lässt und was gemessen werden muss. Für diesen Artikel wurde kein Android-Akku-Benchmark von Livara durchgeführt. Das folgende Vorgehen ist ein Testplan, kein behauptetes Messergebnis.
Was uns der Standard verrät
ML-KEM ist ein Mechanismus zur Schlüsselkapselung: Er hilft dabei, ein gemeinsames Geheimnis herzustellen, das ein Protokoll für symmetrische Verschlüsselung verwenden kann. In FIPS 203 hat ML-KEM-768 einen Kapselungsschlüssel von 1184 Bytes und einen Geheimtext von 1088 Bytes. Zusammen sind diese beiden Objekte 2272 Bytes groß.
Diese Summe ist weder die vollständige Größe eines Messaging-Handshakes noch zwangsläufig dessen zusätzlicher Netzwerkaufwand. Zertifikate, Signaturen, klassisches Schlüsselmaterial, Framing, Kodierung, zwischengespeicherte Schlüssel und erneute Übertragungen können die tatsächlich gesendete Bytezahl verändern. Die „768“ bezeichnet einen Parametersatz, nicht die Länge eines gemeinsamen Geheimnisses von 768 Bit; dieser Satz zielt auf NIST-Sicherheitskategorie 3 ab.
| Größe | Vom Algorithmus vorgegeben oder zu messen? |
|---|---|
| Länge des Kapselungsschlüssels und des Geheimtexts | Durch den gewählten ML-KEM-Parametersatz definiert |
| Zeit für Schlüsselerzeugung, Kapselung und Entkapselung | Für die tatsächliche Implementierung und das Gerät messen |
| Bytezahl des vollständigen Sitzungsaufbaus | Das Protokoll einschließlich Framing und Wiederholungsversuchen messen |
| Ende-zu-Ende-Sendelatenz | App und Netzwerk gemeinsam messen |
| Energie pro Arbeitslast | In einem kontrollierten Experiment auf Geräteebene messen |
Fällt der Aufwand nur einmal pro Sitzung an?
Nicht unbedingt. Ein Protokoll kann beim ersten Verbindungsaufbau einen KEM einsetzen und erneut bei regelmäßigen Postquanten-Schlüsselaktualisierungen. Änderungen der Gruppenmitgliedschaft, neue Geräte, fehlgeschlagene Sitzungen und Wiederherstellungsvorgänge können zusätzliche Arbeit auslösen. Die richtige Bezugsgröße ist das Protokollereignis, nicht die Annahme, dass jedes Gespräch genau eine KEM-Operation ausführt.
Livaras veröffentlichte LVR1-Architektur beschreibt regelmäßige ML-KEM-Epochen neben den üblichen Schritten der Nachrichtenketten. Ein aussagekräftiger Benchmark muss deshalb sowohl den laufenden Nachrichtenaustausch als auch Ereignisse zur Schlüsselaktualisierung abdecken. Er sollte nicht behaupten, dass der Postquanten-Aufwand nie wieder anfällt.
Auch die Bytezahl eines gespeicherten Geheimtexts sagt für sich genommen wenig über den Energieverbrauch aus. Ein zusätzliches Paket kann das Verhalten der Funkschnittstelle anders beeinflussen als ein paar zusätzliche Bytes innerhalb einer bereits laufenden Übertragung.
Ein reproduzierbarer Messplan für Android
1. Die Testumgebung dokumentieren
Notieren Sie Smartphone-Modell, Android-Build, App-Version, Version der Kryptografiebibliothek, Build-Modus, Akkuzustand und thermischen Zustand. Halten Sie Netzwerktyp und Signalbedingungen fest. Veröffentlichen Sie in einem Benchmark-Bericht keine privaten Kontodaten oder Paketinhalte.
2. Tests von Grundoperationen und Anwendung trennen
Ein Test einer kryptografischen Grundoperation misst Schlüsselerzeugung, Kapselung oder Entkapselung isoliert. Ein Test der gesamten App misst den Sitzungsaufbau, das Senden von Nachrichten und die Wiederherstellung nach einer Verbindungsunterbrechung. Berichten Sie nach Möglichkeit über beides; geben Sie nicht das eine als das andere aus.
Führen Sie wiederholte Versuche durch und berichten Sie über die Streuung, etwa mit Median und einem hohen Perzentil, statt den schnellsten Durchlauf auszuwählen. Aufwärmphase, Laufzeitkompilierung und thermisch bedingte Leistungsdrosselung können die Ergebnisse beeinflussen.
3. Realistische Arbeitslasten definieren
- Eine neue Sitzung für Direktnachrichten aufbauen.
- In einer bestehenden Sitzung Nachrichten in festgelegter Anzahl und Größe senden.
- Einen dokumentierten Übergang zur Schlüsselaktualisierung durchlaufen.
- Wenn unterstützt, ein Mitglied zu einer Testgruppe hinzufügen oder daraus entfernen.
- Denselben Anhang unter denselben Bedingungen senden.
- Die App für eine feste Zeitspanne im Leerlauf lassen und ihr Hintergrundverhalten separat messen.
Verwenden Sie synthetische Inhalte und Testkonten mit Zustimmung der Beteiligten. Ein Gruppentest sollte die Mitgliederzahl nennen; ein Ergebnis mit zwei Personen darf nicht stillschweigend auf eine große Gruppe übertragen werden.
4. Neben der Zeit auch die Energie messen
Der Power Profiler von Android Studio kann auf unterstützter Hardware Aktivitäten mit Messungen an den Stromversorgungsschienen in Beziehung setzen. Google weist darauf hin, dass dies Messungen auf Geräteebene sind und andere Aktivitäten deshalb Störeinflüsse verursachen. Die unterstützten Messmethoden unterscheiden sich je nach Gerät.
Kontrollieren Sie Bildschirmhelligkeit, Hintergrundaktivitäten, Netzwerkbedingungen und Testdauer. Wiederholen Sie dieselbe Arbeitslast und vergleichen Sie nur unter vergleichbaren Bedingungen. Wenn Ihre Methode den kryptografischen Anteil nicht isolieren kann, sagen Sie das, statt den gesamten Akkuverbrauch ML-KEM zuzuschreiben.
Illustration eines Messaufbaus, keine aufgezeichneten Benchmark-Ergebnisse.
Was sollte eine aussagekräftige Ergebnistabelle enthalten?
| Ergebnisfeld | Beispiel für die zu dokumentierenden Angaben |
|---|---|
| Arbeitslast | Neue Sitzung, laufender Nachrichtenaustausch oder Schlüsselaktualisierung |
| Umgebung | Genaues Gerät, App-Build und Netzwerk |
| Versuche | Anzahl und Umgang mit Aufwärmdurchläufen |
| Zeitmessung | Median, Streuung und Einheiten |
| Datenverkehr | Gemessene Bytes und Bedingungen für erneute Übertragungen |
| Energie | Methode, Messintervall und Unsicherheit |
| Einschränkungen | Was der Test nicht isoliert oder abgedeckt hat |
Lassen Sie nicht gemessene Zellen leer oder kennzeichnen Sie sie mit „nicht gemessen“. Ein beispielhaftes Energiebalkendiagramm mit erfundenen relativen Anteilen ist kein Beleg.
Wie sieht es mit Fotos und Videos aus?
Große Anhänge verwenden in der Regel symmetrische Verschlüsselung statt ML-KEM für jeden einzelnen Inhaltsblock. Die Herstellung eines gemeinsamen Schlüssels kann den Verbindungsaufbau dennoch beeinflussen, während Dateiverarbeitung, Speicherung, Netzwerkübertragung und Wiederholungslogik zum gesamten Vorgang beitragen. Der relative Anteil muss anhand der tatsächlichen Arbeitslast gemessen werden; „niemals spürbar“ ist keine haltbare allgemeingültige Aussage.
Häufig gestellte Fragen
Ist ML-KEM-768 immer langsamer als P-256?
Es gibt keinen allgemeingültigen Vergleich für alle Bibliotheken und Hardwareplattformen. Vergleichen Sie dieselben Operationen unter denselben Bedingungen und messen Sie das vollständige Hybridprotokoll anschließend separat.
Bestätigt eine APK-Prüfsumme die Leistungsergebnisse?
Im Vergleich mit einer vertrauenswürdigen Referenz kann sie genau die getestete Datei identifizieren. Sie bestätigt weder die Testmethode noch die Sicherheit der Implementierung oder die Energiemessung.
Sollten Nutzer die Verschlüsselung deaktivieren, um Akku zu sparen?
Verzichten Sie nicht aufgrund einer unbelegten Leistungsaussage auf eine Sicherheitsanforderung. Ermitteln Sie zuerst die tatsächliche Ursache des Akkuverbrauchs und nutzen Sie unterstützte Einstellungen oder Updates.
