Should we have a nonempty ML-DSA context string?

[sfluhrer]

ML-DSA has a 'context string' as an input; the idea is to allow the capability to bind a signature to a specific context.

Should we specify that, when we implement ML-DSA within a composite signature, that we have a nonempty context?

If the verifier will never accept a signature signed by a specific ML-DSA key except as part of a composite signature, we don't gain anything. However, it might be a helpful 'belt-and-suspenders' if some application would happen to reuse the ML-DSA public key.

If we do have a nonempty context string, what should it be:

• Should it be the OID for the composite (so that the signature can be used only as a part of that specific combination)
• Should it be the hash of the composite public key (so that we're safe even if some fool changes the other components)

Thoughts?

[ounsworth]

Discussion between John, Felipe, and myself. Decision is to change one sentence is the draft:

OLD:

2. Generate the 2 component signatures independently, by calculating the signature over M'
      according to their algorithm specifications that might involve the use of the hash-n-sign paradigm.

         S1 := Sign( K1, A1, M' )
         S2 := Sign( K2, A2, M' )

NEW:

2. Generate the 2 component signatures independently, by calculating the signature over M'
      according to their algorithm specifications that might involve the use of the hash-n-sign paradigm.

         S1 := ML-DSA.Sign( K1, A1, M', ctx="" )
         S2 := TradSign( K2, A2, M' )

Since Composite ML-DSA incorporates the domain separator into a pre-hash, which serves theh same purpose as the ML-DSA context string, the ML-DSA context string is left empty.

[falko-strenzke]

If we do have a nonempty context string, what should it be:

* Should it be the OID for the composite (so that the signature can be used only as a part of that specific combination)

* Should it be the hash of the composite public key (so that we're safe even if some fool changes the other components)

I am in favor of using the context parameter to enhance the security of the protocol. This means we should fix the signature algorithm (as Scott suggests above), thus also preventing signature stripping attacks that leave the signature of a component algorithms that has the context parameter. I am also in favor of using the context parameter to signal whether a CMS signature was generated with or without SignedAttributes. Currently, the ambiguity with respect to the presence of the SignedAttributes leads to a trivial signature forgery (https://eprint.iacr.org/2023/1801.pdf – sorry if it seems that I am promoting my work here; that is not the case; I wrote this only to have a reference for something that is probably known to some but everyone). This will improve the security of CMS in course of the PQC transition.

Clearly this measure should not only be restricted to composite signatures, but should be specified for all CMS signatures.

I also suggest to use approach with for EdDSA in the new composites, and possibly even to add new versions of standalone EdDSA which make use of this feature.

[falko-strenzke]

Since Composite ML-DSA incorporates the domain separator into a pre-hash, which serves theh same purpose as the ML-DSA context string, the ML-DSA context string is left empty.

I don't agree to that: The way the domain separator is specified, it doesn't prevent signature stripping attacks, but it transforms a signature stripping attack for the message M to one for the message M'. This clearly implies an existential signature forgery, a fundamental weakening of the protocol. If using the context parameter (additionally or as a replacement for the current combiner) we achieve a profound⁺ means of preventing signature stripping attacks at least for those signature schemes that do offer a context parameter – namely EdDSA and all the new PQC schemes.

⁺ profound in the sense of not introducing existential signature forgeries

[janklaussner]

We discussed this in https://github.com/lamps-wg/draft-composite-sigs/issues/42#issuecomment-2374284632 We will pass the context down to ML-DSA.

[janklaussner]

Duplicate of #42

[johngray-dev]

We ended up adding both Pure and Hash versions with the context string, so this will also resolve #45

resolves #45

[johngray-dev]

We decided to use the context String, and this was Merged in Pull #59