Efecto de los algoritmos poscuánticos en el rendimiento de red

En las dos primeras entradas de esta serie hablé de dos iniciativas clave de la criptografía poscuántica: una para corregir el establecimiento de claves y otra para corregir la autenticación. Aunque son dos problemas distintos, tienen algo en común: ambos cambios afectarán al rendimiento de los protocolos de red cifrados.

De los efectos de los cambios en el establecimiento de claves se habla mucho, pero Google ha observado solo un pequeño aumento en la latencia del handshake. No parece gran cosa, pero importa a gran escala. Existe una preocupación mucho mayor sobre el tamaño de las firmas poscuánticas, cuyos efectos podrían ser mucho peores según el enfoque que se adopte.

Para entender por qué ocurre esto, primero hay que entender los principios básicos del cifrado y luego cómo TLS los utiliza para ofrecer seguridad. En este artículo profundizo en los detalles del handshake TLS, destacando las partes de establecimiento de claves y autenticación, y el efecto de los cambios poscuánticos en esta parte crucial de la comunicación cifrada.

A grandes rasgos, cuando hablamos de cifrado, lo que realmente queremos suele describirse en tres aspectos: confidencialidad, autenticación e integridad. Para lograr estas propiedades combinamos primitivas criptográficas para diseñar protocolos. En cualquier protocolo criptográfico, la mayor parte de la complejidad está en el handshake, que hace más o menos lo siguiente:

• Acordar parámetros de cifrado comunes
• Autenticarse, idealmente ambas partes, aunque lo más habitual es que solo lo haga el servidor
• Acordar las claves de cifrado (establecimiento de claves)
• Validar la integridad del handshake para asegurar que no haya habido manipulación

Ahí ocurre mucho más de lo que parece. Los protocolos populares también deben resolver la interoperabilidad, es decir, el arte de lograr que cientos de herramientas y productos fabricados por distintos proveedores se entiendan entre sí, a pesar de estar a menudo mal implementados, ser antiguos o incluso estar obsoletos.

La parte de cifrado propiamente dicha resulta casi aburrida comparada con el handshake, sobre todo hoy en día, cuando el llamado cifrado autenticado es la norma. Básicamente se indica qué algoritmo de cifrado usar y con qué clave, se introducen unos datos de entrada y se obtienen unos datos de salida. Para evitar ataques como la repetición, la reordenación o la eliminación de datos, todos los paquetes de datos cifrados forman una cadena inmutable y comparten una comprobación de integridad común y continua.

Ya hemos visto lo compleja que es la criptografía en los protocolos. En TLS, un handshake consta de varios flights. Dentro de cada flight se envían varios mensajes del protocolo de un lado a otro, prácticamente al mismo tiempo. Aquí tienes un esquema sencillo (hay un diagrama más detallado en la RFC, por si te interesa):

1. El cliente inicia el handshake enviando un mensaje ClientHello.
2. El servidor acepta la conexión, pasa al cifrado, envía su certificado, demuestra que posee la clave privada correspondiente y completa el handshake.
3. El cliente valida los datos del servidor y completa el handshake por su parte. A continuación, empieza a enviar datos de la aplicación (por ejemplo, HTTP).
4. El servidor completa el handshake por su parte y luego responde a los datos de la aplicación.

Si observamos el handshake desde el punto de vista de la red, vemos que cada flight consta de uno o varios paquetes de red, según la cantidad de datos que haya que enviar. Como los paquetes tardan un tiempo en llegar al otro extremo, y la respuesta también tarda en volver, existe cierta espera entre los flights. Un handshake TLS completo requiere dos round trips entre cliente y servidor. Volveremos sobre esto más adelante.

Cada handshake implica lo siguiente:

• Operaciones criptográficas en la CPU
• Construcción de los mensajes del protocolo
• Envío de bytes a la red
• Espera de respuesta del otro lado
• Procesamiento de los paquetes recibidos

Si necesitas más información, consulta la RFC 9846 de TLS 1.3, recientemente actualizada. Después, abre Wireshark y observa los handshakes reales tal como los realizan los navegadores y otras herramientas.

La criptografía se paga con más procesamiento de CPU y con latencia de red. Para lo primero, basta con comprar más CPU. Para lo segundo, la latencia de red ralentiza nuestros sitios web, lo que se traduce en menos ingresos.

Veamos ambos aspectos con más detalle:

• CPU: En los primeros tiempos de la criptografía, las CPU eran mucho más lentas que hoy y supónian un cuello de botella importante. Entonces era habitual cifrar solo una parte del tráfico. Por suerte, hoy la situación es mucho mejor y podemos cifrarlo todo. La criptografía tiene un coste medible, pero no es elevado en comparación con sus beneficios.
• Latencia: El verdadero coste de la criptografía está en los round trips adicionales que conlleva. Para realizar un handshake TCP se necesita un round trip. Se envía una solicitud, que viaja por la red, y luego se espera a que la respuesta regrese. Para realizar un handshake TLS sobre una conexión TCP ya abierta, se necesitan dos round trips más. Así, si inicias una nueva conexión de Londres a Nueva York, no puedes evitar esperar 3x90=270ms mientras los paquetes van y vienen. QUIC, que se basa en UDP, puede abrir una conexión en menos tiempo, solo 180ms.

