Una prueba necesita un dispositivo, una carga de trabajo, un método e incertidumbre, no solo una cifra que parezca rápida.
No hay un porcentaje universal de consumo de batería atribuible a ML-KEM-768 en Android que pueda justificarse. El coste depende de la implementación, el teléfono, el establecimiento de sesiones, la frecuencia de renovación de claves y el comportamiento de la red. Una prueba criptográfica rápida en un ordenador de sobremesa no demuestra la autonomía de una aplicación completa de mensajería móvil.
Este artículo explica qué se puede calcular a partir del estándar y qué requiere mediciones. No se realizó ninguna prueba de consumo de batería de Livara en Android para este artículo. El procedimiento siguiente es un plan de pruebas, no un resultado que se afirme haber obtenido.
Qué nos dice el estándar
ML-KEM es un mecanismo de encapsulación de claves: ayuda a establecer un secreto compartido que un protocolo puede utilizar para el cifrado simétrico. En FIPS 203, ML-KEM-768 tiene una clave de encapsulación de 1184 bytes y un texto cifrado de 1088 bytes. Juntos, estos dos objetos suman 2272 bytes.
Ese total no es el tamaño completo de la negociación inicial de un sistema de mensajería ni necesariamente su coste adicional de red. Los certificados, las firmas, el material de claves clásicas, el entramado, la codificación, las claves almacenadas en caché y las retransmisiones pueden cambiar el número de bytes que realmente se envían. «768» es un identificador del conjunto de parámetros, no la longitud de un secreto compartido de 768 bits; este conjunto apunta a la categoría de seguridad 3 del NIST.
| Magnitud | ¿La fija el algoritmo o hay que medirla? |
|---|---|
| Longitud de la clave de encapsulación y del texto cifrado | La define el conjunto de parámetros ML-KEM elegido |
| Tiempo de generación de claves, encapsulación y descapsulación | Medir en la implementación y el dispositivo reales |
| Bytes del establecimiento completo de la sesión | Medir el protocolo, incluidos el entramado y los reintentos |
| Latencia de envío de extremo a extremo | Medir la aplicación y la red conjuntamente |
| Energía por carga de trabajo | Medir mediante un experimento controlado a nivel de dispositivo |
¿Se paga el coste una sola vez por sesión?
No necesariamente. Un protocolo puede utilizar un KEM en la configuración inicial y volver a hacerlo durante las actualizaciones periódicas de claves poscuánticas. Los cambios en los miembros del grupo, los dispositivos nuevos, las sesiones fallidas y la recuperación pueden generar trabajo adicional. La unidad correcta es el evento del protocolo, no la suposición de que cada conversación realiza exactamente una operación KEM.
La arquitectura LVR1 publicada por Livara describe épocas periódicas de ML-KEM junto con los pasos habituales de las cadenas de mensajes. Por tanto, una prueba útil debe cubrir tanto la mensajería en régimen estable como los eventos de renovación de claves. No debe afirmar que el trabajo poscuántico nunca se repite.
El número de bytes de un texto cifrado almacenado tampoco dice mucho, por sí solo, sobre la energía. Un paquete adicional puede afectar al comportamiento de la radio de forma distinta a unos pocos bytes más dentro de una transferencia que ya está activa.
Un plan reproducible de medición en Android
1. Registrar el entorno
Anote el modelo del teléfono, la compilación de Android, la versión de la aplicación, la versión de la biblioteca criptográfica, el modo de compilación, el estado de la batería y el estado térmico. Registre el tipo de red y las condiciones de señal. No publique datos privados de cuentas ni el contenido de los paquetes en un informe de pruebas.
2. Separar las pruebas de primitivas y de aplicación
Una prueba de una primitiva mide de forma aislada la generación de claves, la encapsulación o la descapsulación. Una prueba de la aplicación completa mide la creación de una sesión, el envío de mensajes y la recuperación tras una interrupción de la conexión. Presente ambas si dispone de ellas; no etiquete una como si fuera la otra.
Realice ensayos repetidos e informe de la dispersión, por ejemplo mediante la mediana y un percentil alto, en lugar de seleccionar la ejecución más rápida. La fase de calentamiento, la compilación en tiempo de ejecución y la limitación térmica del rendimiento pueden afectar a los resultados.
3. Definir cargas de trabajo realistas
- Establecer una nueva sesión de mensajes directos.
- Enviar un número fijo de mensajes de tamaño definido en una sesión ya establecida.
- Atravesar un límite documentado de renovación de claves.
- Añadir o eliminar un miembro de un grupo de prueba, si se admite.
- Enviar el mismo archivo adjunto en las mismas condiciones.
- Dejar la aplicación inactiva durante un intervalo fijo y medir por separado su comportamiento en segundo plano.
Utilice contenido sintético y cuentas de prueba con el consentimiento de sus titulares. Una prueba de grupo debe indicar el número de miembros; un resultado con dos personas no puede extrapolarse a un grupo grande sin explicarlo.
4. Medir la energía además del tiempo
Power Profiler de Android Studio puede correlacionar la actividad con las mediciones de los raíles de alimentación en hardware compatible. Google advierte de que son mediciones a nivel de dispositivo, por lo que otras actividades introducen ruido. Los métodos de medición admitidos varían según el dispositivo.
Controle el brillo de la pantalla, el trabajo en segundo plano, las condiciones de red y la duración de la prueba. Repita la misma carga de trabajo y compare en condiciones equivalentes. Si su método no puede aislar la contribución criptográfica, indíquelo en lugar de atribuir todo el consumo de batería a ML-KEM.
Ilustración de un montaje de medición, no de resultados registrados de pruebas de rendimiento.
¿Qué debería contener una tabla de resultados útil?
| Campo del resultado | Ejemplo de la información que se debe registrar |
|---|---|
| Carga de trabajo | Nueva sesión, mensajería en régimen estable o renovación de claves |
| Entorno | Dispositivo exacto, compilación de la aplicación y red |
| Ensayos | Número y tratamiento de las ejecuciones de calentamiento |
| Tiempo | Mediana, variación y unidades |
| Tráfico | Bytes medidos y condiciones de retransmisión |
| Energía | Método, intervalo e incertidumbre |
| Limitaciones | Lo que la prueba no aisló o no cubrió |
Deje en blanco las celdas no medidas o márquelas como «no medido». Un gráfico de barras ilustrativo de la energía con proporciones relativas inventadas no constituye una prueba.
¿Y las fotos y los vídeos?
Los archivos adjuntos grandes suelen utilizar cifrado simétrico en lugar de ML-KEM para cada bloque de contenido. El establecimiento de claves puede seguir influyendo en la preparación inicial, mientras que el procesamiento de archivos, el almacenamiento, la transferencia por red y la lógica de reintentos contribuyen a la operación completa. La contribución relativa debe medirse con la carga de trabajo real; «nunca se nota» no es una afirmación universal válida.
Preguntas frecuentes
¿ML-KEM-768 es siempre más lento que P-256?
No existe una comparación universal válida para todas las bibliotecas y todo el hardware. Compare las mismas operaciones en las mismas condiciones y, después, mida por separado el protocolo híbrido completo.
¿La suma de comprobación de un APK valida los resultados de rendimiento?
Al compararla con una referencia de confianza, puede identificar el archivo exacto sometido a prueba. No valida el método de prueba, la seguridad de la implementación ni la medición de energía.
¿Deberían los usuarios desactivar el cifrado para ahorrar batería?
No renuncie a un requisito de seguridad basándose en una afirmación de rendimiento sin respaldo. Primero identifique el origen real del consumo de batería y utilice ajustes o actualizaciones compatibles.
