mlkem768x25519-sha256 is a hybrid SSH key exchange method. It combines the post-quantum ML-KEM-768 key encapsulation mechanism from FIPS 203 with classical X25519 elliptic-curve Diffie-Hellman and hashes the result with SHA-256. The session keys stay secret as long as at least one of the two components holds, including against a future quantum computer.
For operators of OT and critical infrastructure, SSH is how engineers reach jump hosts, historians, firewalls, switches and serial-to-IP gateways. This article covers what the method does, what the standard says, how to roll it out, and how to handle the devices that cannot take part.
What is mlkem768x25519-sha256 in SSH?
It is one of three post-quantum/traditional (PQ/T) hybrid key exchange methods published in RFC 10042. It runs inside the normal SSH transport handshake, so applications, user authentication and channels stay the same.
RFC 10042 defines Post-Quantum Traditional (PQ/T) Hybrid key exchange methods based on the quantum-resistant Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) standard and traditional Elliptic-Curve Diffie-Hellman (ECDH) key exchange schemes. The authors are Panos Kampanakis, Douglas Stebila and Torben Hansen, and it was published as an Informational RFC in August 2026.
How the two halves fit together
On the classical side, the public keys are defined as strings of 32 bytes as per RFC 8731, and the K_CL shared secret is generated from the exchanged public keys as defined in RFC 8731 (key agreement method curve25519-sha256). On the post-quantum side, the client’s public key and the server’s ciphertext represent ML-KEM-768 public key and ciphertext from the client and server, respectively, and the K_PQ shared secret is decapsulated from the ciphertext using the client post-quantum KEM private key as defined in FIPS 203. K_CL and K_PQ are used together to generate the shared secret K, which goes into the exchange hash defined in RFC 4253.
Validation is strict. The client must abort using a disconnect message (SSH_MSG_DISCONNECT) with a SSH_DISCONNECT_KEY_EXCHANGE_FAILED as the reason if the check fails or decapsulation fails. A malformed reply ends the session. It never quietly downgrades.
Which post-quantum key exchange methods does RFC 10042 define for SSH?
RFC 10042 defines three method names, each pairing an ML-KEM parameter set with a matching classical curve and hash. All three are listed in the IANA SSH Key Exchange Method Names registry.
| Method name | Post-quantum part | Classical part | Exchange hash | Typical fit |
|---|---|---|---|---|
| mlkem768x25519-sha256 | ML-KEM-768 | X25519 (RFC 8731) | SHA-256 | General default for admin access |
| mlkem768nistp256-sha256 | ML-KEM-768 | ECDH P-256 | SHA-256 | Environments restricted to NIST curves |
| mlkem1024nistp384-sha384 | ML-KEM-1024 | ECDH P-384 | SHA-384 | National security and CNSA 2.0 oriented systems |
In the IANA registry, all three carry “OK to Implement” set to SHOULD. A related method from the same working group, RFC 9941, specifies sntrup761x25519-sha512, which uses a different lattice KEM. RFC 10042 explains that its message abstraction and key derivation align with the ones defined in RFC 9941, which uses a different quantum-resistant KEM.
How do I enable hybrid ML-KEM key exchange for SSH access to OT jump hosts and network devices?
Put the hybrid method first in the key exchange preference list on both sides, starting with the jump hosts. Then check which algorithm each session actually negotiated, instead of assuming the setting took effect.
A sequence that works in segmented OT networks
- Inventory first. For each zone and conduit, list which SSH servers you reach (jump hosts, firewalls, managed switches, RTU gateways) and record the key exchange methods each one offers. Most clients can print their supported list and show the negotiated algorithm in verbose output.
- Harden the jump host first. Jump hosts are usually general-purpose servers that you can patch on a normal schedule. Set the server’s key exchange list (the KexAlgorithms setting in many implementations) to put mlkem768x25519-sha256 first. The leg from engineer laptop to jump host often crosses the IT/OT boundary or the internet, so it gains the most.
- Configure clients per destination. Use host-specific client configuration so that destinations known to support ML-KEM are hybrid-only, while legacy targets get an explicit, documented exception.
- Verify and log. Capture the negotiated kex algorithm in server logs. That gives you evidence for your crypto inventory and shows when a firmware update removes an exception.
- Test packet sizes on small devices. ML-KEM public keys and ciphertexts make the key exchange messages larger. RFC 10042 notes that an SSH implementation adhering to RFC 4253 must be able to support packets with an uncompressed payload length of 32768 bytes or less and a total packet size of 35000 bytes or less. Embedded SSH stacks that cut corners on buffers show up here, so test in a lab before production.
Does mlkem1024nistp384-sha384 meet CNSA 2.0 requirements for SSH?
For the transition period it is the closest fit in RFC 10042, because it is the only method that uses ML-KEM-1024 with SHA-384. CNSA 2.0 eventually expects pure ML-KEM-1024 with no classical component, though.
The CNSA 2.0 suite as described in the NSA-authored SSH profile draft states that ML-DSA-87 and ML-KEM-1024 together with SHA-384, SHA-512, AES-256, LMS, and XMSS comprise the CNSA Suite 2.0. mlkem1024nistp384-sha384 matches on the KEM and the hash. An earlier working group draft of RFC 10042 said this method is compliant with CNSA 2.0 requirements until 2033.
Statistic: CNSA 2.0 requires support for ML-KEM-1024 in 2025 and makes it mandatory without any classical algorithm in the key exchange in 2033 (IETF draft-ietf-sshm-mlkem-hybrid-kex-03, 2025).
The separate CNSA 2.0 SSH profile draft is stricter: ML-KEM-1024 MUST be used to establish a shared secret value between the client and the server. Any algorithm other than ML-KEM-1024 MUST NOT be negotiated for key exchange in a CNSA-compliant connection. That draft names a pure method, mlkem1024-sha384. The practical reading: hybrid P-384 is a transition step for organisations that follow CNSA 2.0. It is not the end state. Whether a specific implementation is acceptable for national security systems is decided by the relevant validation authority, not by algorithm choice alone.
What happens when an SSH client connects to a legacy OT device that has no ML-KEM support?
Under RFC 4253 negotiation, the client and server agree on the first key exchange method in the client’s list that the server also supports. If the client still lists a classical method, the session quietly falls back to it. If not, the connection fails.
Both outcomes cause trouble in OT. Silent fallback to curve25519-sha256 means that path has no post-quantum protection, and nothing tells the engineer. A hard failure during an incident or a maintenance window locks people out of equipment they need. Firmware cycles on PLC-adjacent gear and industrial switches can be long. Researchers studying harvest-now-decrypt-later risk point out that protocols that hard-code algorithms or require firmware updates (e.g., IoT, SCADA) cannot pivot within relevant timescales.
| Option | What it protects | Trade-off |
|---|---|---|
| Allow classical fallback per host, documented | Availability only | That path stays exposed to harvest now, decrypt later |
| Terminate on a jump host inside the zone | The long, exposed leg (user to jump host) gets hybrid ML-KEM | The final hop from jump host to device is still classical, so keep it short and inside the zone |
| Wrap the path in a network-layer post-quantum tunnel | All traffic between sites, including classical SSH | Protects data in transit between gateways, not the device itself |
| Firmware upgrade to an ML-KEM capable SSH stack | The full SSH session end to end | Depends on vendor roadmaps and change windows |
The tunnel option is how Quantum Network’s Quantum Gateway works. A hardware or software gateway at each end of a site-to-site, edge-to-cloud or remote-access connection encrypts at Layer 3 using a hybrid key agreement with ML-KEM (FIPS 203). The equipment behind it needs no software, so an old device’s classical SSH session runs inside a post-quantum protected path. The device itself is not protected, and the SSH session still needs its own host key checks.
Are recorded SSH sessions to industrial systems at risk from harvest now, decrypt later?
Yes, if the key exchange was purely classical and the content needs to stay confidential for years. Authentication cannot be forged after the fact, but recorded encrypted traffic can be stored and decrypted once ECDH can be broken.
SSH sessions into OT often carry information with a long shelf life: network device configurations, firewall rule sets, controller logic uploads, plant topology and credentials typed at prompts. A substation or water-treatment layout does not lose value after a few months. Hybrid key exchange closes this gap because a recorded session can only be decrypted if both ML-KEM-768 and X25519 are broken.
Statistic: Under NIST IR 8547, quantum-vulnerable algorithms at 112-bit security strength are deprecated after 2030, disallowed after 2035 (NIST IR 8547 initial public draft, November 2024).
Statistic: One forecast cited by the OECD suggests there is less than a 5% chance that RSA-2048 encryption will be broken before 2039 (OECD quantum technologies policy primer, 2024). A low probability is not the same as low risk when a captured session has to stay confidential for twenty years.
US policy treats the timeline as a reason to act now. National Security Memorandum 10, quoted in NIST IR 8547, states that the United States must prioritize the timely and equitable transition of cryptographic systems to quantum-resistant cryptography. NIST’s own guidance is direct: organizations should begin migrating their systems to quantum-resistant cryptography.
Prioritising which SSH paths to fix first
Rank paths by two factors: how exposed the network segment is (internet, carrier links, cloud interconnects) and how long the data needs to stay confidential. Remote vendor access over the internet into a jump host usually comes first. Next are site-to-site management paths between control centres and substations. Short, in-zone hops on isolated segments come last. Fix the exposed legs with mlkem768x25519-sha256, or mlkem1024nistp384-sha384 where you follow CNSA 2.0. Then keep a dated list of legacy exceptions, each with a compensating control.
Where Quantum Network fits
Quantum Network is a quantum-safe encryption gateway that protects the connections between your own locations, without replacing the network equipment you already run.