Rendimiento de la criptografía poscuántica

He escrito bastante sobre el impacto de la criptografía poscuántica en el rendimiento de red (enlaces más abajo). Aun así, me pareció buena idea escribir otro artículo para resumir la situación actual, aportar información y referencias adicionales y, quizá, sacar algunas conclusiones.

En pocas palabras: aunque las primitivas poscuánticas como ML-KEM y ML-DSA tienen un coste de CPU asumible, el tamaño mucho mayor de sus claves públicas y firmas supone un problema serio de carga útil para las redes reales. Hacer pasar estos volúmenes de datos más grandes por los protocolos de transporte provoca fragmentación, supera las ventanas de congestión iniciales estándar y genera round trips adicionales que reducen directamente la velocidad de conexión.

Este artículo forma parte de una serie. No hace falta que hayas leído todas las entregas anteriores, pero sí te recomiendo estas dos por el contexto que aportan:

• Efecto de los algoritmos poscuánticos en el rendimiento de red
• Por qué las firmas poscuánticas están rompiendo los límites del handshake TLS

Esos dos artículos se centran en la teoría, pero verás que no aportan muchas pruebas. ¿Qué dicen la industria y el mundo académico?

Chrome fue el primer navegador en desplegar X25519MLKEM768 (un nuevo mecanismo híbrido de establecimiento de claves resistente a la computación cuántica), así que tiene sentido empezar por ahí. ¿Qué están observando en la práctica?

«Chrome registró un aumento del 4 % en la latencia del handshake TLS al desplegar ML-KEM, que ocupa aproximadamente 1 KB adicional en el ClientHello. Esto hizo que el tamaño del ClientHello superara la unidad máxima de transmisión (MTU) estándar de los paquetes en Internet, de unos 1400 bytes, lo que provocó que el ClientHello se fragmentara en dos paquetes de la capa de transporte subyacente (TCP o UDP)».

— David Adrian, en Post-quantum cryptography is too damn big

Sobre el mismo tema, Cloudflare ha publicado varios artículos interesantes sobre criptografía poscuántica. En lugar de buscar el mejor recurso, aquí tienes un enlace a toda la categoría. Para ahorrarte tiempo: sus conclusiones coinciden con las de Google. Las cargas útiles más grandes provocan fragmentación TCP, mayor probabilidad de pérdida de paquetes y retrasos de conexión medibles en redes reales.

Cuando introduces nuevas cargas útiles criptográficas y extensiones de protocolo en el mundo real, te topas de lleno con la osificación de los middleboxes: dispositivos de red y equipos de inspección de seguridad que cortan las conexiones simplemente porque encuentran estructuras o tamaños de datos para los que no estaban programados.

A medida que Google, Cloudflare, Meta y AWS ampliaron el despliegue del acuerdo de claves poscuántico, surgió una serie de problemas operativos concretos:

• Fallos en middleboxes y firewalls: los dispositivos de red y las pasarelas de seguridad descartan con frecuencia los mensajes ClientHello fragmentados en varios paquetes o rechazan extensiones TLS desconocidas. Los firewalls de Sophos con los modos de inspección de protección web activados han tenido problemas históricamente con los handshakes de clientes poscuánticos. Al mismo tiempo, usuarios de AWS Network Firewall han sufrido errores de coincidencia de reglas al procesar handshakes PQC con OpenSSL 3.5.1.
• Discrepancias en despliegues a gran escala: en el despliegue real de TLS de Meta (TLS-PQR), incluso tasas de intolerancia mínimas se tradujeron en millones de conexiones de usuarios afectadas. Del mismo modo, los despliegues de PQC más amplios de Cloudflare (pqc-to-origin y poscuántico para todos) pusieron de manifiesto que las rutas edge-a-origen y cliente-a-edge se enfrentan a entornos de middleboxes muy distintos.
• Casos extremos de fragmentación: cuando la MTU de la ruta de red cae por debajo de los estándares habituales o cuando los handshakes UDP/QUIC alcanzan límites estrictos de amplificación, los mensajes PQC de gran tamaño provocan bucles de descarte, un fenómeno documentado en detalle por proyectos de investigación como tldr.fail.

