openssh unix dev - Jul 2025 - Plans for post-quantum-secure signature algorithms for host and public key authentication?

On Sat, 12 Jul 2025 06:09:34 +1000 (AEST)
Damien Miller <djm at mindrot.org> wrote:
> On Fri, 11 Jul 2025, Aaron Rainbolt wrote:
> 
> > I'm currently writing some documentation for a work project, and
> > part of my job has involved doing a (somewhat over my head) deep
> > dive into the security properties of various cryptography-related
> > algorithms in OpenSSH and which ones are likely to be superior to
> > others in various scenarios. In the process of doing this, I noted
> > that it seems OpenSSH supports post-quantum-secure algorithms for
> > symmetric encryption, key exchange, and message authentication
> > codes, but notably lacks a post-quantum-secure signature algorithm
> > for host key and public key authentication. As I understand it
> > (keep in mind I am not a cryptographer by any means), this means
> > that an attacker with a sufficiently powerful quantum computer
> > could, in the future, MITM SSH connections or spoof trusted client
> > devices.
> > 
> > Are there any plans to integrate a post-quantum-secure signature
> > algorithm in OpenSSH, such as SLH-DSA (SPHINCS+)?  
> 
> We have experimental XMSS support in OpenSSH, but it's not really
> usable and will probably be removed when we get a more modern PQ
> signature scheme.
> 
> There are no concrete plans to add support for a PQ signature scheme
> but I think that it's fairly likely we'll add support for hybrid
> ML-DSA/ed25519 per
> https://datatracker.ietf.org/doc/draft-sun-ssh-composite-sigs/01/
Nice. If some input is allowable, I would like to see SLH-DSA
specifically though since as I understand it, ML-DSA is related to
ML-KEM (Kyber), and there are concerns that Kyber's security properties
may have been intentionally misrepresented by NIST. [1] [2] Currently
in the documentation I'm working on, I've recommended the use of
sntrup761x25519-sha512 over mlkem768x25519-sha256 after skimming
through the mentioned articles. SLH-DSA I believe also has
better-understood security properties, so it may be more reliable.
Obviously having an ML-DSA mode won't hurt, but given the choice, I'd
prefer to use SLH-DSA.
> > (Unrelated, the "About openssh-unix-dev" page [1] claims
that the
> > list is open for non-subscribers, but my first attempt at sending
> > this was rejected with "Posting by non-members to
> > openssh-unix-dev at mindrot.org is currently disabled, sorry." It
> > might be useful to correct the page so people know to subscribe
> > first.)  
> 
> Sorry, fixed.
Thanks :)

[1] https://blog.cr.yp.to/20231003-countcorrectly.html
[2] https://blog.cr.yp.to/20231125-kyber.html

--
Aaron
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20250711/a4f5c57a/attachment-0001.asc>

On Fri, 11 Jul 2025, Aaron Rainbolt wrote:
> On Sat, 12 Jul 2025 06:09:34 +1000 (AEST)
> Damien Miller <djm at mindrot.org> wrote:
> 
> > There are no concrete plans to add support for a PQ signature scheme
> > but I think that it's fairly likely we'll add support for
hybrid
> > ML-DSA/ed25519 per
> > https://datatracker.ietf.org/doc/draft-sun-ssh-composite-sigs/01/
> 
> Nice. If some input is allowable, I would like to see SLH-DSA
> specifically though since as I understand it, ML-DSA is related to
> ML-KEM (Kyber), and there are concerns that Kyber's security properties
> may have been intentionally misrepresented by NIST. [1] [2]
AIUI those claims are 1) disputed (e.g. [1]), 2) are at the margins
even for ML-KEM512, 3) don't really apply to ML-KEM768, which is what
most people (inc. us) are using and 4) it's not clear the extent to
which they apply to ML-DSA.

If we adopt a ML-DSA variant then we'd pick one with a similar
security margin (i.e. probably ML-DSA-65).
> Currently
> in the documentation I'm working on, I've recommended the use of
> sntrup761x25519-sha512 over mlkem768x25519-sha256 after skimming
> through the mentioned articles.
FWIW ML-KEM is quite a bit faster and targets a higher security level
(NIST category 3) [2] to sntrup761's NIST category 2 [3].

Also, in OpenSSH at least, ML-KEM has a formally-verified
implementation (from libcrux).
> SLH-DSA I believe also has
> better-understood security properties, so it may be more reliable.
I haven't studied any of the PQ hash algorithms enough so in my
ignorance I'll generally defer to the cryptographers that will still
speak to me. Most of them are focusing their adoption efforts on
ML-DSA for general purpose protocols like SSH.

Anyway, we're not in a rush to adopt a PQ signature scheme -
there's no analogous store-now-decrypt-later situation like there is
for key agreement and the only places that SSH signatures could
plausibly last into the era of cryptographically-relevant quantum
computing are sshsig and CA signatures of certificates, and these
both have pretty tractable remediation paths.

-d

[1] https://keymaterial.net/2023/11/18/kyber512s-security-level/
[2] https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.203.pdf section 3.2
[3] https://ntruprime.cr.yp.to/nist/ntruprime-20201007.pdf section 3.5