Summary

  • RFC 10042 defines three ML-KEM/ECDH hybrid methods for SSH transport and combines two ephemeral shared secrets into the input for SSH key derivation.
  • A hybrid KEX can authenticate a key-exchange transcript under SSH’s established machinery, but the client still needs an independent basis to accept the server host key; user authentication, permission and action remain later, separate questions.

The phrase “quantum-safe SSH login” compresses too much work into one slogan. RFC 10042 is narrower and more useful than that. It defines Post-Quantum/Traditional hybrid key exchange methods for the SSH transport layer: the client and server execute a classical ECDH-style exchange alongside ML-KEM, then use both results to derive one SSH shared secret. The security aim is specific. If one of the component exchanges remains secure under the document’s assumptions, the hybrid exchange is intended to retain that protection against recorded traffic being decrypted later.

The packet shape reveals the boundary. Instead of the ordinary key-exchange initial message, the client sends SSH_MSG_KEX_HYBRID_INIT carrying C_INIT. That string joins a post-quantum ML-KEM public key and a classical public key. The reply carries the server public host key K_S, S_REPLY—an ML-KEM ciphertext joined to the server’s classical public key—and a signature over the exchange hash. RFC 10042 names the two resulting secrets K_PQ and K_CL, then derives K by hashing their prescribed fixed-length byte encodings.

This is not a decorative extra field. The server must check the length of the incoming composite before encapsulating; the client must check the returned composite before decapsulating. A wrong length or a decapsulation failure requires a key-exchange-failed disconnect. Each side must generate fresh ephemeral ECDH and ML-KEM keypairs for each connection, and the specification forbids reuse of ML-KEM ciphertext randomness. Fixed-length encodings also avoid a variable-length-secret path that could expose a timing signal. These are concrete controls over one key-establishment event.

They do not eliminate the host-trust decision. SSH’s architecture already distinguishes transport-layer server authentication from user authentication. The host-key signature binds the exchange hash to the server’s public host key, but the client must still decide whether that key is really the key for the host it meant to reach. RFC 4251 describes local host-name-to-key databases and certificate-based alternatives; RFC 4253 describes the client verifying K_S against a certificate or local database, while allowing an unchecked acceptance that remains vulnerable to active attacks. RFC 10042 reuses that surrounding SSH arrangement. It does not supply a new provenance system for K_S, choose the client’s trust roots, or convert an offered key into an organisational identity.

Method naming has the same limit. RFC 10042 registers mlkem768nistp256-sha256, mlkem1024nistp384-sha384, and mlkem768x25519-sha256. An inventory can truthfully record that an implementation knows a method name or that a client offered one in SSH_MSG_KEXINIT. Neither observation proves that the peer offered a compatible choice, that the selected exchange completed, that the host key was accepted under local policy, or that the resulting channel reached a user-authentication request. The SSH parameter registry separates key-exchange-specific message numbers from SSH_MSG_USERAUTH_* numbers for a reason: these stages answer different questions.

The exchange hash is valuable precisely because it is bounded. It incorporates the two identification strings, both KEXINIT payloads, K_S, the client and server hybrid messages, and the derived K. It binds the key-establishment transcript into the existing SSH derivation process. It does not contain a local administrator’s rule for a user, a command request, an account mapping or a consequence. RFC 4251 says the server’s local policy decides which authentication methods it will accept for each user, and must enforce the requested access. A hybrid KEX cannot perform that later decision simply because it precedes it.

There is a practical observability lesson here. A security team may retain a configuration declaring a hybrid method, an offer/selection log, an exchange-failure counter, a host-key verification record, a user-authentication result and a channel-action record. Those are not interchangeable. The method configuration shows readiness; a captured and verified transcript can show a particular key-establishment event; host-key evidence supports a trust judgment; user-authentication and authorisation records describe later local decisions. Combining them in a report is useful only if each keeps its own evidentiary role.