Los clientes que quieran comunicarse con servidores que no ofrezcan X25519 ni X25519MLKEM768 tendrán que emitir un HelloRetryRequest. En el futuro, esto podría afectar a los clientes que quieran usar un establecimiento de claves puramente ML-KEM, lo que obligaría a un round trip de red adicional cada vez que el key share previsto por el cliente no coincida con las capacidades del servidor.

Mientras tanto, estamos viendo problemas similares con los orígenes de las CDN: si un origen no admite los métodos de intercambio de claves habituales, se necesita un round trip adicional para completar el handshake. Cloudflare dispone de datos interesantes, que no están disponibles en ningún otro sitio, sobre qué prefieren los orígenes para el establecimiento de claves. En su investigación Automatic Key Exchange for Origins, demuestran cómo la negociación automática y dinámica de las preferencias de intercambio de claves evita los round trips de HelloRetryRequest, tan perjudiciales para el rendimiento, entre los nodos edge y los orígenes upstream.

Todavía no estamos viendo este problema, porque las cadenas de certificados poscuánticas son poco comunes. Donde se usan, es en redes privadas (más rápidas) y en clientes que tienen más control sobre la configuración de red y pueden ajustar sus pilas TCP.

Sin embargo, la investigación académica ofrece un adelanto claro de lo que podría ocurrir cuando la autenticación poscuántica llegue a la Web PKI pública:

