Por qué las firmas poscuánticas están rompiendo los límites del apretón de manos TLS

En lo que respecta a la transición hacia la criptografía poscuántica, algunos aspectos son más sencillos que otros. La transición del establecimiento de claves a un enfoque resistente a la computación cuántica requirió algo de trabajo, pero llegamos a una solución (un enfoque híbrido que combina curvas elípticas con ML-KEM) sin demasiados problemas. Cuando hablamos de certificados y autenticación, la tarea será mucho más ardua, y todo se reduce a las diferencias en los tamaños de las firmas entre los algoritmos que usamos hoy (tradicionales) y los algoritmos que queremos utilizar mañana (poscuánticos).

Siempre que diseñamos algo, por ejemplo un protocolo criptográfico, tenemos en cuenta una variedad de factores, consideramos las posibilidades y sus ventajas y desventajas, y después tomamos decisiones de modo que cumplimos con las limitaciones que se nos imponen. La seguridad generalmente no es negociable (aunque muchas veces tiene matices), pero el rendimiento es un factor importante. Históricamente, nos gusta la seguridad, pero amamos la criptografía rápida.

Algunas cosas te atrapan, y eso fue lo que ocurrió con la criptografía de curvas elípticas. Parecía la herramienta perfecta, segura y eficiente, con operaciones rápidas y firmas pequeñas. Con el paso de los años, más protocolos se mudaron a esta familia de algoritmos criptográficos, hasta que terminó formando parte de todo. Las necesidades se resolvían fácilmente añadiendo otra firma, hasta que todo llegó a un freno abrupto gracias a los ordenadores cuánticos. (Si necesitas refrescar el tema, nuestra Guía de Criptografía Poscuántica es una lectura ligera y recomendable.)

La transición poscuántica de la criptografía, forzada por la amenaza de un ordenador cuántico relevante para criptografía (CRQC), nos recuerda que, en el mundo digital, no existe la seguridad inherente. Todo son juegos que jugamos. Jugamos con las matemáticas y encontramos propiedades interesantes, que luego juntamos de manera útil. Lo que llamamos seguridad es efímero, porque el estado del arte siempre avanza. Ya habrás escuchado que los ataques solo mejoran.

Nuestros ordenadores clásicos no pueden romper las matemáticas de RSA y ECDSA, pero, resulta que los ordenadores cuánticos sí. Para defendernos de ellos, jugamos más juegos, usando matemáticas distintas. Ideamos nuevos algoritmos. El único problema: las propiedades de estos nuevos algoritmos son diferentes. En este caso particular, el rendimiento sigue siendo equivalente, pero las claves y las firmas ocupan mucho más espacio.

En la siguiente tabla, comparamos los aspectos clave de ML-DSA con los de la criptografía tradicional. Mostramos los valores para los algoritmos y niveles de seguridad comunes que solemos ver en certificados hoja y en intermedios, estos últimos usando criptografía más fuerte. Nos centramos solo en ML-DSA porque es nuestra principal apuesta de momento. Si quieres saber cómo son otros algoritmos, visita el PQC Signature Zoo.

Como puedes ver, la variante de entrada de ML-DSA utiliza firmas 10 veces más grandes que RSA y 34 veces más grandes que ECDSA. Este aumento en el tamaño de la criptografía pública cambia las suposiciones que teníamos al construir capas superiores de criptografía, hasta el punto de que podría llevar a que las cosas dejen de funcionar como deberían.

Por cierto, si ves pequeñas diferencias en los tamaños de firma y clave pública que se afirman en diferentes artículos en Internet, probablemente sea porque algunos usan los tamaños puros de las primitivas y otros tienen en cuenta cómo se empaquetan los datos para su transporte, como hago yo aquí.

En esencia, un certificado X.509 es un vehículo de empaquetado y transporte para una clave pública, firmada con la clave de una autoridad. Cuando aparecieron los primeros certificados, solo teníamos claves RSA. Con los habituales 2.048 bits, una clave RSA ocupa 272 bytes y su firma 256. ECDSA, en cambio, consume 65 bytes para la clave pública (sin compresión) y 72 para la firma. Con la metainformación extra que hay que integrar en cada certificado, el tamaño típico de un certificado hoja puede rondar entre 1 y 2 KB.

Un único certificado no basta para acceder de forma segura a un servidor. En la práctica, dependemos de cadenas de certificados, que incluyen al menos 2 certificados transportados por red. (Una cadena completa podría estar formada por 3 certificados si incluimos la raíz, pero ese certificado final no debería transmitirse.)

Este intermedio adicional duplica los requisitos de tamaño. Los intermediarios y raíces suelen emplear criptografía más potente, lo que los hace aún más grandes.

