[Ssh] Re: PQ signatures - where do we want to end up?

[Stephen Farrell <[e-mail]>]

Hi Simon,

On 12/05/2026 19:31, Simon Josefsson wrote:
> Stephen Farrell <[e-mail]> writes:
> 
>> Hiya,
>>
>> Thanks all for the discussion.
>>
>> What we think we see from that, ignoring parameter variations
>> for the moment, is that we have multiple participants who
>> would like to see us end up specifying:
>>
>> 1) ML-DSA + eddsa - quite a few
>> 2) pure ML-DSA - quite a few
>> 3) ML-DSA + ecdsa - mentioned in passing
>> 4) SLH-DSA - some interest
> 
> 5) SLH-DSA + eddsa
> 6) FN-DSA + eddsa

I don't recall mention of 5 or 6 in the thread before. And wouldn't
including those imply yet more combinations? (Personally, I'm not
keen on even the number of variants I'm sure we'll end up with, so
even less keen to see yet more added. But as chairs, we'll try help
enable what the WG want of course, whenever that's clear.)

How about we consider the list 1-4 as the current list to discuss
where there seems to be broad interest? (Making that list shorter
would be great too though, IMO.) Adding to the list could then be
something to chat about later. Would that make sense?

> I believe the PQ story for SSH isn't complete without a conservative
> fall-back KEM like Classic McEliece and some political KEM like
> FrodoKEM.  Historically the SSH community has made use of fall-backs
> available in implementations when crypto attacks are published.  It
> doesn't seem impossible that we'll need that in the future too.

I'd prefer we keep this thread to signatures if that's ok.

> Otherwise your summary seems good.  I do worry that by phrasing
> decisions the WG should make in particular ways, we shape the answer in
> a potentially less optimal way.

I don't understand what you mean, sorry.

> For example, I think it would be unwise to demand that all hybrid
> documents necessarily must use the same hybrid signature combiner.  It
> would be easy to arrive at that conclusion by asking such a question
> specifically before further separate work on each algorithm combination.
> The LAMPS hybrid approach is far along the pipeline, but it has also
> attracted critique.  It doesn't seem unreasonable to use the LAMPS
> hybrid for ML-DSA + EdDSA but chose some stronger hybrid for SLH-DSA +
> EdDSA or even ML-DSA + ECDSA.

Our summary wasn't meant to imply anything about combiners. And I'd
agree that there's no need for all combiners to be the same. (Nor is
there a need for them to differ.)
  > I also think we should acknowledge that SSH signatures are relevant for
> both interactive use and offline long-term use.  The algorithm and/or
> parameter choices may be different for those two use-cases.

Fair point. I guess I'm assuming that's of secondary importance for
the WG, but certainly of some interest. (Though we're not really
chartered to consider such things.)

Cheers,
S.


> 
> /Simon
> 
>>
>> We also see a desire to avoid lots of variations in parameter
>> sets somehow, but also sense it might be hard to "only pick
>> 1" for any of 1-4.  That suggests we'd like to end up with
>> some way of favouring/recommending a small number of
>> parameters for each of 1-4, whilst also perhaps specifying
>> how other parameter sets could be used. We're not clear if the
>> WG would prefer to prefer one of 1-4 over the others, but we
>> could work on that question later.
>>
>> There was also discussion of private key formats and domain
>> separation that we guess will continue but perhaps is better
>> handled once we're clear about the overall direction.
>>
>> Is that a fair summary? If so, Job and I can use that to
>> look at the set of drafts people have proposed and see
>> whether we should do some calls for adoption etc. If not,
>> please do correct us if we've gotten the sense of the
>> discussion wrong.
>>
>> Cheers,
>> Stephen&Job
>>
>> _______________________________________________
>> Ssh mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>