Este artículo es el segundo de una serie sobre las decisiones técnicas en torno a la criptografía poscuántica. La serie empezó la semana pasada con el artículo sobre el tamaño de las firmas poscuánticas. No hace falta haber leído el primero para disfrutar de este.
Esta semana el IETF publicó oficialmente el último RFC necesario para estandarizar por completo el establecimiento de claves poscuántico en TLS, así que es buen momento para mirar de cerca el establecimiento de claves en esta nueva entrega.
Este aspecto de la migración es a la vez más simple y más complicado. En pocas palabras, la amenaza sobre el establecimiento de claves es inmediata y hay una urgencia clara por abordarla. El reto técnico es más sencillo y el diseño se resolvió con relativamente poco drama. Esa es la parte simple. En la parte complicada, la NSA eligió un camino que choca con la comunidad técnica y abrió en el IETF una brecha que sigue abierta. Sigue leyendo.
La amenaza del "Harvest Now, Decrypt Later"
Los protocolos criptográficos tienen muchas piezas, pero en general deben resolver tres aspectos clave: autenticación, establecimiento de claves y cifrado. Los algoritmos que se ejecutan en ordenadores cuánticos no amenazan por igual a los tres. Contra la autenticación, por ejemplo, la amenaza solo se materializa cuando hace falta autenticar. En TLS la autenticación es efímera, así que no corremos peligro inmediato. No lo haremos hasta que los ordenadores cuánticos sean una realidad práctica.
Los ordenadores cuánticos apenas afectarán al cifrado, pero el establecimiento de claves está bajo ataque hoy, mucho antes de que exista un ordenador cuántico [criptográficamente relevante] en funcionamiento. Un adversario capaz puede recopilar tráfico cifrado hoy, guardarlo y descifrarlo más adelante, cuando tenga acceso a un ordenador cuántico. Esta amenaza se conoce como "harvest now, decrypt later", o HNDL.
Dada esta asimetría, no sorprende que el trabajo empezara por buscar un nuevo enfoque para el establecimiento de claves. De hecho, Google anunció su primer experimento hace casi exactamente 10 años. Fue más o menos cuando el NIST empezó a planificar su concurso de criptografía poscuántica.
Diez años después, el establecimiento de claves híbrido domina
Hoy todos los navegadores modernos admiten un establecimiento de claves híbrido que combina criptografía tradicional (basada en curvas elípticas) con ML-KEM, el algoritmo que el NIST eligió primero para este fin. Hay tres variantes en uso: X25519MLKEM768, SecP256r1MLKEM768 y SecP384r1MLKEM1024. La construcción es la misma en los tres casos, y las diferencias principales están en los parámetros de la curva elíptica y los niveles de seguridad.
En el plano técnico, este nuevo establecimiento de claves se compone de las siguientes capas:
- Diffie-Hellman de curva elíptica (ECDH), parte de la especificación de TLS 1.3 desde el principio
- ML-KEM, estandarizado por el NIST en 2024 (aunque anunciado como ganador en 2022)
- RFC 9954: Hybrid Exchange in TLS 1.3
- RFC 10024: Post-Quantum Traditional Hybrid Key Agreement Mechanisms for TLS 1.3
¿Por qué tantas piezas? Al principio solo teníamos ECDH. Después hubo que inventar ML-KEM para hacer frente a la amenaza cuántica. Como ML-KEM es bastante nuevo y menos asentado, y como la criptografía de curva elíptica es pequeña y rápida, se decidió que un enfoque híbrido daría la mejor seguridad. Por desgracia, TLS no permitía un establecimiento de claves híbrido, así que hubo que diseñar la RFC 9954. Por último, la RFC 10024 se creó para unirlo todo.
Fíjate también en que ambas RFC dicen explícitamente "for TLS 1.3". El IETF intenta dejar claro que estos trabajos no se aplican a protocolos anteriores. De hecho, TLS 1.2 está congelado en funcionalidades (RFC 9851) y se están escribiendo documentos nuevos para marcar como obsoleto lo que se pueda (RFC 10015).
Según Cloudflare, que tiene un panel con lo que observa sobre criptografía poscuántica, alrededor del 71% del tráfico humano que llega a su CDN usa establecimiento de claves híbrido y está por tanto protegido frente a las amenazas cuánticas.
Ese es el titular, pero si bajas en la página verás que solo el 11% aproximadamente de los servidores de origen tiene la misma protección. Tras 10 años de trabajo, seguimos lejos de un soporte amplio del establecimiento de claves resistente al cuántico en el lado servidor. El primer número (71%) suena bien, pero ese adversario capaz que te preocupa atacará donde eres débil, no donde eres fuerte.
Costó más trabajo del que parece
Podrías pensar que el establecimiento de claves se resolvió rápido, pero solo lo parece desde lejos. Como decía, Google empezó hace mucho. Aquel primer experimento, iniciado en julio de 2016, terminó en noviembre del mismo año. Sirvió para demostrar que el enfoque era viable.
El segundo experimento arrancó a finales de 2019, como colaboración entre Cloudflare y Google. Usaba el mismo enfoque híbrido con otros dos algoritmos, NTRU-HRSS y SIKE. Tres años después, SIKE acabó siendo roto. Y eso reforzó la idea de los híbridos.
Tras la selección de ML-KEM por el NIST, el foco pasó a usarlo en construcciones híbridas. Fue llegando a las bibliotecas y los navegadores añadieron soporte. Cloudflare lo activó en octubre de 2022, con los algoritmos provisionales X25519Kyber512Draft00 y X25519Kyber768Draft00. ML-KEM tardó otros dos años en estandarizarse, y luego todos pasaron a X25519MLKEM768 y compañía.
Impacto de ML-KEM en el rendimiento del handshake TLS
En la entrega anterior dediqué el artículo entero al fuerte aumento del tamaño de las firmas poscuánticas. En la práctica, el paso al establecimiento de claves híbrido ya aumentó el tamaño del handshake TLS en unos 1.100 bytes en cada sentido.
En 2024, Google informó de un aumento mediano del 4% en la latencia del handshake por este cambio. AWS informó de un ligero aumento del tiempo de handshake en un entorno controlado, por el mayor coste de cálculo. La conclusión principal es que el aumento de latencia viene de tener que transferir más datos para completar el handshake TLS, y eso con solo 1 kB. El aumento por las firmas añadirá más de diez veces esa cifra.
A la NSA no le gusta la criptografía híbrida
La migración de los algoritmos de establecimiento de claves parece una historia de éxito, pero hay un bache: la Agencia de Seguridad Nacional de Estados Unidos (la todopoderosa NSA) no quiere criptografía híbrida.
En septiembre de 2022, la NSA lanzó su Commercial National Algorithm Suite 2.0 (nombre nuevo; antes se llamaba NSA Suite B). En sí fue un buen movimiento, porque fijó pronto un calendario de migración y aclaró qué algoritmos usar. Por desgracia, sus requisitos para el establecimiento de claves van a contracorriente.
En la comunidad técnica, la mayoría [es mi impresión, no una medición científica] prefiere el enfoque híbrido por la seguridad extra que aporta. La sensación es que necesitamos más tiempo para aceptar los nuevos algoritmos poscuánticos y probarlos más. Los criptógrafos son, por naturaleza, muy conservadores. Como muestra, esta semana aparecieron dos artículos de investigación interesantes, uno que podría mellar la seguridad de los problemas de retículos y otro sobre Classic McEliece. Nada está roto todavía, pero solemos recordar que los ataques solo mejoran.
La división se ve sobre todo en el grupo de trabajo TLS del IETF, como te dirá cualquiera que siga la lista de correo. El punto de discusión es este: ¿debería el IETF publicar un RFC informativo que documente el establecimiento de claves con ML-KEM puro? Por un lado están quienes dicen que, por los requisitos de la NSA, ese algoritmo se va a usar y todos necesitamos trabajar sobre la misma especificación. Por otro, quienes sostienen que el enfoque híbrido ya se ha desplegado con éxito, así que para qué dar legitimidad a uno menos seguro.
Para aclararlo, la dirección actual no es solo marcar este trabajo como informativo (es decir, no un estándar), sino también señalarlo como no recomendado. Ni así se han evitado discusiones interminables en la lista. El documento (draft-ietf-tls-mlkem-09) está actualmente en Last Call. También está implementado ya en algunos navegadores, con menor prioridad que los híbridos pero disponible para servidores que prefieran el enfoque ML-KEM puro.
Ivan Ristic is the Chief Scientist for Red Sift and former founder of Hardenize. Learn more about how Red Sift helps organizations with their Certificate Monitoring.