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

[Filippo Valsorda <[e-mail]>]

2026-04-29 18:16 GMT+02:00 Damien Miller <[e-mail]>:
> 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.

But we did get more time. We did hybrid KEMs for years, and we have had the
ML-DSA spec for two years now to develop the implementations and opinions.

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

"only" =)

> >  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 totally believe you that in OpenSSH the complexity cost is limited.
OpenSSH is not the whole ecosystem, and most other SSH implementations are
not so integrated with their cryptography layer.

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

Right, it has to be a key type *in the Go standard library* which is not
golang.org/x/crypto/ssh, so it leaked. (Concretely, where do I put the
SSHCompositePublicKey and SSHCompositePrivateKey types? And then do I allow
instantiating a SSHCompositePrivateKey from the components? If not, what do
I tell folks with hardware ECC and not hardware SSH composite? Note that
hardware SSH composite will take a much longer time than hardware ML-DSA.)

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

We live in a world of tradeoffs. None of these arguments are absolutely
right or wrong. I said that if you assume a CRQC will come soon*er* then
the advantages of hybrids are *smaller*.

Then I said that "[i]f we do absolutely need to implement composites" we
should capture the IMHO biggest part of the upside, which is not defending
against ML-DSA being broken, but bridging the gap to ML-DSA 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.

I don't have a YubiKey that can do Ed25519 over PIV, and I have a lot of
YubiKeys. Ed25519 is indeed specified and supported in software, but that
doesn't mean it's supported in hardware.

I can offer more data points about this, but is there a strong reason to
conversely prefer Ed25519?

Again thinking about non-OpenSSH implementations: do they all support
Ed25519? Because if not they will have to implement two new things to
adopt the composite, and Ed25519 is IMHO trickier than ML-DSA.

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

Again I would prefer ML-DSA-44 and ML-DSA-87, but I could live with
ML-DSA-44 + ECDSA P-256 and ML-DSA-87, and the complexity cost would be
offset by a year or two of hardware token availability.