Avance de las funciones poscuánticas de SSH en Red Hat Enterprise Linux

La transición a la criptografía poscuántica (PQC) está muy avanzada en Red Hat Enterprise Linux (RHEL). En mayo de 2025, RHEL 10 incorporó algoritmos de intercambio de claves poscuánticas en tres bibliotecas criptográficas importantes (OpenSSL, GnuTLS y NSS), lo que permite utilizar el intercambio de claves poscuánticas en las conexiones TLS 1.3. A continuación, RHEL 10.1 estableció los nuevos algoritmos de intercambio de claves como predeterminados en TLS e introdujo firmas poscuánticas para paquetes RPM.

El protocolo Secure Shell (SSH) no se quedó atrás. RHEL 10 se lanzó con OpenSSH 9.9, que admite dos métodos híbridos de intercambio de claves poscuánticas: sntrup761x25519-sha512 combina el intercambio de claves clásico X25519 con el algoritmo principal de NTRU simplificado basado en red (SNTRUP), y mlkem768x25519-sha256 combina X25519 con el mecanismo de encapsulación de claves basado en entramado de módulos (ML-KEM) estandarizado por el National Institute of Standards and Technology (NIST) de EE. UU. A partir de RHEL 10.1, OpenSSH prefiere esta última opción al establecer conexiones, a menos que se configure de otro modo.

Novedades de SSH en RHEL 10.2

RHEL 10.2 integró otras funciones de PQC de SSH.

Intercambio de claves SSH poscuánticas en modo FIPS

El grupo de trabajo de mantenimiento de Secure Shell (SSHM) del Internet Engineering Task Force (IETF) está finalizando el borrador de RFC para mlkem768x25519-sha256, y diversos desarrollos de SSH están adoptando cada vez más el algoritmo. Sin embargo, el borrador también especifica otros dos algoritmos híbridos de intercambio de claves: mlkem768nistp256-sha256 y mlkem1024nistp384-sha384. Estos combinan las variantes de ML-KEM con el intercambio de claves Diffie-Hellman de curva elíptica (ECDH) sobre las curvas recomendadas por el NIST (P-256 y P-384) en lugar de Curve25519.

Dado que ML-KEM y ECDH sobre P-256/P-384 cuentan con la aprobación de FIPS, ofrecemos mlkem768nistp256-sha256 y mlkem1024nistp384-sha384 como los dos únicos algoritmos de intercambio de claves SSH compatibles con FIPS poscuánticas en Red Hat Enterprise Linux 10.2. Aunque los responsables del mantenimiento del upstream de OpenSSH decidieron no implementar estos dos híbridos adicionales, los clientes de Red Hat pueden empezar a utilizar la criptografía poscuántica en SSH en modo FIPS gracias a los parches del downstream de OpenSSH que proporcionan los desarrolladores de Red Hat.

Compatibilidad con el intercambio de claves poscuánticas en libssh

Estas construcciones de intercambio de claves híbridas también llegan finalmente a libssh 0.12.0 (la biblioteca C de SSH). En consonancia con el comportamiento de OpenSSH, los clientes y los servidores de SSH creados con libssh ahora prefieren el algoritmo de intercambio de claves mlkem768x25519-sha256 de forma predeterminada en RHEL 10.2. Esto significa que los clientes que ejecutan servidores personalizados basados en libssh pueden protegerse de los ataques de «recolección ahora, descifrado después» con solo actualizar la versión.

El futuro de SSH

Aún se están estandarizando más funciones de PQC, y Red Hat participa en este proceso.

Intercambio de claves de ML-KEM puro y claves SSH poscuánticas

Seguimos de cerca los esfuerzos actuales para estandarizar el uso del intercambio de claves ML-KEM puro (no híbrido) en SSH. El grupo de trabajo SSHM del IETF aún no ha adoptado el borrador actual, ya que no hay consenso sobre si es adecuado (los detractores argumentan que ML-KEM no es lo suficientemente maduro).

También se debate el uso de ML-DSA (una familia de algoritmos de firma poscuántica estandarizados por el NIST) en SSH, con varios borradores de RFC en competencia: draft-rpe-ssh-mldsa y draft-sfluhrer-ssh-mldsa buscan estandarizar el uso de ML-DSA puro para las claves públicas SSH, mientras que draft-sun-ssh-composite-sigs y draft-josefsson-ssh-ed25519mldsa65 buscan estandarizar las firmas ML-DSA compuestas (combinadas, por ejemplo, con las firmas EdDSA clásicas). La implementación de cualquiera de estas opciones permitiría que los hosts y los clientes de SSH se autentiquen con claves públicas poscuánticas, lo que los protegería de los ataques de intermediarios que utilizan computadoras cuánticas.

Intercambio de claves de GSSAPI con criptografía poscuántica

Por último, trabajamos para estandarizar el intercambio de claves de GSSAPI con métodos de PQC híbridos (concretamente los tres métodos híbridos de ML-KEM) e implementarlo en OpenSSH y libssh. El borrador de RFC propuesto por Red Hat se basa en RFC 4462 y RFC 8732, y su adopción hará que la autenticación Kerberos en SSH sea segura frente a la computación cuántica.

Conclusión

Con el lanzamiento de RHEL 10.2, el intercambio de claves SSH poscuántico está habilitado de forma predeterminada, ya sea que operes en modo FIPS o utilices aplicaciones SSH personalizadas basadas en libssh.  Te invitamos a actualizar tus sistemas a la versión más reciente de RHEL 10 para ayudar a mitigar las amenazas de tipo "recolectar ahora, descifrar después".

De cara al futuro, los ingenieros de Red Hat participan activamente en el IETF y en las comunidades upstream para ayudar a definir la siguiente fase de SSH con seguridad cuántica, lo que incluye el soporte de claves de host poscuánticas y la autenticación GSSAPI (Kerberos) poscuántica. A medida que los nuevos estándares de SSH maduren y alcancen un consenso, continuaremos implementándolos y ofreciendo soporte en las versiones futuras de RHEL.