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

[Filippo Valsorda <[e-mail]>]

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

 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.

 3. It's not 2020, ML-DSA has been analyzed for almost a decade, it's a
    delightfully simple and robust algorithm to implement, we have good
    test vectors for it in Wycheproof that survived mutation testing against
    multiple implementations, and remarkably there has not been a single
    security issue in a ML-DSA implementation in the nearly two years since
    it was specified (that I know of).

 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/

    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.

    Take golang.org/x/crypto/ssh for example: if we put a composite
    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.

If we do absolutely need to implement composites:

 1. We will categorically implement at most one combination, ever.

    At least this way we can implement "the SSH hybrid" instead of having
    to build a framework to combine different key types and parameters.

 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. (Which by the way these days can be
    implemented with equivalent or better safety than Ed25519 by following
    draft-irtf-cfrg-det-sigs-with-noise-05.)

 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.

Putting all that together, if we really must have a composite, the only one
that would make sense to us is ML-DSA-44 + ECDSA P-256.

But please, don't block pure ML-DSA availability on the composites debate.

2026-04-28 01:38 GMT+02:00 Damien Miller <[e-mail]>:
> On Mon, 27 Apr 2026, Watson Ladd wrote:
> 
> > > FWIW I have a test implementation of hybrid ML-DSA 65 / Ed25519 for
> > > OpenSSH using the draft-ietf-lamps-pq-composite-sigs construction
> > > and was planning on writing it up as an I-D is anyone is interested.
> > >
> > > https://github.com/djmdjm/openssh-portable-wip/pull/11
> > 
> > I don't want to drag us down the composite rabbit hole but short PQ
> > timelines and the nature of authentication make me less interested.
> 
> Basing this on an document that is in the RFC editor queue as opposed
> to one of the other myriad constructions was an attempt to step over
> the rabbit hole as much as possible.
> 
> IMO, the increased urgency for deployment of PQ sig algs (I have seen
> requests for by-default deployment in 2028) *heightens* the
> desirability of a hybrid construction. I was more comfortable with
> pure ML-DSA when it was a 2030s thing on the basis that we'd have
> more time for algorithmic and implementation scrutiny.
> 
> -d
>