using Rebex.Net;
// News, tips & tricks from Rebex developers

How to use ML-DSA with Rebex SSH libraries

  |   Lukas Pokorny
Components HOWTO

ML-DSA (Module-Lattice-Based Digital Signature Algorithm) is a post-quantum cryptographic signature algorithm standardized in NIST FIPS 204 that is currently being integrated into the SSH protocol. ML-DSA is designed to replace traditional digital signature algorithms like RSA and ECDSA for identity verification. And along with ML-KEM, it protects SSH communication against future decryption threats from cryptographically relevant quantum computers.

However, as of summer 2026, while SSH key exchange ciphers based on ML-KEM are already widely implemented and deployed, the exact details of ML-DSA support in SSH are still work in progress. Lately, there has been an increasingly heated debate about whether to use ML-DSA in stand-alone (pure) mode, or whether to go for composite (hybrid) mode instead. In hybrid mode, ML-DSA is used together with a well-known and battle-tested classic algorithm such RSA, ECDSA or Ed25519. This ensures that when a vulnerability is discovered in the post-quantum algorithm or its implementation, the SSH session at least remains protected by the classical algorithm. Others argue this would be overly-complicated, and would not provide any extra security in the longer term, when ML-DSA implementations mature or cryptographically relevant quantum computers actually arrive.

As for Rebex libraries, in order to make it possible to perform some real-world testing, we added experimental support for stand-alone SSH ML-DSA algorithm to version 8.0 of our SSH-enabled libraries. We choose to add support pure mode ML-DSA ciphers first because these have already been available during development of version 8, and they do seem likely to stay, even if hybrid variants initially become a preferred choice.

Of course, we plan to add hybrid variants as well, as soon as it becomes clear which of the composites actually gain traction. Expect more updates soon!

For now, if you decide to enable experimental ML-DSA support in Rebex SSH libraries and give it a try, make sure you are aware of the controversies surrounding pure mode ML-DSA and understand the implications.

Currently, two competing (but almost compatible) draft specifications of pure SSH ML-DSA exist:

  • sfluhrer-ssh-mldsa, defines ssh-mldsa-44, ssh-mldsa-65, and ssh-mldsa-87 public key and signature formats.
  • rpe-ssh-mldsa defines mldsa-44, mldsa-65, and mldsa-87 instead.
  • Confusingly, an earlier version of sfluhrer-ssh-mldsa defined cipher IDs as ssh-mldsaNN instead, while an earlier version of rpe-ssh-mldsa used ssh-mldsa-NN form (which is currently used by sfluhrer-ssh-mldsa).

Because it is still not clear whether and when any of these are going to become official, Rebex libraries currently support all these forms. You just have to explicitly enable the variant you intend to use. Our test server at test.rebex.net supports all of them, but in practice, we really recommend choosing just a single one.

For example, to try ssh-mldsa-44 host key algorithm with Rebex SFTP (which runs over SSH), get Rebex.Sftp NuGet package and use the following code:

var sftp = new Rebex.Net.Sftp();
sftp.LogWriter = new ConsoleLogWriter(LogLevel.Debug);

// only allow 'ML-DSA-44' group of host key algorithms
sftp.Settings.SshParameters.HostKeyAlgorithms = SshHostKeyAlgorithm.MLDsa44;

// explicitly enable 'mldsa-44' host key algorithm only
sftp.Settings.SshParameters.SetHostKeyAlgorithms("ssh-mldsa-44");

// connect to an SSH server
sftp.Connect("test.rebex.net", 22);

// check server key fingerprint
if (sftp.Fingerprint.ToString() != "D5wjygbqhOAQ8O1chM7Vo1geEuQHuLT9WOgZO0z5cYE")
{
    throw new Exception("Warning: Unexpected server key.");
}

// authenticate and list remote root directory
sftp.Login("demo", "password");
Console.WriteLine(string.Join("\n", sftp.GetRawList("/")));
...

Rebex libraries have been tested with these third-party implementations of pure SSH ML-DSA:

  • PKIX-SSH secure shell, a fork of OpenSSH that adds X.509 v3 certificate support and other features; implements mldsa-NN algorithms
  • OQS-OpenSSH, a fork of OpenSSH that adds PQC algorithm support using liboqs for prototyping and evaluation purposes; implements ssh-mldsaNN algorithms

Last month, developers taking part in the IETF 126 Hackathon produced new sfluhrer-ssh-mldsa implementations:

We have not tested these new forks yet, but we should be compatible with their ssh-mldsa-44, ssh-mldsa-65 and ssh-mldsa-87. If you encounter any issues, let us know!

For more information about the 8.0 release and its enhancements, see release highlights.