Un test exige un appareil, une charge de travail, une méthode et une incertitude, pas seulement un chiffre qui semble rapide.
Il n’existe aucun pourcentage universel de consommation de batterie que l’on puisse raisonnablement attribuer à ML-KEM-768 sur Android. Le coût dépend de l’implémentation, du téléphone, de l’établissement des sessions, de la fréquence de renouvellement des clés et du comportement du réseau. Un test cryptographique rapide sur un ordinateur de bureau ne démontre pas l’autonomie d’une messagerie mobile complète.
Cet article explique ce que l’on peut calculer à partir de la norme et ce qui nécessite des mesures. Aucun test de consommation de batterie de Livara sur Android n’a été réalisé pour cet article. La procédure ci-dessous est un plan de test, et non un résultat revendiqué.
Ce que nous apprend la norme
ML-KEM est un mécanisme d’encapsulation de clés : il contribue à établir un secret partagé qu’un protocole peut utiliser pour le chiffrement symétrique. Dans FIPS 203, ML-KEM-768 possède une clé d’encapsulation de 1184 octets et un texte chiffré de 1088 octets. Ensemble, ces deux objets représentent 2272 octets.
Ce total n’est ni la taille complète d’une négociation initiale de messagerie ni nécessairement son surcoût réseau. Les certificats, les signatures, les éléments de clé classiques, la mise en trames, l’encodage, les clés en cache et les retransmissions peuvent tous modifier le nombre d’octets réellement envoyés. Le nombre « 768 » désigne un jeu de paramètres, et non un secret partagé de 768 bits ; ce jeu vise la catégorie de sécurité 3 du NIST.
| Grandeur | Fixée par l’algorithme ou à mesurer ? |
|---|---|
| Longueur de la clé d’encapsulation et du texte chiffré | Définie par le jeu de paramètres ML-KEM sélectionné |
| Temps de génération des clés, d’encapsulation et de décapsulation | À mesurer pour l’implémentation et l’appareil réellement utilisés |
| Octets de l’établissement complet d’une session | Mesurer le protocole, y compris la mise en trames et les nouvelles tentatives |
| Latence d’envoi de bout en bout | Mesurer l’application et le réseau ensemble |
| Énergie par charge de travail | À mesurer par une expérience contrôlée à l’échelle de l’appareil |
Le coût n’est-il payé qu’une fois par session ?
Pas nécessairement. Un protocole peut utiliser un KEM lors de la configuration initiale, puis à nouveau lors des mises à jour périodiques des clés post-quantiques. Les changements de membres d’un groupe, les nouveaux appareils, les sessions échouées et les opérations de récupération peuvent entraîner du travail supplémentaire. La bonne unité est l’événement de protocole, et non l’hypothèse selon laquelle chaque conversation effectue exactement une opération KEM.
L’architecture LVR1 publiée par Livara décrit des époques ML-KEM périodiques parallèlement aux étapes habituelles des chaînes de messages. Un test pertinent doit donc couvrir à la fois la messagerie en régime établi et les événements de renouvellement des clés. Il ne doit pas prétendre que le travail post-quantique ne se reproduit jamais.
Le nombre d’octets d’un texte chiffré stocké renseigne lui aussi peu sur l’énergie à lui seul. Un paquet supplémentaire peut avoir un effet différent sur le comportement de la radio que quelques octets de plus dans un transfert déjà actif.
Un plan de mesure reproductible sur Android
1. Consigner l’environnement
Notez le modèle du téléphone, le build Android, la version de l’application, celle de la bibliothèque cryptographique, le mode de compilation, l’état de la batterie et l’état thermique. Consignez le type de réseau et les conditions de réception du signal. Ne publiez pas de données privées de comptes ni de contenu de paquets dans un rapport de test.
2. Séparer les tests de primitives et d’application
Un test de primitive mesure isolément la génération de clés, l’encapsulation ou la décapsulation. Un test de l’application complète mesure la création d’une session, l’envoi de messages et la reprise après une interruption de connexion. Présentez les deux si vous en disposez ; ne faites pas passer l’un pour l’autre.
Répétez les essais et indiquez la dispersion, par exemple la médiane et un percentile élevé, plutôt que de sélectionner l’exécution la plus rapide. La phase de mise en régime, la compilation à l’exécution et la limitation des performances due à la chaleur peuvent influer sur les résultats.
3. Définir des charges de travail réalistes
- Établir une nouvelle session de messages directs.
- Envoyer un nombre fixe de messages de taille définie dans une session déjà établie.
- Franchir un seuil documenté de renouvellement des clés.
- Ajouter ou retirer un membre d’un groupe de test, si cette fonction est prise en charge.
- Envoyer la même pièce jointe dans les mêmes conditions.
- Laisser l’application inactive pendant une durée fixe et mesurer séparément son comportement en arrière-plan.
Utilisez du contenu synthétique et des comptes de test avec le consentement des participants. Un test de groupe doit préciser le nombre de membres ; un résultat obtenu à deux personnes ne peut pas être extrapolé discrètement à un grand groupe.
4. Mesurer l’énergie, pas seulement le temps
Le Power Profiler d’Android Studio peut corréler l’activité avec des mesures sur les rails d’alimentation du matériel compatible. Google rappelle qu’il s’agit de mesures à l’échelle de l’appareil : d’autres activités introduisent donc du bruit. Les méthodes de mesure prises en charge varient selon les appareils.
Contrôlez la luminosité de l’écran, les tâches en arrière-plan, les conditions réseau et la durée du test. Répétez la même charge de travail et comparez ce qui est comparable. Si votre méthode ne permet pas d’isoler la contribution cryptographique, indiquez-le au lieu d’attribuer toute la consommation de batterie à ML-KEM.
Illustration d’un dispositif de mesure, et non de résultats de test enregistrés.
Que devrait contenir un tableau de résultats utile ?
| Champ de résultat | Exemple d’informations à consigner |
|---|---|
| Charge de travail | Nouvelle session, messagerie en régime établi ou renouvellement des clés |
| Environnement | Appareil exact, build de l’application et réseau |
| Essais | Nombre d’essais et traitement des exécutions de mise en régime |
| Temps | Médiane, variabilité et unités |
| Trafic | Octets mesurés et conditions de retransmission |
| Énergie | Méthode, intervalle et incertitude |
| Limites | Ce que le test n’a pas isolé ou couvert |
Laissez les cellules non mesurées vides ou indiquez « non mesuré ». Un diagramme en barres illustratif de l’énergie, fondé sur des parts relatives inventées, ne constitue pas une preuve.
Et pour les photos et les vidéos ?
Les pièces jointes volumineuses utilisent généralement le chiffrement symétrique, plutôt que ML-KEM pour chaque bloc de contenu. L’établissement des clés peut tout de même influer sur la phase initiale, tandis que le traitement des fichiers, le stockage, le transfert réseau et la logique de nouvelle tentative contribuent à l’opération complète. La contribution relative doit être mesurée sur la charge de travail réelle ; « jamais perceptible » n’est pas une affirmation universelle valable.
Questions fréquentes
ML-KEM-768 est-il toujours plus lent que P-256 ?
Aucune comparaison universelle ne vaut pour toutes les bibliothèques et tous les matériels. Comparez les mêmes opérations dans les mêmes conditions, puis mesurez séparément le protocole hybride complet.
La somme de contrôle d’un APK valide-t-elle les résultats de performance ?
Comparée à une référence de confiance, elle peut identifier le fichier exact testé. Elle ne valide ni la méthode de test, ni la sécurité de l’implémentation, ni la mesure de l’énergie.
Faut-il désactiver le chiffrement pour économiser la batterie ?
Ne renoncez pas à une exigence de sécurité sur la base d’une affirmation de performance non étayée. Identifiez d’abord la source réelle de la consommation de batterie et utilisez les réglages ou les mises à jour pris en charge.
