Un benchmark richiede un dispositivo, un carico di lavoro, un metodo e un’incertezza, non soltanto un numero che sembri veloce.
Non esiste una percentuale universale e giustificabile di consumo della batteria per ML-KEM-768 su Android. Il costo dipende dall’implementazione, dal telefono, dall’instaurazione delle sessioni, dalla frequenza di rinnovo delle chiavi e dal comportamento della rete. Un benchmark crittografico veloce su un computer desktop non dimostra l’autonomia di un’applicazione completa di messaggistica mobile.
Questo articolo spiega che cosa si può calcolare a partire dallo standard e che cosa richiede misurazioni. Per questo articolo non è stato eseguito alcun benchmark del consumo della batteria di Livara su Android. La procedura seguente è un piano di test, non un risultato che si dichiara di aver ottenuto.
Che cosa ci dice lo standard
ML-KEM è un meccanismo di incapsulamento delle chiavi: aiuta a stabilire un segreto condiviso che un protocollo può usare per la cifratura simmetrica. In FIPS 203, ML-KEM-768 ha una chiave di incapsulamento di 1184 byte e un testo cifrato di 1088 byte. Insieme, questi due oggetti totalizzano 2272 byte.
Questo totale non è la dimensione completa dell’handshake di un sistema di messaggistica, né necessariamente il suo costo aggiuntivo di rete. Certificati, firme, materiale di chiavi classiche, organizzazione in frame, codifica, chiavi nella cache e ritrasmissioni possono tutti modificare il numero di byte effettivamente inviati. «768» identifica un insieme di parametri, non la lunghezza di un segreto condiviso di 768 bit; questo insieme mira alla categoria di sicurezza 3 del NIST.
| Grandezza | Fissata dall’algoritmo o da misurare? |
|---|---|
| Lunghezza della chiave di incapsulamento e del testo cifrato | Definita dall’insieme di parametri ML-KEM selezionato |
| Tempo di generazione delle chiavi, incapsulamento e decapsulamento | Misurare sull’implementazione e sul dispositivo effettivi |
| Byte dell’intera instaurazione della sessione | Misurare il protocollo, inclusi frame e tentativi ripetuti |
| Latenza di invio da un capo all’altro | Misurare insieme l’app e la rete |
| Energia per carico di lavoro | Misurare con un esperimento controllato a livello di dispositivo |
Il costo si sostiene una sola volta per sessione?
Non necessariamente. Un protocollo può usare un KEM nella configurazione iniziale e poi di nuovo durante gli aggiornamenti periodici delle chiavi post-quantistiche. I cambiamenti nei membri del gruppo, i nuovi dispositivi, le sessioni non riuscite e le operazioni di ripristino possono comportare altro lavoro. L’unità corretta è l’evento del protocollo, non l’ipotesi che ogni conversazione esegua esattamente un’operazione KEM.
L’architettura LVR1 pubblicata da Livara descrive epoche periodiche di ML-KEM accanto ai normali passaggi delle catene di messaggi. Un benchmark utile deve quindi coprire sia la messaggistica a regime sia gli eventi di rinnovo delle chiavi. Non dovrebbe affermare che il lavoro post-quantistico non si ripete mai.
Anche il numero di byte di un testo cifrato memorizzato, da solo, dice poco sull’energia. Un pacchetto in più può influire sul comportamento della radio in modo diverso da qualche byte aggiuntivo all’interno di un trasferimento già attivo.
Un piano di misurazione riproducibile su Android
1. Documentare l’ambiente
Annotare modello del telefono, build di Android, versione dell’app, versione della libreria crittografica, modalità di compilazione, stato della batteria e stato termico. Registrare il tipo di rete e le condizioni del segnale. Non pubblicare dati privati degli account o contenuti dei pacchetti in un rapporto di benchmark.
2. Separare i test delle primitive da quelli dell’applicazione
Un test di una primitiva misura isolatamente la generazione delle chiavi, l’incapsulamento o il decapsulamento. Un test dell’intera app misura la creazione di una sessione, l’invio di messaggi e il ripristino dopo un’interruzione della connessione. Riportare entrambi, se disponibili; non presentare l’uno come se fosse l’altro.
Ripetere le prove e riportare la dispersione, per esempio la mediana e un percentile alto, invece di scegliere l’esecuzione più veloce. La fase di riscaldamento iniziale, la compilazione in fase di esecuzione e la limitazione delle prestazioni dovuta alla temperatura possono influenzare i risultati.
3. Definire carichi di lavoro realistici
- Instaurare una nuova sessione di messaggi diretti.
- Inviare un numero fisso di messaggi di dimensione definita in una sessione già instaurata.
- Attraversare una soglia documentata di rinnovo delle chiavi.
- Aggiungere o rimuovere un membro in un gruppo di test, se supportato.
- Inviare lo stesso allegato nelle stesse condizioni.
- Lasciare l’app inattiva per un intervallo fisso e misurare separatamente il comportamento in background.
Usare contenuti sintetici e account di test con il consenso dei titolari. Un test di gruppo deve indicare il numero di membri; un risultato con due persone non può essere esteso a un gruppo numeroso senza dichiararlo.
4. Misurare l’energia oltre al tempo
Il Power Profiler di Android Studio può correlare l’attività con le misurazioni delle linee di alimentazione sull’hardware supportato. Google avverte che si tratta di misurazioni a livello di dispositivo, quindi altre attività introducono rumore. I metodi di misurazione supportati variano a seconda del dispositivo.
Controllare la luminosità dello schermo, le attività in background, le condizioni di rete e la durata del test. Ripetere lo stesso carico di lavoro e confrontare condizioni equivalenti. Se il metodo non consente di isolare il contributo della crittografia, dichiararlo invece di attribuire tutto il consumo della batteria a ML-KEM.
Illustrazione di un allestimento per le misurazioni, non di risultati di benchmark registrati.
Che cosa dovrebbe contenere una tabella dei risultati utile?
| Campo del risultato | Esempio di informazioni da registrare |
|---|---|
| Carico di lavoro | Nuova sessione, messaggistica a regime o rinnovo delle chiavi |
| Ambiente | Dispositivo esatto, build dell’app e rete |
| Prove | Numero e trattamento delle esecuzioni di riscaldamento iniziale |
| Tempi | Mediana, variabilità e unità |
| Traffico | Byte misurati e condizioni di ritrasmissione |
| Energia | Metodo, intervallo e incertezza |
| Limiti | Che cosa il test non ha isolato o coperto |
Lasciare vuote le celle non misurate o contrassegnarle con «non misurato». Un grafico a barre illustrativo dell’energia, con quote relative inventate, non costituisce una prova.
E per foto e video?
Gli allegati di grandi dimensioni usano generalmente la cifratura simmetrica, anziché ML-KEM per ogni blocco di contenuto. L’instaurazione delle chiavi può comunque influire sulla fase iniziale, mentre l’elaborazione dei file, l’archiviazione, il trasferimento di rete e la logica dei nuovi tentativi contribuiscono all’operazione completa. Il contributo relativo va misurato sul carico di lavoro effettivo; «non si nota mai» non è un’affermazione universale fondata.
Domande frequenti
ML-KEM-768 è sempre più lento di P-256?
Non esiste un confronto universale valido per tutte le librerie e tutte le piattaforme hardware. Confrontare le stesse operazioni nelle stesse condizioni, poi misurare separatamente l’intero protocollo ibrido.
La somma di controllo di un APK convalida i risultati delle prestazioni?
Se confrontata con un riferimento attendibile, può identificare il file esatto sottoposto al test. Non convalida il metodo di test, la sicurezza dell’implementazione o la misurazione dell’energia.
Gli utenti dovrebbero disattivare la cifratura per risparmiare batteria?
Non rinunciare a un requisito di sicurezza sulla base di un’affermazione sulle prestazioni priva di riscontri. Identificare prima l’effettiva origine del consumo della batteria e usare impostazioni o aggiornamenti supportati.
