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

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+)?

(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.)

[1] https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

--
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/c6704789/attachment.asc>

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/
> (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.

-d

Aaron Rainbolt <arraybolt3 at gmail.com> writes:
> Are there any plans to integrate a post-quantum-secure signature
> algorithm in OpenSSH, such as SLH-DSA (SPHINCS+)?
I don't know, but I made initial experiments with it:

https://blog.josefsson.org/2024/12/23/openssh-and-git-on-a-post-quantum-sphincs/

There is a specification for it:

https://datatracker.ietf.org/doc/html/draft-josefsson-ssh-sphincs-00

Niels M?ller implemented SLH-DSA recently and did some performance
statistics:

https://lists.lysator.liu.se/mailman/hyperkitty/list/nettle-bugs at
lists.lysator.liu.se/message/FQU6J4OGIKCE46SXOYG4HFZ67MVOGDIL/

After that I am inclined to add more algorithm options: it seems fast
verification (thus the "slow" variant) may be more relevant to
software
signing code paths, and the 128-bit variants may be relevant for online
interactive use.  I'm still mixed about the cost to add both SHAKE and
SHA2, I picked SHA2 because it is faster.

If there is interest, I'm happy to make another iteration of these
patches.

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