Resumen

  • RFC 10042 define tres nombres de intercambio híbrido para la capa de transporte SSH y combina un secreto ML-KEM con otro ECDH.
  • Una oferta o registro de método describe una posibilidad; la selección, el intercambio, la confianza de host y el acceso del usuario requieren evidencias distintas.

Una lista de algoritmos es una promesa de compatibilidad potencial, no el diario de una conexión. RFC 10042 añade a SSH los nombres mlkem768nistp256-sha256, mlkem1024nistp384-sha384 y mlkem768x25519-sha256. Cada uno une ML-KEM con una variante clásica: P-256, P-384 o X25519. El registro IANA confirma que esos identificadores existen y el cliente puede anunciarlos dentro de SSH_MSG_KEXINIT. Ninguno de esos dos hechos revela por sí mismo qué par eligió el servidor en una conexión concreta.

La especificación define qué tendría que suceder después. El cliente envía SSH_MSG_KEX_HYBRID_INIT con C_INIT, una concatenación de la clave pública poscuántica y la clave pública clásica. El servidor devuelve SSH_MSG_KEX_HYBRID_REPLY, la clave pública de host K_S, y S_REPLY, que combina el texto cifrado ML-KEM con la clave pública clásica del servidor, además de una firma sobre el hash de intercambio. De esa secuencia salen K_PQ y K_CL; RFC 10042 fija su codificación y calcula K mediante un hash de ambos.

La diferencia entre “ofrecido” y “completado” es operativa. Antes de encapsular, el servidor debe comprobar que la longitud de C_INIT es la esperada para el método negociado. Antes de desencapsular, el cliente debe comprobar lo mismo para S_REPLY. Si una comprobación falla, o la desencapsulación falla, el cliente debe desconectar con un motivo de fallo de intercambio. Por tanto, un contador de ofertas, una política que habilita un nombre o incluso una traza parcial no sustituyen a la evidencia de que los controles llegaron a buen término.

Tampoco basta con inferir confianza de host a partir de K_S. La firma del host liga el transcript del intercambio a la clave presentada, y SSH utiliza esa firma para autenticar el transporte. Pero RFC 4251 deja claro que el cliente necesita conocimiento previo de la clave pública del servidor: puede proceder de una base local que asocia nombre y clave o de una autoridad certificadora aceptada. RFC 4253 describe que el cliente verifica K_S contra un certificado o una base local; aceptar sin verificar conserva exposición a ataques activos. RFC 10042 no cambia esa política de confianza ni decide qué asociación de nombre y clave es aceptable.

El hash de intercambio tampoco es un recibo de autorización. Incluye las cadenas de identificación, las dos cargas KEXINIT, K_S, C_INIT, S_REPLY y K. Esa composición permite ligar los elementos de establecimiento de claves y alimentar la derivación SSH. No contiene una solicitud SSH_MSG_USERAUTH_REQUEST, un resultado SSH_MSG_USERAUTH_SUCCESS, una regla de cuenta ni una solicitud de canal. La arquitectura SSH coloca la autenticación de usuario sobre el transporte y deja a la política local del servidor decidir qué métodos y accesos acepta.

La nueva construcción impone además pares efímeros ECDH y ML-KEM por conexión y prohíbe reutilizar la aleatoriedad de los textos cifrados ML-KEM. Sus codificaciones de longitud fija evitan que una longitud variable del secreto se convierta en una señal lateral. Son pruebas de rigor en el diseño del intercambio; no son pruebas de que una implementación concreta las aplicó, ni de que el resultado de una sesión habilitó una operación posterior.