Using ML-KEM Post-Quantum Key Exchange in OpenSSH

OpenSSH 9.9, released on 2024-09-19, first introduced support for the new FIPS 203 Module-Lattice Key Encapsulation Mechanism (ML-KEM) post-quantum key exchange algorithm, previously known as Kyber. ML-KEM was formally standardized by NIST on 2024-08-13, and is designed to be secure against quantum attacks, making it a suitable choice for future-proofing cryptographic systems.

The OpenSSH implementation of supporting ML-KEM, specifically the mlkem768x25519-sha256 key exchange algorithm, is a hybrid approach that combines the post-quantum ML-KEM with the standard X25519 key exchange algorithm. The benefit of a hybrid approach is that in the event that, after further cryptanalysis, the ML-KEM algorithm ends up being broken, the X25519 key exchange algorithm will still provide a secure fallback. At least for now, while we don’t yet have a Cryptographically Relevant Quantum Computer (CRQC) that can break X25519. There is currently an IETF draft for Post-Quantum Traditional (PQ/T) hybrid key exchange methods based on ML-KEM and Elliptic Curve Diffie-Hellman (ECDH) algorithms (also including X25519) for use in SSH. OpenSSH’s mlkem768x25519-sha256 key exchange is exactly such an example thereof, and is being described there.

OpenSSH 10.0, released on 2025-04-09, is now using this new quantum-resistant key exchange algorithm by default. This further safe-guards against "store now, decrypt later" attacks, and I have since updated my personal OpenSSH configurations. Both mlkem768x25519-sha256 and curve25519-sha256 are now the only two key exchange algorithms I allow:

You can inspect if your OpenSSH client supports the mlkem768x25519-sha256 key exchange algorithm by running the following command:

When connecting using the -v option, you can see the key exchange algorithm being used:

Your own use cases may vary, so you might want to adjust the above settings according to your own needs. The mlkem768x25519-sha256 key exchange algorithm is not yet widely supported by all SSH clients and servers, which is why I have kept the curve25519-sha256 key exchange algorithm as well. My SSH client on Android does not yet support this new key exchange algorithm. I wish I could continue to use ConnectBot, but it doesn’t yet use chacha20-poly1305@openssh.com (not even aes256-gcm@openssh.com) to negotiate ciphers:

While ConnectBot still seems to be maintained, I don’t see any progress on this front.

JuiceSSH also does not support chacha20-poly1305@openssh.com for that matter (even though it does support aes256-gcm@openssh.com unlike ConnectBot):

And judging from JuiceSSH’s changelog, I don’t see this project as being actively maintained anymore since 2021. This is why I’ve (somewhat reluctantly) recently switched to Termius, which does support at least the chacha20-poly1305@openssh.com cipher (no mlkem768x25519-sha256 key exchange yet, though). Perhaps I will give Termux’s SSH client a try in the future, but seems more clunky in use than a dedicated SSH client app.

I’m also still considering using the sk-ssh-ed25519@openssh.com host key algorithm, which would allow me to use my YubiKey. Bernard Spil has written a good article on how to set that up.

Edit 20250820:

In an effort to speed-up adoption, OpenSSH 10.1 will also start throwing warnings when not using a quantum-resistant key exchange algorithm: https://www.openssh.com/pq.html