SHARE THE PERSPECTIVE
Een benchmark vereist een apparaat, een werklast, een methode en onzekerheidsmarges — niet alleen een getal dat snel lijkt.

Er bestaat geen algemeen geldig, verdedigbaar percentage voor het batterijverbruik van ML-KEM-768 op Android. De kosten hangen af van de implementatie, de telefoon, het opzetten van sessies, de frequentie van sleutelverversing en het netwerkgedrag. Een snelle cryptografische benchmark op een desktop zegt niets beslissends over de batterijduur van een complete mobiele berichtenapp.

Dit artikel legt uit wat uit de standaard kan worden berekend en wat moet worden gemeten. Voor dit artikel is geen Livara-batterijbenchmark op Android uitgevoerd. De onderstaande procedure is een testplan, geen bewering over gemeten resultaten.

Wat de standaard ons vertelt

ML-KEM is een sleutelinkapselingsmechanisme: het helpt een gedeeld geheim tot stand te brengen dat een protocol voor symmetrische versleuteling kan gebruiken. Volgens FIPS 203 heeft ML-KEM-768 een inkapselingssleutel van 1184 bytes en een cijfertekst van 1088 bytes. Samen zijn die twee objecten 2272 bytes groot.

Dat totaal is niet de volledige omvang van de handshake van een berichtenprotocol en ook niet noodzakelijk de extra hoeveelheid netwerkverkeer die deze veroorzaakt. Certificaten, handtekeningen, klassiek sleutelmateriaal, framing, codering, gecachete sleutels en hertransmissies kunnen allemaal invloed hebben op het aantal daadwerkelijk verzonden bytes. De «768» is een aanduiding van een parameterset, geen lengte van 768 bits voor het gedeelde geheim; deze set is gericht op NIST-beveiligingscategorie 3.

Grootheid Vastgelegd door het algoritme of te meten?
Lengte van inkapselingssleutel en cijfertekst Vastgelegd door de gekozen ML-KEM-parameterset
Tijd voor sleutelgeneratie, inkapseling en uitkapseling Meten voor de daadwerkelijke implementatie en het apparaat
Bytes voor het volledig opzetten van een sessie Het protocol meten, inclusief framing en nieuwe pogingen
End-to-end-verzendvertraging App en netwerk samen meten
Energie per werklast Meten met een gecontroleerd experiment op apparaatniveau

Ontstaan de kosten maar één keer per sessie?

Niet noodzakelijk. Een protocol kan een KEM gebruiken bij het eerste opzetten van een sessie en opnieuw tijdens periodieke postkwantumsleutelupdates. Veranderingen in het groepslidmaatschap, nieuwe apparaten, mislukte sessies en herstel kunnen extra werk veroorzaken. De juiste eenheid is de protocolgebeurtenis, niet de aanname dat elk gesprek precies één KEM-bewerking uitvoert.

Livara's gepubliceerde LVR1-architectuur beschrijft periodieke ML-KEM-epochs naast de gebruikelijke stappen in berichtketens. Daarom moet een bruikbare benchmark zowel berichtenverkeer in stabiele toestand als sleutelverversingen omvatten. De benchmark mag niet beweren dat het postkwantumwerk nooit terugkeert.

Ook het aantal bytes in een opgeslagen cijfertekst zegt op zichzelf weinig over energie. Een extra pakket kan het gedrag van de radioverbinding anders beïnvloeden dan een paar extra bytes binnen een al actieve overdracht.

Een reproduceerbaar meetplan voor Android

1. Leg de omgeving vast

Noteer het telefoonmodel, de Android-build, de appversie, de versie van de cryptografische bibliotheek, de buildmodus, de batterijstatus en de thermische toestand. Leg ook het netwerktype en de signaalomstandigheden vast. Publiceer geen privégegevens van accounts of pakketinhoud in een benchmarkrapport.

2. Scheid tests van primitieven van app-tests

Een test van een cryptografische primitieve meet sleutelgeneratie, inkapseling of uitkapseling afzonderlijk. Een volledige app-test meet het aanmaken van een sessie, het verzenden van berichten en het herstellen na een onderbroken verbinding. Rapporteer beide als ze beschikbaar zijn; presenteer de ene niet als de andere.

