[Ssh] Re: Supporting pure ML-DSA as hostkey and authkey

[Damien Miller <[e-mail]>]

On Wed, 29 Apr 2026, Filippo Valsorda wrote:

> >From the point of view of Go, we'd strongly prefer to implement pure ML-DSA,
> specifically because of the increased urgency.
> 
>  1. If the CRQC are coming sooner than expected, the hypothetical value of
>     the ECC component is obviously shorter-lived.

Currently we have a notion that CQRCs might arrive sooner. This has
caused many people to be given actual mandates to move to PQC on a
compressed timeline.

The CQRC may or may not happen sooner than expected but the mandates
will force transition faster than the original timeline regardless.

The argument for doing pure signatures whe we did not have the
confidence to do pure KEMs was that we'd get more time with them before
we had to migrate. This seems to no longer be the case.

>  2. Picking and specifying a composite will take longer, as proven by the
>     failure of every other ecosystem to pick and deploy a composite so far.

Well, as I said previously, we have ietf-lamps-pq-composite-sigs, which
seems to have "won" the construction fight. We need only pick the
algorithms to plug into it.

>  4. Composites, unlike hybrid ephemeral key exchange, add complexity across
>     the stack, as I have argued on the TLS WG mailing list:
> 
>     https://mailarchive.ietf.org/arch/msg/tls/oh3jmmkHzHdp1hk4R4M9QjkmvBk/

You make two points there, 1) that they leak across the whole stack and
2) that they make the already complex X.509 authentication even more
complex.

#2 does not apply to SSH and I don't think #1 universally does either.
Please take a look at my test implementation of ML-DSA65/Ed25519. There
is zero leakage of the compositeness of the key beyond the single file
that implements the composite primitive.

>     I know some folks hold on to the idea that composites will be "just
>     another key type" but that's wishful at best, especially in the context
>     of SSH, which is not tightly integrated with the cryptography library.
>
>     public/private key type in that package, we'll not be able to return it
>     from ParsePKCS8PrivateKey in crypto/x509, because the latter is in the
>     standard library. That's just an example of how composites leak through
>     API layers.

I don't follow here. ietf-lamps-pq-composite-sigs defines a PKCS8
encoding. It can absolutely be just another key type there.

> If we do absolutely need to implement composites:
> 
>  1. We will categorically implement at most one combination, ever.

That's my preference too.

>  2. The ECC side should at least be useful for hardware binding.
> 
>     There is one benefit to hybrids, and it's using hardware keys that
>     provide protections like limited PIN retries and per-signature user
>     intent (i.e. touching the YubiKey). We don't have yet widely available
>     ML-DSA hardware, so it might make sense for tools like
>     https://github.com/FiloSottile/yubikey-agent to do software / hardware
>     hybrids (which by the way breaks the "composites are just an opaque
>     key type" illusion).
> 
>     That means using ECDSA P-256.

This seems directly contradictory with your opening point - if
you're arguing against hybrid constructions on the basis that
their classical component will be broken soon, then there is no
reason to demand their use when implemented in hardware.

I'll also observe that there are many hardware devices that support
Ed25519. It's specified for both FIDO and PKCS#11 and indeed OpenSSH
supports it for both of them.

>  3. The only PQ parameters that make sense to us are ML-DSA-44 and -87.
> 
>     If we are making a risk- and security-based analysis, ML-DSA-44 is
>     perfectly fine. Unlike ML-KEM-512, which was... hotly debated, leading
>     to the selection of ML-KEM-768 for hybrids, ML-DSA-44 is Category 2,
>     so it already has a healthy margin for small improvements in lattice
>     cryptanalysis. There is no reason to think large improvements would
>     leave any parameter set standing.
> 
>     If we are making a bigger-is-better or compliance-based analysis, then
>     the obvious answer is ML-DSA-87, which is the only one allowed by
>     CNSA 2.0, and is... bigger! (Both the bigger-is-better and compliance
>     arguments are weaker when selecting a hybrid, because the hybrid is
>     already supposed to provide additional margin, and because CNSA 2.0
>     actually has a preference against hybrids, so ML-DSA-87 makes more
>     sense as a pure parameter set.)
> 
>     I see no logical argument for selecting ML-DSA-65.

I'm happy to take feedback on which ML-DSA variant to adopt in a
composite construction. In particular, ML-DSA 44 for the composite and
ML-DSA 87 for pure is a future I could envisage.

-d