Re: [openpgp] PQC signature algorithm selection

[Daniel Huigens <[e-mail]>]

On Friday, February 23rd, 2024 at 09:32, Werner Koch wrote:
> A modified PGP 2 implementation once used algorithm
> ids 2 and 3 to add key usage restrictions to RSA. This was also the
> wrong way and OpenPGP sorted this out.

Having a single algorithm ID for RSA signing and encryption has caused
some issues in practice, for example, some uncareful implementations
have used RSA signing keys to encrypt, which forces us to now carry a
`allowInsecureDecryptionWithSigningKeys` config option in OpenPGP.js,
for compatibility reasons. And, signing and encrypting with RSA really
is a different operation, and should not have been intermixed, IMO.

Of course you might argue the difference between ML-DSA-65 and -87 is
not as big as between RSA signing and encryption, however, I hope
you'll agree that Ed25519 is a different algorithm than ECDSA, and so
Ml-DSA-65 + Ed25519 should also have a different algorithm ID than
ML-DSA-65 + ECDSA-NIST-P-256, for example.

Beyond that, having fully-specified algorithm IDs (i.e. with all the
parameters included in the algorithm ID) also simplifies the
implementation, and since there's not really a risk of running out of
available IDs, I would prefer to keep the current separation.


That being said, I personally also (like Simon) think the current draft
specifies a few too many combinations, and I would support splitting
some of them (e.g. the combinations with NIST and Brainpool curves) off
into separate documents. So I would tend to keep:

- ML-DSA-65 + Ed25519: MUST
- ML-DSA-87 + Ed448: SHOULD
- SLH-DSA-SHA2 or -SHAKE (no strong preference, but I'd keep at most
  one of them): MAY

And even for SLH-DSA, I would tend to pick one or two of the parameter
sets and specify them in the algorithm ID, rather than having 2 * 6
parameter sets. Also because if we have ML-DSA-65 and -87 as an option
as well, perhaps we don't need the full range of security & performance
possibilities / trade-offs of SLH-DSA?


On Friday, February 23rd, 2024 at 12:26, Simon Josefsson wrote:
> 2) Mandate two different PQ algorithms to get PQ-interop which reduce
>    the risks that the protocol is designed around one particular PQ
>    algorithms that does not generalize to others.

It seems like SLH-DSA isn't really feasible to use for all applications
(in particular email), and so I wouldn't like to mandate it. Also -
since the protocol already exists, if there's something that needs to
change to adapt to SLH-DSA, we'll have to do that separately anyway,
and writing a MUST here won't really be enough by itself to make that
happen, I think.

> 4) Don't reduce security along the way.  This argues for strong
>    conservatively designed combiners of PQ and non-PQ algorithms, and
>    always avoid using PQ-algorithms in non-hybrid modes.

I agree in general, but AFAIU, SLH-DSA is battle-tested enough by now
that it can be used by itself, without a fallback on EdDSA or ECDSA.
That being said, it probably doesn't add much to the size or time
required percentage-wise, so I wouldn't strongly object either.

Best,
Daniel