Además, los protocolos requieren al menos una firma para autenticar el apretón de manos criptográfico en tiempo real. Para un apretón de manos TLS, hablamos de al menos 3 firmas y 2 claves públicas.

En los primeros días de SSL, las CPU eran lentas y la criptografía demasiado exigente. Las operaciones criptográficas eran el principal cuello de botella. (También teníamos páginas web mucho más ligeras que ahora). Hoy, el cuello de botella es algo de lo que quizá no hayas oído hablar: la ventana de congestión inicial de TCP.

Sin explayarnos, la ventana inicial de congestión es la cantidad máxima de datos que puedes enviar al principio de una conexión TCP sin tener que esperar otro viaje de red. Antes era mucho menor, pero ahora el límite moderno es de unos 14,5 KB. QUIC, el reemplazo moderno de TCP (e implementado sobre UDP), tiene un límite de solo unos 4.500 bytes, aunque por un motivo distinto (defensa anti-amplificación, diseñada para reducir los ataques DoS de amplificación que son fáciles de realizar vía UDP).

Traducido: si el servidor no puede meter todos sus certificados y la criptografía relacionada con el protocolo en esos 14,5 KB, tendrá que esperar a recibir la autorización del cliente en el momento más sensible de la conversación, el mismísimo inicio. En una red pequeña, esta pérdida de rendimiento puede sumar decenas de milisegundos. En redes móviles, pueden ser cientos.

Si tu protocolo usa UDP (como QUIC), los paquetes grandes pueden requerir fragmentación, que a menudo es descartada por los dispositivos intermedios. En redes con pérdidas significativas de paquetes, el rendimiento se ve aún más perjudicado.

Los certificados X.509 estándar que describimos antes ya casi no se usan. Tal vez en redes privadas, pero en la Web PKI hace falta una versión extendida de X.509 que añade información de Certificate Transparency (CT). El ecosistema CT proporciona garantías de seguridad ampliadas al asegurar que todos los certificados públicos se registren en logs públicos. La publicación es atestiguada, actualmente por al menos 2 operadores. Cada operador aporta una firma, que se integra en los certificados X.509 mediante la extensión Signed Certificate Timestamp (SCT).

Con CT añadido en la mezcla, ya vamos por 5 firmas y 2 claves públicas en un apretón de manos TLS típico.

Sin entrar en el detalle de los cálculos (quizá material para otra entrada del blog), aquí tienes los números aproximados que obtuve para cadenas típicas en uso hoy:

• Cadena de certificados ECDSA: 586 bytes
• Cadena de certificados RSA: 1.712 bytes
• Cadena de certificados ML-DSA: 14.724, 18.640 o 18.565 bytes

Los números para ML-DSA requieren explicación. Obtenemos el tamaño más pequeño (14.724) si usamos ML-DSA-44 para toda la cadena, pero esto va en contra de las mejores prácticas. El segundo valor (18.640) lo obtenemos si intermedios y raíces usan criptografía más fuerte, asumiendo que estas claves deben permanecer seguras por más tiempo. El tercer valor corresponde al uso con CNSA 2.0 (el paquete de algoritmos de seguridad nacional comercial de la NSA), que solo acepta ML-DSA-87.

Claramente, incluso en el mejor de los casos con una cadena ML-DSA, la criptografía pública por sí sola sobrepasa el límite inicial de congestión de 14 KB, y nadie se alegra de eso. Este aumento seguramente tendrá un impacto pequeño pero importante en nuestro día a día. Es posible que los dispositivos limitados (por ejemplo, IoT) no puedan implementar criptografía poscuántica en absoluto.

Este cálculo se centra en lo básico, pero hay muchas circunstancias en las que el apretón de manos TLS crecerá aún más. Por ejemplo:

• A veces es necesario agregar otro intermedio en la cadena de certificados, por ejemplo, al pasar de una jerarquía a otra y querer mantener compatibilidad con almacenes de raíces antiguos.
• La situación empeora si eliges autenticación híbrida, mezclando criptografía tradicional y poscuántica en el mismo certificado. Es posible que quieras hacerlo si no confías aún plenamente en estos nuevos algoritmos poscuánticos y prefieres ir "con cinturón y tirantes".
• También empeora algo si quieres soportar el chequeo de revocación mediante OCSP, aunque actualmente rara vez se usa en Internet pública.

Hemos visto que una transición ingenua a algoritmos poscuánticos implica prepararse para un posible impacto importante en el rendimiento. En mi próxima entrada de blog, analizaré las pruebas que podrían ayudarnos a fundamentar estos temores.