[lamps] Re: [EXTERNAL] Re: Re: WG Last Call: draft-ietf-lamps-pq-composite-sigs-08 (Ends 2025-10-06)

["Scott Fluhrer (sfluhrer)" <[e-mail]>]

Mike is right.  The relevant question is "can you fool an innocent third party", that is, "can you create a message and signature pair that will be accepted by a pure ML-DSA verifier which is implemented as specified in draft-ietf-lamps-dilithium-certificates", given access to composite signatures (with the same ML-DSA private key).

Because you cannot (because of the mismatch in the context strings), you have nonseparability, at least in that aspect.  In fact, we have nonseparability against any use that doesn't use the precise context string which happens to be the label for the composite parameter set.

Of course, we don't have comparable separability in the RSA side; I don't believe that is possible while treating the RSA implementation as a black box.

________________________________
From: Mike Ounsworth <[e-mail]>
Sent: Wednesday, October 1, 2025 2:27 PM
To: Peter C <[e-mail]>
Cc: Scott Fluhrer (sfluhrer) <[e-mail]>; Mike Ounsworth <[e-mail]>; Falko Strenzke <[e-mail]>; Russ Housley <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [EXTERNAL] Re: [lamps] Re: WG Last Call: draft-ietf-lamps-pq-composite-sigs-08 (Ends 2025-10-06)

Peter,

One additional point though.

You said:

> The discussion in composite-sigs-08 was framed in terms of an attacker with access to the underlying signing oracles and in that case the context string is just another input to ML-KEM.Sign.

I'm not sure I agree though. It's actually not ML-KEM.Sign that's important, it's actually ML-KEM.Verify that matters. And if the attacker controls ML-KEM.Verify, then you're in a Game Over scenario anyway.

Scott's point is that because we use an ML-DSA ctx within the composite, but (at least within X.509 and CMS) require ctx to be empty in pure ML-DSA, it is not possible to create a (M, \sigma) pair that is simultaneously valid in both contexts.

I am a bit nervous about hacking at Security Considerations during WGLC like this, so I want to slow down and give this some more careful thought before making more text changes.

On Wed, 1 Oct 2025 at 13:22, Mike Ounsworth <[e-mail]<mailto:[e-mail]>> wrote:
Hi Peter,

> I’m in favour of reframing the security considerations so that it is clearer which properties of the composite construction hold generally, which only hold when it is used within X.509 or CMS, and which only hold with additional mitigations.

Yes. This is the main point. I agree that I was sloppy with this in the changes that I made in -09 I will do another pass over the security considerations.

On Wed, 1 Oct 2025 at 12:17, Peter C <[e-mail]<mailto:[e-mail]>> wrote:

While this might be true for the use of composite ML-DSA and standalone ML-DSA as specified by LAMPS, it is not true in general.  The discussion in composite-sigs-08 was framed in terms of an attacker with access to the underlying signing oracles and in that case the context string is just another input to ML-KEM.Sign.



I’m in favour of reframing the security considerations so that it is clearer which properties of the composite construction hold generally, which only hold when it is used within X.509 or CMS, and which only hold with additional mitigations.



Peter





From: Scott Fluhrer (sfluhrer) <sfluhrer=[e-mail]<mailto:[e-mail]>>
Sent: 01 October 2025 15:54
To: Mike Ounsworth <[e-mail]<mailto:[e-mail]>>; Falko Strenzke <[e-mail]<mailto:[e-mail]>>; Mike Ounsworth <[e-mail]<mailto:[e-mail]>>; Peter C <[e-mail]<mailto:[e-mail]>>
Cc: Russ Housley <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [EXTERNAL] Re: [lamps] Re: WG Last Call: draft-ietf-lamps-pq-composite-sigs-08 (Ends 2025-10-06)



That is correct; for composite ML-DSA, we use a nonempty context string, and for pure ML-DSA, the context string is empty.



Hence, a stripping attack against a composite ML-DSA signature cannot be used to create a valid pure ML-DSA signature for any message (assuming no break on SHAKE, of course).



A stripping attack can be used to take a composite signature, and so we don't get full nonseparability.  However, we do get some.



________________________________

From: Falko Strenzke
Sent: Monday, September 29, 2025 9:51 AM
To: Mike Ounsworth; Peter C
Cc: Russ Housley; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: [EXTERNAL] Re: [lamps] Re: WG Last Call: draft-ietf-lamps-pq-composite-sigs-08 (Ends 2025-10-06)



Am 27.09.25 um 16:46 schrieb Mike Ounsworth:

The first case (attacker constructing a composite signature from individual components) is indistinguishable from the situation where a legitimate signer stores the component private keys in separate cryptographic modules (as mentioned in section 4.1).  Weak non-separability only allows a verifier to detect the second case (attacker splitting a composite signature into its individual components).

I am not sure what the current discussion is about exactly, but just this remark: constructing a valid composite signature and message from two component signatures must fail for the proposed combiner, since for the ML-DSA component signature the context parameter is non-empty whereas for the standalone ML-DSA as defined by the current LAMPS draft it is always empty. I didn't check both drafts right now, but previously this was true and I am not aware that the handling of the context parameter was changed in either draft recently.

Falko

--

MTG AG
Dr. Falko Strenzke

Phone:

[phone]

E-Mail:

[e-mail]<mailto:[e-mail]>

Web:

mtg.de<https://www.mtg.de/>

________________________________

MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany
Commercial register: HRB 8901
Register Court: Amtsgericht Darmstadt
Management Board: Jürgen Ruf (CEO), Tamer Kemeröz
Chairman of the Supervisory Board: Dr. Thomas Milde

This email may contain confidential and/or privileged information. If you are not the correct recipient or have received this email in error,
please inform the sender immediately and delete this email.Unauthorised copying or distribution of this email is not permitted.

Data protection information: Privacy policy<https://www.mtg.de/en/privacy-policy>

Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.