• Cadenas de certificados y rendimiento del handshake: un completo estudio de rendimiento de Sikeridis et al. (NDSS 2020) evaluó los candidatos a firma PQC del NIST dentro de cadenas de certificados TLS 1.3. Descubrieron que usar un único esquema de firma PQC de gran tamaño en toda la cadena degrada seriamente el rendimiento y la latencia del servidor. Para mitigarlo, propusieron cadenas de certificados mixtas (combinando algoritmos rápidos y más grandes, como Falcon, con otros más pequeños y lentos, como Dilithium o SPHINCS+), que aceleran notablemente los handshakes y restablecen las tasas de conexión.
• Latencia de red frente a cuellos de botella de CPU: Benchmarking post-quantum cryptography in TLS, de Paquin, Stebila y Tam (Microsoft Research), demostró mediante un framework de emulación de red que el tiempo de cálculo de la CPU rara vez es el principal cuello de botella en TLS con PQC. En cambio, la latencia de red y la pérdida de paquetes dominan el tiempo total de carga de las páginas, debido al enorme tamaño de las claves públicas y los textos cifrados poscuánticos.
• TTFB y TTLB en condiciones de red reales: la investigación de Kampanakis y Childs-Klein (MADWeb 2024) evaluó el ciclo de vida completo de la conexión, el Time-To-First-Byte (TTFB) y el Time-To-Last-Byte (TTLB). Comprobaron que, aunque las cadenas de certificados PQC con muchos datos aumentan la latencia inicial del handshake entre un 20 y un 30 % en enlaces limpios, su impacto relativo se amortiza en gran medida al transferir grandes cargas de datos o en conexiones ya degradadas o con pérdidas.
• Microbenchmarks de caja blanca y caja negra: Sosnowski et al. (ACM CoNEXT '23) demostraron que, aunque el intercambio de claves basado en retículos se ejecuta más rápido que los algoritmos clásicos en la CPU, el mayor tamaño de las claves y de las cadenas de certificados aumenta la latencia a nivel de red en rutas con pérdidas.

Al pasar de los navegadores de escritorio y los potentes servidores edge a los módulos de seguridad de hardware (HSM), los microcontroladores IoT y los sistemas embebidos, la gran huella de memoria y el tamaño de los paquetes de la PQC imponen restricciones físicas importantes.

Los protocolos IoT estándar (como CoAP, DTLS y EDHOC) funcionan sobre redes inalámbricas de bajo consumo y con pérdidas, donde los búferes de paquetes se miden en kilobytes. Almacenar y reensamblar claves públicas o firmas PQC de varios kilobytes provoca rápidamente el agotamiento de los búferes, bucles de pérdida de fragmentos y un fuerte consumo de batería. Además, los HSM y las tarjetas inteligentes se enfrentan a límites estrictos de almacenamiento no volátil y a un ancho de banda de bus interno restringido al gestionar material de claves PQC y procesar pesadas firmas de firmware OTA (Over-The-Air).

El IETF está desarrollando activamente soluciones técnicas para adaptar los entornos con recursos limitados a los requisitos poscuánticos:

• RFC 9958: Post-Quantum Cryptography for Engineers: publicado por el grupo de trabajo PQUIP, este documento recoge orientaciones operativas, compromisos de rendimiento y criterios de selección de algoritmos para pilas de red con recursos limitados.
• draft-ietf-pquip-pqc-hsm-constrained: aborda los límites de los recursos físicos de hardware y detalla cómo las restricciones de estado, RAM y NVRAM en HSM, tarjetas inteligentes y microcontroladores embebidos afectan al almacenamiento de claves PQC, a los tiempos de procesamiento y a las actualizaciones de firmware.
• draft-rfcxml-pqc-key-fragmentation: analiza los riesgos de reensamblado en la capa de red y ofrece recomendaciones para evitar el agotamiento de búferes y los bucles de pérdida de paquetes al transmitir claves PQC fragmentadas por redes inalámbricas de bajo consumo (CoAP, DTLS, EDHOC, OSCORE).
• Firmas compactas y con estado: orientaciones para adoptar esquemas de firma basados en hash con estado (como LMS y XMSS, definidos en RFC 8554 / RFC 8708) para que el código de verificación y la sobrecarga de la verificación de firmas sean lo bastante ligeros para los bootloaders embebidos.

Tenemos muchos problemas, pero el rendimiento de cálculo no es uno de ellos. Los algoritmos PQC modernos basados en retículos, en concreto ML-KEM y ML-DSA, son rápidos desde el punto de vista computacional. En los procesadores x86 y ARM modernos, la generación de claves, el encapsulado y el desencapsulado basados en retículos suelen ejecutarse en menos ciclos de CPU que los intercambios ECDH o RSA tradicionales. Por suerte, al menos de esto no tenemos que preocuparnos, salvo que en el futuro decidamos cambiar a otros algoritmos.

A pesar de estos obstáculos estructurales, varios benchmarks empíricos sostienen que el TLS poscuántico no va a tumbar Internet, e incluso podría mejorar el rendimiento donde menos lo esperamos:

• La superioridad de cálculo compensa los bytes: Sosnowski et al. (ACM CoNEXT '23) demostraron que, como las primitivas basadas en retículos (ML-KEM) requieren muchísimos menos ciclos de CPU que las curvas clásicas de alta seguridad o RSA, el rendimiento global del servidor puede incluso aumentar en condiciones de red normales.
• Los microcontroladores pueden ser más rápidos con PQC: Gillot, Buchanan y Turino (arXiv:2610.27766) cuestionaron directamente la suposición de que el hardware IoT cedería ante las cargas útiles PQC. Tras probar decenas de configuraciones de TLS 1.3 en microcontroladores con recursos limitados (como la Raspberry Pi Pico W), descubrieron que las operaciones matemáticas de pocos ciclos de ML-KEM permitían completar los handshakes TLS poscuánticos mucho más rápido (hasta un ~41 % más rápido en los benchmarks) que los handshakes clásicos tradicionales, lo que demuestra que los dispositivos embebidos pueden ejecutar sin problemas un intercambio de claves resistente a la computación cuántica.
• Amortización de la carga útil en el tráfico real: la investigación de Kampanakis y Childs-Klein (MADWeb '24) destaca que, aunque la latencia del handshake PQC aumenta de forma aislada, se vuelve estadísticamente insignificante cuando se evalúa frente al Time-to-Last-Byte (TTLB) real y a cargas útiles HTTP típicas (>40 KB).
• Soluciones de arquitectura como KEMTLS: la investigación de Schwabe, Stebila y Wiggers (ACM CCS '20) demuestra que la autenticación no necesita obligatoriamente firmas de varios kilobytes: sustituir las firmas del handshake por KEM (AuthKEM) mantiene el volumen de bytes del handshake muy por debajo de los límites estándar de la ventana TCP.