En cuanto a la criptografía poscuántica, que en el contexto de TLS hoy significa ML-KEM (para el establecimiento de claves) y ML-DSA (autenticación), las diferencias en los requisitos de CPU no son significativamente diferentes.

Con la latencia de red la historia es completamente distinta, y es lo que tiene el potencial de afectar negativamente al rendimiento al forzar condiciones que aumentan el número de round trips necesarios durante la fase inicial del handshake. Esto puede ocurrir por uno de estos dos mecanismos:

• Suposiciones sobre key shares: En TLS 1.3, los clientes tienen que "adivinar" qué key shares podría admitir un servidor. Históricamente, todos los servidores TLS 1.3 admitían X25519, así que eso es lo que todos enviaban. Hoy, los clientes modernos envían X25519 además de X25519MLKEM768, y eso funciona la mayoría de las veces. Cuando no funciona, el servidor tiene que solicitar un reintento del ClientHello, mediante un mensaje HelloRetryRequest. Este mensaje contiene la información sobre qué métodos de establecimiento de claves admite el servidor. Si el servidor admite un algoritmo coincidente, puede volver a intentarlo, pero este proceso añade otro round trip.
• Slow start: Al inicio de una nueva conexión, no se conocen las condiciones de la red, por lo que los protocolos suelen empezar despacio, aumentando la velocidad a medida que se intercambian más paquetes. Este enfoque suele llamarse Slow Start en TCP, y existen equivalentes en otros protocolos (por ejemplo, QUIC). La cantidad de datos que se puede enviar inicialmente se denomina ventana de congestión inicial. El valor predeterminado en los servidores actuales es de unos 14,5 KB, aunque las CDN pueden permitir valores mayores, por ejemplo 30-45 KB. En resumen, una vez enviados todos los datos permitidos, hay que esperar una respuesta, lo que añade otro round trip.

Así que la ventana de congestión inicial es el nuevo cuello de botella. Si recuerdas mi artículo anterior, en el que hablé sobre el tamaño de las firmas poscuánticas, una transición directa de firmas ECDSA a ML-DSA en los certificados y mensajes del protocolo podría añadir entre 14 KB y 18 KB al handshake TLS, lo que reventaría por completo la ventana de congestión inicial predeterminada de la mayoría de los servidores.

Aunque siempre es posible aumentar el tamaño de la ventana de congestión inicial (suponiendo que nuestras redes lo soporten), también hay que tener en cuenta que negociar TLS no es un fin en sí mismo: encima hay que montar un protocolo de aplicación. En la práctica, esto significa que lo ideal es entregar toda la página de inicio del sitio de una sola vez, para que el navegador pueda empezar a procesarla.

Además de encarecer y ralentizar las cosas, unos cambios tan importantes suelen provocar también roturas. Es, en cualquier caso, un problema que debemos abordar en lo que respecta al rendimiento de red.

Como hemos visto, en TLS el handshake comienza con un ClientHello. En este mensaje, el cliente envía su solicitud al servidor y proporciona los parámetros iniciales. Hace tiempo, este mensaje solía ser bastante pequeño, incluso menos de 256 bytes. Con los años, a medida que aumentaba la complejidad de TLS, el tamaño del ClientHello creció, pero se mantuvo dentro del tamaño de un solo paquete de red. Como resultado, buena parte del software existente se escribió asumiendo que el ClientHello completo siempre llegaría en un único paquete.

Esa suposición se rompió recientemente cuando actualizamos el establecimiento de claves en TLS para incorporar ML-KEM-768, que exige 1.216 bytes adicionales. Al comprobar un ClientHello real hace un momento, observé que tenía 2.117 bytes en la última versión de Chrome. Eso supera con creces lo que se puede enviar en un solo paquete (unos 1.440 bytes de datos útiles).

Como resultado, estos nuevos ClientHello de gran tamaño atraviesan la red como dos segmentos TCP, y algunos programas y dispositivos no pueden gestionarlo, por diversos motivos. Suelen ser los infames middleboxes, dispositivos diseñados para inspeccionar el tráfico de red.

TLS tiene una larga historia de problemas con los middleboxes. Casi cada vez que ha sido necesaria una evolución del protocolo, los middleboxes se han interpuesto en el camino. Esto acabó dando lugar a GREASE, un método que incorpora datos falsos aleatorios para evitar suposiciones sobre lo que puede o no aparecer en los paquetes TLS.

Incluso si no se produce ningún problema con dispositivos intermedios, un ClientHello más grande implica enviar más datos y más paquetes. Las comunicaciones son más lentas, y aumenta la probabilidad de pérdida de paquetes, lo que puede provocar retransmisiones. Esto es, según lo informado por Google, un aumento medio del 4% en la latencia del handshake. En equipos de escritorio; peor en móviles.