Cifrado post-cuántico de OpenSSH
(openssh.com)- OpenSSH admite algoritmos criptográficos post-cuánticos para defenderse de ataques de computadoras cuánticas
- A partir de la versión 9.0, aplica de forma predeterminada el algoritmo sntrup761x25519-sha512, y desde la 10.0 adopta mlkem768x25519-sha256 como mecanismo de conexión por defecto
- A partir de la versión 10.1, cuando se usa un intercambio de claves que no sea post-cuántico, aparece un mensaje de advertencia
- También se espera que en el futuro se agregue soporte para la mayoría de los algoritmos de firma existentes (RSA, ECDSA, etc.)
- Para proteger con seguridad el tráfico existente, es necesario aplicar algoritmos post-cuánticos tanto en el servidor como en el cliente
Adopción de OpenSSH y el cifrado post-cuántico
OpenSSH admite múltiples algoritmos de intercambio de claves seguros frente a ataques de computadoras cuánticas
Recomienda usar esos algoritmos en todas las conexiones SSH
Desde OpenSSH 9.0 (2022), sntrup761x25519-sha512 ofrecía por defecto algoritmos de intercambio de claves post-cuánticos (KexAlgorithms), y desde OpenSSH 9.9 se agregó mlkem768x25519-sha256
mlkem768x25519-sha256 quedó configurado como el método de cifrado predeterminado desde OpenSSH 10.0
Para impulsar la adopción de algoritmos post-cuánticos, OpenSSH 10.1 muestra la siguiente advertencia cuando no se usa un intercambio de claves resistente a la computación cuántica:
** WARNING: connection is not using a post-quantum kex exchange algorithm. **
This session may be vulnerable to "store now, decrypt later" attacks.
The server may need to be upgraded. See https://openssh.com/pq.html
Esta advertencia se muestra de forma predeterminada, pero puede desactivarse con la opción WarnWeakCrypto de ssh_config(5)
Contexto
Una computadora cuántica es un dispositivo que calcula codificando información en estados cuánticos
Puede resolver rápidamente ciertos problemas matemáticos que con una computadora tradicional son imposibles
Muchos algoritmos criptográficos se basan en problemas matemáticos que pueden resolverse fácilmente con una computadora cuántica
Si aparece una computadora cuántica suficientemente poderosa (desde un punto de vista criptográficamente relevante), existe riesgo de que estos esquemas de cifrado se rompan
Especialmente, los algoritmos usados para intercambio de claves y firmas digitales son los más afectados
Aún no se han materializado tales computadoras cuánticas, pero especialistas pronostican que aparecerán en 5 a 20 años o a mediados de la década de 2030
La garantía de privacidad de una conexión SSH depende del cifrado del intercambio de claves
Si un atacante rompe el algoritmo de intercambio de claves, podría descifrar todo el contenido de la sesión
Además, incluso sin ser en tiempo real, podría realizarse un ataque de "store now, decrypt later" guardando una sesión cifrada y descifrándola más tarde cuando exista una computadora cuántica
OpenSSH está reforzando el soporte de cifrado post-cuántico para contrarrestar este tipo de ataques
FAQ
Q: OpenSSH muestra una advertencia en ssh, ¿qué debo hacer?
- OpenSSH 10.1 y versiones posteriores muestran una advertencia al usuario si se usa cifrado con autenticación no segura para computación cuántica
- En este caso, significa que el servidor conectado no ofrece algoritmos de intercambio de claves post-cuánticas (mlkem768x25519-sha256, sntrup761x25519-sha512)
- La opción recomendada es actualizar el servidor a OpenSSH 9.0 o superior (9.9 o superior para lo último) y verificar que KexAlgorithms no tenga desactivados esos algoritmos
- Si no es posible actualizar el servidor o si aceptas el riesgo, también es posible ocultar solo la advertencia con la opción WarnWeakCrypto en ssh_config(5)
- Si es necesario, aplica este ajuste solo para hosts específicos de la siguiente manera:
Match host unsafe.example.com WarnWeakCrypto no
Q: ¿Por qué prepararse si todavía no hay computadoras cuánticas?
- Es por el ataque mencionado como "store now, decrypt later"
- El tráfico enviado hoy podría descifrarse más tarde, por lo que se recomienda una conexión segura post-cuántica desde ahora
Q: También dijeron que los algoritmos de firma son riesgosos, ¿por qué no es un problema ahora?
- La mayoría de los algoritmos de firma actuales (RSA, ECDSA, etc.) también pueden neutralizarse con una computadora cuántica
- Sin embargo, en este caso no hay escenarios donde el tráfico existente se guarde para descifrado posterior
- En lo urgente respecto a las firmas, se trata de retirar las claves de firma antiguas cuando la llegada de computadoras cuánticas esté más cerca
- OpenSSH planea agregar soporte de algoritmos de firma post-cuántica en el futuro
Q: Creo que las computadoras cuánticas no serán posibles, ¿por qué es importante?
- Algunos piensan que las computadoras cuánticas no se lograrán, pero las barreras técnicas actuales son un problema de ingeniería, no de física fundamental
- Si las computadoras cuánticas son posibles, las medidas de hoy acabarán protegiendo una enorme cantidad de datos de usuarios
- Incluso si al final resultara una preparación innecesaria, no es más que una migración a cifrado matemáticamente más fuerte
Q: ¿No podrían también ser vulnerables los algoritmos post-cuánticos?
- OpenSSH también está abordando esto con cautela
- Ha seleccionado únicamente algoritmos que han sido evaluados en profundidad durante los últimos años, pero sigue existiendo la posibilidad de que se descubran nuevos métodos de ataque
- Para cubrir eso, se eligieron algoritmos con holgura de seguridad suficiente, lo que aumenta la probabilidad de mantener seguridad operativa incluso si resultan más débiles de lo esperado
- Además, los algoritmos post-cuánticos de OpenSSH son completamente de tipo híbrido
- Por ejemplo: mlkem768x25519-sha256 combina ML-KEM (post-cuántico) y el algoritmo ECDH/x25519 (clásico) existente
- De este modo, incluso si el algoritmo post-cuántico se vuelve ineficaz en el futuro, se conservaría al menos el mismo nivel de seguridad que antes
1 comentarios
Opinión de Hacker News
En la parte inferior de la página hay contenido importante oculto. Todos los algoritmos postcuánticos aplicados en OpenSSH son de tipo "híbrido": usan al mismo tiempo un intercambio de llaves postcuántico (por ejemplo, ML-KEM) y uno tradicional (x25519). Al usar ambos algoritmos juntos, si en el futuro el algoritmo postcuántico se rompe por completo, al menos se conserva el mismo nivel de seguridad que antes. Lo importante es que, con lo híbrido, no hay pérdida de seguridad respecto al estado actual.
La industria en general se está moviendo hacia una arquitectura híbrida PQC-clásica. Hasta que aparezca una computadora cuántica capaz de romper de verdad RSA, ECC y DH, lo más seguro por ahora parece el enfoque conservador de poner dos cerraduras en paralelo. Por otro lado, el algoritmo CNSA 2.0 de la NSA (enlace) indica en su FAQ oficial que adopta solo algoritmos postcuánticos y que el modo híbrido no es estrictamente necesario.
Con el paper reciente, sesgado y divertido (enlace), me genera la duda de si realmente hace falta adoptar crypto postcuántica tan pronto. Según tengo entendido, los parámetros de clave postcuánticos son muchísimo más grandes, así que aumentan bastante el tráfico de red y el consumo de CPU.
Este texto trata solo de aplicar PQC al intercambio de claves en conexiones SSH, así que el overhead ahí es bastante mínimo. Y, como también dice la FAQ, la pregunta de "¿por qué prepararnos antes si aún no existe la computadora cuántica?" se responde por el riesgo de que el tráfico enviado hoy pueda ser descifrado más tarde (ataque store now, decrypt later). Hay quien sostiene que las computadoras cuánticas son imposibles, pero el principal obstáculo no son las leyes físicas sino la ingeniería. Si una computadora cuántica realmente se materializa, sería posible recuperar una enorme cantidad de datos de usuarios. El paper vale la pena leerlo por interés, pero no hay que tomarlo con cinismo extremo.
Ese paper da para reír, pero no para burlarse solamente. De hecho, también hay avances sustanciales. Recomiendo la charla de Sam Jacques en PQCrypto 2025 (enlace). En los últimos 10 años, el costo de factorización basada en computación cuántica bajó 1000 veces y la tasa de error de hardware se redujo muchísimo (enlace1, enlace2, enlace3, enlace4). Si quieres observar el avance de la computación cuántica, basta con seguir la mejora gradual de su robustez. El ruido es el gran obstáculo, y cuando se solucionen los problemas de calidad en ambos frentes, se espera un avance real.
Ese paper parece una broma. Si fuera una crítica seria, sería como quejarse en 1951 de que un transistor no puede calcular pi. La necesidad de adoptar PQC depende de estas dos preguntas: 1) si crees que nunca verás una computadora cuántica en tu vida; 2) qué tan valioso consideras proteger los datos que confías. Si ambas te importan poco, PQC puede ser una pérdida de tiempo. Pero si estás a cargo de un sistema criptográfico, creo que no tienes derecho a ignorar el valor de los datos de los usuarios.
La discusión actual va, en gran parte, sobre el intercambio de claves. Este intercambio ocurre con baja frecuencia y el overhead suele no ser problemático. En resumen: 1) Los algoritmos PQ (firma, intercambio de claves) tienen claves mucho más grandes, pero el rendimiento de cómputo es igual o incluso más rápido. 2) En la mayoría de protocolos como TLS o SSH, el intercambio de claves se hace solo en el handshake inicial, por lo que ese tamaño grande de clave no es gran problema. Puede haber temas de compatibilidad como superar el MTU de TCP. En protocolos que renegocian clave muy seguido, como Signal o MLS, se usa PQ sólo de manera ocasional para rekey (referencia). 3) En TLS, el problema mayor es el tamaño de los mensajes de firma, porque la cadena de certificados tiene muchas firmas. Por eso, la viabilidad de introducir firmas PQ en TLS tiene más peso (referencia).
Además de lo público, un factor de confianza es que nuestras agencias recomienden PQ para sistemas que requieren mantener confidencialidad por más de 20 años. Para compartir: en 2014, la agencia holandesa de inteligencia mencionó 2030~2040; en 2021 dijo que para 2030 la probabilidad era baja pero no descartable. En 2025, 18 países emitieron una declaración conjunta recomendando prepararse contra ataques store now, decrypt later hasta 2030 (documento1, documento2, comunicado conjunto).
La app Secretive de macOS guarda la clave SSH en Secure Enclave. Por el algoritmo soportado, está usando ecdsa-sha2-nistp256, y parece que Secure Enclave probablemente no soporta algoritmos PQ. Me pregunto si sería posible emparejarlo en modo híbrido, tipo mlkem768×ecdsa-sha2-nistp256, y delegar solo la parte ECDSA al SE (Secretive GitHub).
Pienso que la herramienta ssh-audit (enlace) debería agregar una entrada para comprobar algoritmos teóricos (PQC híbrido). Parece que incluso usando algoritmos fijos, igual sale calificación "A". Hoy en día solo estoy usando cha-cha.
Me pregunto si existe un algoritmo híbrido PQC para OpenSSH que cumpla con FIPS 140-3.
El enfoque de prepararse con antelación es razonable. Lo considero más válido cuando cambiar llaves es una tarea relativamente menor. Entre dos opciones, no sé cuál es más fuerte; quizá la 512 no será la más fuerte.
Los dos algoritmos son completamente distintos. mlkem768x25519-sha256 mezcla un intercambio de claves ML-KEM postcuántico con ECDH/x25519 tradicional. Así, si uno de los dos se rompe, se conserva el nivel de seguridad previo. Además, la versión 256 (mlkem768) salió después de la versión 512 (sntrup761). OpenSSH soportó sntrup761x25519-sha512 desde la 9.0 y mlkem768x25519-sha256 desde la 9.9.
El tema de 256 vs 512 no hay que preocuparse de eso ahora. No existe hoy una máquina capaz de barrer completamente un espacio de 128 bits, ni la energía para hacerlo. No es el momento de preocuparse.
mlkem es el default razonable en este momento. La industria se está alineando hacia ahí.
Estoy considerando convertir mi app de microblogging/chat por terminal a postcuántica. Tras ver varias veces la entrevista a Paul Durov y escuchar lo que le pasó, la duda crece.
Me pregunto cuál conviene más entre sntrup761x25519-sha512 y mlkem768x25519-sha256.
MLKEM768 ofrece mejor rendimiento y claves más pequeñas. SNTRUP761 tiene una base de seguridad más fuerte y mejor resistencia a posibles ataques criptográficos.
NTRU Prime (sntrup) entró por razones históricas (en ese momento no existía mlkem). Se puede usar cualquiera, pero sntrup se siente como un valor por defecto de una época, parecido a cuando GPG usaba CAST por defecto.
Me pregunto cuándo se ofrecerán certificados PQ también para autenticación de host/usuario.
Adelantarse con este tipo de iniciativas es algo bueno. Incluso si en el futuro aparece una alternativa con mejor seguridad, no creo que este esfuerzo sea inútil si no empeora respecto de la situación actual.