openssh unix dev - Jul 2025 - [EXT] Re: Plans for post-quantum-secure signature algorithms for host and public key authentication?

?While SLH-DSA may be more secure than ML-DSA, performance and signature size
would make it prohibitive for dynamic authentication for many use cases.

As to how much security you need ? for the vast majority of users ML-DSA is
plenty secure ?enough?. To the point that US and German governments (probably,
among others ? I didn?t bother to check) decided to bet their security on it.
-- 
V/R, 

Uri 

From: openssh-unix-dev <openssh-unix-dev-bounces+uri=ll.mit.edu at
mindrot.org> on behalf of Simon Josefsson via openssh-unix-dev
<openssh-unix-dev at mindrot.org>
Date: Friday, July 11, 2025 at 18:16
To: Aaron Rainbolt <arraybolt3 at gmail.com>
Cc: openssh-unix-dev at mindrot.org <openssh-unix-dev at mindrot.org>
Subject: [EXT] Re: Plans for post-quantum-secure signature algorithms for host
and public key authentication?

Aaron Rainbolt <arraybolt3 at gmail.com> writes:
> If this was to be "resurrected" to some degree, it would be neat
if
> this could be combined with a more traditional Ed25519 signature
> verification, similar to the hybrid PQ kex algorithms currently
> available. Depending on how exactly SLH-DSA works (which I have not
> studied), that might be way over-paranoid, but my workplace likes way
> over-paranoid :P
>
> If there's something I could do to meaningfully contribute to this sort
> of thing, feel free to let me know.
SLH-DSA/SPHINCS+ is based on traditional old-school hashes (e.g., SHA2),
and I think many cryptographers are even more comfortable with that
compared to RSA/ECDSA/EDDSA. Could you read up on SLH-DSA and
re-evaluate?

I like belt and suspenders approaches, but one shouldn't be blind to
specifics. I would not use ML-DSA unless it was in a hybrid, and I
generally prefer hybrid constructs for everything PQ, but for SLH-DSA I
am personally ready to make an exception. The risk for signatures is
smaller than KEX's, where the attack surface becomes passively
decrypting all prior communication, whereas for signatures it requires
an online active SLH-DSA attack to be useful. For long-term SSHSIG used
to authenticate software releases (via git signing) this argument
doesn't apply though.

Still, maybe this is a losing fight, and that it is actually simpler to
promote Ed25519 + SLH-DSA in a hybrid because the optics of it is
simpler to take in for everyone who are migrating from a Ed25519 world.
Having more discussion and opinions on this would be nice.

/Simon 





-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7920 bytes
Desc: not available
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20250711/d5079546/attachment-0001.bin>

On Fri, 11 Jul 2025 22:31:18 +0000
"Blumenthal, Uri - 0553 - MITLL" <uri at ll.mit.edu> wrote:
> ?While SLH-DSA may be more secure than ML-DSA, performance and
> signature size would make it prohibitive for dynamic authentication
> for many use cases. 
> 
> As to how much security you need ? for the vast majority of users
> ML-DSA is plenty secure ?enough?. To the point that US and German
> governments (probably, among others ? I didn?t bother to check)
> decided to bet their security on it. 
There is a pretty significant community of users and developers
(oftentimes people involved with projects like Kicksecure, Whonix, and
Qubes OS, all of which I either contribute to or am paid to work on)
where "secure enough for the government" is not secure enough. Many of
those people work in situations where paranoid-level security mesures
are warranted, and for those people I feel having SLH-DSA would be
reasonable. Performance isn't a high priority in a lot of these
situations.

--
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/9da333c9/attachment-0001.asc>