More about key reuse

[danvangeest]

So, I think I have a use case for key reuse for composite signatures. To allow the use of the native and alternative private and public keys of Catalyst (hssss) certificates to generate composite signatures. Composite private and public keys for the certificate wouldn't exist in the wild, but the native and alternative private keys of a certificate could be used to generate a composite signature.

Due to the flexibility of these certificates, this means that a signature could be generated corresponding to the native key, the alternative key, or a composite of the native+alternative key.

Some of you authors already know that I'm not generally in favour of Catalyst certificates, but there are those out there who still want to use them, so I'm coming at this from a harm-reduction perspective. And also from a forward-looking perspective, this draft is setting the standard for composite signatures. It would be easier if future composite signatures, for example PQ/PQ, could use the framework of this draft (and implementation) to define other composites (obviously with specific security considerations for the component algorithms involved). At that point, both component algorithms may take a context and key reuse could be done safely.

To that end, I wonder if it would be worth considering enabling key reuse of the component algorithms which take a context parameter by changing the context from:

ctx = Domain

to:

ctx = Domain || Hash(PublicKey1 || PublicKey2)

This would provide domain separation for a key, ML-DSA for example, to be used standalone or as part of multiple composite keys (even multiple composite keys with the same Domain, because the key hash achieves the separation). I don't claim it's a good idea to reuse a key in multiple composite keys with the same Domain, just that this idea would protect the key if that happened.

I'm interested in your opinions.

[danvangeest]

As Scott says elsewhere, 'belt and suspenders` but this is belt and suspenders and superglue.

[johngray-dev]

My first thought is what if the signer doesn't have access to the public key? My second thought is this works great to obtain what you want for ML-DSA or other component algorithms that take a context, but not at all for the ones that don't (which is RSA and most EC combinations except the Edwards ones). So at best in the context of the current draft it would give us separation for 1 of the components, but not the others, which would foil our security claim of EUF-CMA as long as one of them is EUF-CMA. My third thought is that we had thought about this property a few years ago (For instance, it would work with multiple independent certs as well), and there probably are lots of interesting use cases where keys could be joined to make a composite signature. After lots of discussions it seems this property wasn't desired in lieu of the security implications it brought to composite.

Perhaps for combinations where a context string is used in BOTH algorithms this could make sense... We had talked about using context strings for other components that could support it. See https://github.com/lamps-wg/draft-composite-sigs/issues/64 but it was mostly decided against because the most compatible way is to use no context String...

So in summary for cases where both components take contexts, I would say it is interesting. For cases where some components don't take a context String, i don't think we want to go there.

[danvangeest]

Here is someone trying to combine separate keys using the composite signature construct. Check out IPSECME on Monday to see/influence how that goes. https://datatracker.ietf.org/doc/draft-hu-ipsecme-pqt-hybrid-auth/

Regarding your second thought, yes it protects ML-DSA but not the trad key. My point is if someone is going to end up doing this anyways, better to protect only the ML-DSA key than neither key.