Un análisis más detallado del rendimiento de ML-KEM

Esta entrada de blog forma parte de una serie en la que abordo la migración poscuántica desde una perspectiva técnica. Nuestro objetivo es entender qué problemas hay que resolver, y cómo y por qué se toman ciertas decisiones. En definitiva, se trata de entender. Las dos primeras entradas trataron los retos relacionados con el aumento del tamaño de las firmas y los nuevos métodos de establecimiento de claves. En la tercera, examinamos las capas de red y el protocolo TLS para descubrir qué aspectos influyen en el rendimiento y cómo se verán afectados por la migración.

En esta cuarta entrada, analizamos las nuevas opciones de establecimiento de claves que incorporan ML-KEM para entender cómo se comportan en la práctica. Esta es la parte de la migración poscuántica que ya se ha implementado, al menos en el protocolo TLS. Las decisiones ya están tomadas, así que veamos cómo han afectado al rendimiento en la red.

Antes de emprender la migración poscuántica, TLS 1.3 ofrecía dos opciones de establecimiento de claves, ambas basadas en el algoritmo Diffie-Hellman; una clásica y otra con curvas elípticas. Solemos llamarlas DHE y ECHDE. (La última «E» de la abreviatura significa ephemeral, es decir, efímero. Eso es una ventaja, porque aporta forward secrecy.) ECHDE era y sigue siendo la opción dominante, gracias a mejores propiedades de seguridad con claves más pequeñas, mejor rendimiento y menores requisitos de almacenamiento en la red.

Con la migración poscuántica, TLS pasó al establecimiento de claves híbrido, que combina ECDHE con el estándar ML-KEM adoptado por el NIST. Al tratarse de un híbrido, cada handshake TLS transporta información sobre dos algoritmos; literalmente hacemos todo el doble. ¿Cómo ha afectado esto al protocolo?

Para averiguarlo, rescaté una vieja herramienta mía (un fork de un trabajo anterior de Vincent Bernat) que ya había usado antes para este tipo de medición. La porté a OpenSSL 3.5.5, que se incluye con Ubuntu 26.04 LTS. Esta versión de OpenSSL [o algo similar] es la que llevan actualmente los sistemas operativos LTS más recientes.

Mi herramienta está diseñada para medir los requisitos de CPU y transporte de red de varias suites de cifrado, algoritmos de establecimiento de claves y protocolos. En este caso, elegí probar cuatro opciones:

• Clave ECDSA-256 combinada con ECDHE-X25519 – la línea base, una opción moderna y rápida.
• Clave RSA-2048 combinada con ECDHE-X25519 – algo más lenta debido a RSA.
• Clave ECDSA-256 combinada con X25519MLKEM768 – la nueva opción híbrida PQC.
• Clave ECDSA-256 combinada con ML-KEM-1024 – la nueva opción PQC pura.

Solo podemos probar TLS 1.3, porque TLS 1.2 y versiones anteriores no se adaptarán a la criptografía poscuántica.

La medición se realiza en el mismo ordenador, ejecutando un cliente completo y un servidor completo, en el mismo proceso pero en hilos distintos. Medimos el consumo de CPU y monitorizamos el tamaño de cada handshake. Cada ejecución realizó 2.000 handshakes y se repitió entre 3 y 5 veces para que los valores se estabilizaran. Ten en cuenta que las mediciones de CPU son tiempo de CPU, lo cual es suficiente para nuestros fines de comparar un establecimiento de claves con otro, pero por lo demás no son comparables con mediciones realizadas en otro lugar.

Primero, echemos un vistazo al uso de CPU durante el establecimiento de claves.

Se ve enseguida por qué ECDSA es actualmente el algoritmo de clave preferido frente a RSA. Con este último, el servidor tiene que hacer 2,5 veces más trabajo en cada handshake. También existe una asimetría notable en el tiempo de CPU consumido por el cliente y el servidor: los servidores hacen 3 veces más trabajo en total.

Incluí RSA solo como contraste pero, para nuestros fines, podemos excluir esa medición y centrarnos en las otras tres, que usan todas ECDSA. ¿El veredicto? No hay diferencias significativas en el tiempo de CPU, sea cual sea el establecimiento de claves usado. Esto se debe a que ML-KEM es muy rápido. Aunque hay incrementos relativos no triviales, en términos absolutos las diferencias son mínimas.

A continuación, examinemos la cantidad de datos que van y vienen entre cliente y servidor.

Aquí vemos diferencias significativas. Comparando las dos mediciones de ML-KEM con X25519 como línea base, vemos que X25519MLKEM768 añade 1176 bytes al handshake del cliente y 1088 bytes al del servidor. De los dos, el incremento en el servidor (2x) es más significativo, porque ocupa espacio en la ventana de congestión inicial, que es el cuello de botella con el que nos toparemos en la práctica.

ML-KEM-1024, que es un algoritmo más robusto, ocupa aún más espacio. El lado del servidor del handshake aumenta en 1537 bytes, aproximadamente 2,6 veces más.

Como recordarás de mis artículos anteriores, usamos ML-KEM-1024 para la medición de ML-KEM puro porque es el mínimo que acepta la NSA como parte de su requisito Commercial National Security Algorithm (CNSA) 2.0.

Estas mediciones no cuentan toda la historia, porque el cliente y el servidor se ejecutan en la misma máquina, con una latencia de red mínima. Incluso a este nivel, vemos que el ML-KEM puro rinde algo peor que los demás métodos; requiere aproximadamente la misma CPU, pero más bytes en el handshake.

En la práctica, hay que tener en cuenta que los clientes TLS solo pueden enviar un pequeño número de key shares en su ClientHello inicial. Hoy en día se envían X25519 y X25519MLKEM768, pero no ML-KEM-1024. Esto significa que cualquier servidor que quiera esta última opción tiene que responder con una solicitud de reintento en cada conexión TLS completa, lo que añade otro round trip al handshake.

Añadir ML-KEM-1024 como tercer key share por defecto no tiene mucho sentido, dado que la mayor parte del mundo no lo va a usar. Por ahora, los servidores que necesiten una opción PQC pura tendrán que asumir esta penalización de rendimiento.

Esto probablemente no sea un problema en redes locales, donde los round trips se miden en milisegundos de un solo dígito, pero la penalización de rendimiento será claramente perceptible en Internet público. Si supiéramos qué establecimientos de claves admite un servidor concreto, podríamos enviar un solo key share, pero por ahora no tenemos la tecnología para distribuir esa información. Un RFC actualmente en curso («TLS Key Share Prediction») explora el uso de DNS para este fin, a través de los registros SVCB y HTTPS.