Hi Emil,

Am 24.10.25 um 14:50 schrieb Emil Lundberg:

    Security-wise, I would like to point out that it is necessary that
    with the introduction of the split signing algorithms no ambiguity
    is created as to whether a specific signature algorithm is applied
    to the message directly or the message digest. If that was the
    case, then an attacker could potentially exchange the directly
    signed message with a hash of the message without invalidating the
    signature.


The entire point of this is to /keep/ that ambiguity, though, and intentionally /not/ invalidate the signature: we want to generate, for example, ESP256 signatures that can be successfully verified by an existing ESP256 verifier that is not (and indeed should not be) aware of ESP256-split. As you mentioned in your first paragraph:

    [...] Otherwise such a separation seems to be an implementation
    detail that typically has no relevance for interoperability.

The quote you give here doesn't imply an ambiguity with respect to what is exactly signed. The separation is only an implementation detail if it doesn't change the mechanism (e.g., signing directly or signing a hash) of signing. Just to make sure this aspect doesn't t get lost: If this draft (or another) should in any way introduce an ambiguity with respect to what exactly is being signed, then this will result in formal violation of the EUF-CMA security notion, which means allowing signature forgeries. Whether or not or to which degree this can be exploited might require further analysis.

I generally recommend to use cryptographic algorithms in COSE only through their external interfaces and according to their specifications in the form of RFCs or other standards. In case cryptographic algorithms are being "opened up", in the sense of accessing their internals, or their inputs redefined or reinterpreted, I suggest to let the design undergo a detailed review from one or multiple experts in cryptographic engineering. My existing review doesn't live up to that as I lack knowledge of the application context and, as I become aware after your response, apparently don't understand the design and its exact goals.

Best regards,
Falko
--

*MTG AG*
Dr. Falko Strenzke

Phone: +49 6151 8000 24
E-Mail: [email protected]
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>

Attachment: smime.p7s
Description: Kryptografische S/MIME-Signatur

_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to