Voer herhaalde proeven uit en rapporteer de spreiding, bijvoorbeeld de mediaan en een hoog percentiel, in plaats van alleen de snelste uitvoering te kiezen. Opwarmen, compilatie tijdens de uitvoering en thermische begrenzing kunnen de resultaten beïnvloeden.

3. Definieer realistische werklasten

  • Zet een nieuwe sessie voor directe berichten op.
  • Verstuur een vast aantal berichten van een vaste grootte binnen een bestaande sessie.
  • Test een gedocumenteerde overgang waarbij sleutels worden ververst.
  • Voeg een lid toe aan een testgroep of verwijder er een, als dit wordt ondersteund.
  • Verstuur dezelfde bijlage onder dezelfde omstandigheden.
  • Laat de app gedurende een vaste periode inactief en meet het achtergrondgedrag afzonderlijk.

Gebruik synthetische inhoud en testaccounts waarvan de gebruikers toestemming hebben gegeven. Vermeld bij een groepstest het aantal leden; een resultaat voor twee personen mag niet stilzwijgend naar een grote groep worden geëxtrapoleerd.

4. Meet naast tijd ook energie

De Power Profiler van Android Studio kan op ondersteunde hardware activiteiten correleren met metingen aan voedingslijnen. Google waarschuwt dat dit metingen op apparaatniveau zijn, waardoor andere activiteiten ruis veroorzaken. De ondersteunde meetmethoden verschillen per apparaat.

Houd de schermhelderheid, achtergrondactiviteiten, netwerkomstandigheden en testduur onder controle. Herhaal dezelfde werklast en vergelijk gelijkwaardige situaties. Als je methode de cryptografische bijdrage niet kan isoleren, vermeld dat dan in plaats van al het batterijverbruik aan ML-KEM toe te schrijven.

Telefoon naast een laptop en een klein horloge onder paarse verlichting.

Illustratie van een meetopstelling, geen vastgelegde benchmarkresultaten.

Wat hoort in een bruikbare resultatentabel?

Resultaatveld Voorbeeld van de vast te leggen informatie
Werklast Nieuwe sessie, berichtenverkeer in een bestaande sessie of sleutelverversing
Omgeving Exact apparaat, app-build en netwerk
Proeven Aantal en behandeling van opwarmruns
Tijdmetingen Mediaan, variatie en eenheden
Dataverkeer Gemeten bytes en omstandigheden van hertransmissies
Energie Methode, interval en onzekerheid
Beperkingen Wat de test niet heeft geïsoleerd of bestreken

Laat niet-gemeten cellen leeg of markeer ze als «niet gemeten». Een illustratief staafdiagram voor energie met verzonnen relatieve aandelen is geen bewijs.

Hoe zit het met foto's en video's?

Grote bijlagen gebruiken doorgaans symmetrische versleuteling in plaats van ML-KEM voor elk inhoudsblok. Het tot stand brengen van sleutels kan nog steeds invloed hebben op de voorbereiding, terwijl bestandsverwerking, opslag, netwerkoverdracht en de logica voor nieuwe pogingen de volledige bewerking beïnvloeden. De relatieve bijdrage moet voor de daadwerkelijke werklast worden gemeten; «nooit merkbaar» is geen deugdelijke algemene bewering.

Veelgestelde vragen

Is ML-KEM-768 altijd langzamer dan P-256?

Er bestaat geen universele vergelijking die voor alle bibliotheken en hardware geldt. Vergelijk dezelfde bewerkingen onder dezelfde omstandigheden en meet vervolgens het volledige hybride protocol afzonderlijk.

Valideert een APK-controlesom prestatieresultaten?

Deze kan het exacte geteste bestand identificeren door vergelijking met een vertrouwde referentie. De controlesom valideert niet de testmethode, de veiligheid van de implementatie of de energiemeting.

Moeten gebruikers versleuteling uitschakelen om batterij te besparen?

Geef een beveiligingsvereiste niet op vanwege een ongefundeerde prestatieclaim. Zoek eerst de daadwerkelijke oorzaak van het batterijverbruik en gebruik ondersteunde instellingen of updates.

Bronnen

Verifieer de Android-APK in het Proof Lab
CONTINUE THE THREADPost-quantum encryption ↗Android & device security ↗
YOU’VE REACHED THE ENDBack to the reading room ↗