[openpgp] Re: PQC composite sig context string? [was: Re: Re: AD review of draft-ietf-openpgp-pqc-12]

Sorry - somehow managed to send an incomplete draft. Re-sending it
Hi Falko,
Setting the key reuse aside, that I think is problematic per se, and may always lead to subtle vulnerabilities, OpenPGP uses a hash-then-sign paradigm, so what is fed to the signing algorithm is a hash that contains all of the signature metadata. Therefore:

-   Crafting a valid "other protocol" signature having an OpenPGP signing oracle requires breaking pre-image resistance.
-   Crafting a valid OpenPGP signature having an "other protocol" signing oracle requires a protocol that lets you freely sign an arbitrary hash.


I believe not even the very liberal CMS lets you do that, for instance ML-DSA is specified in pure mode only.

Cheers,
Aron
--Aron Wussler
Sent with ProtonMail, OpenPGP key 0x7E6761563EFE3930


> On Friday, 26 September 2025 at 09:45, Falko Strenzke <[email protected]> wrote:
> 

> > Am 25.09.25 um 14:07 schrieb Falko Strenzke:
> > 

> > > - It would also require the signer to sign the crafted data. Blindly signing the crafted data is in most cases already a security problem.
> > 

> > After meditating on this subject further I need to mention one aspect specific to v6 signatures, that makes crafting effective malicious data to be signed in another protocol rather feasible. This is due to the signature salt that is prefixed to the hashed data in v6 signatures. Thus, a crafted document to be signed in CMS could look like this
> > 

> > ${Freely choosable signature salt (32 byte)} | ${LIT header} | ${LIT body} | ${OpenPGP signature trailer}
> > 

> > This gives the attacker great freedom in the first 32 bytes (signature salt is 16, 24, or 32 bytes) to craft signed data that is interpreted differently in OpenPGP than in CMS. Specifically, the idea is to choose the the salt value such that different portions of the data in the following LIT body are ignored in both views of the data, i.e., the CMS and OpenPGP view.
> > 

> > For HTML the data signed in CMS could look for example like this:
> > 

> > Hello Friend [...] <!-- | ${LIT header} | ${Text appearing only in OpenPGP view} --> ${Text seen in both views} | ${OpenPGP signature trailer}
> > 

> > ^
> > end of the salt
> > 

> > This resembles on the idea of finding polyglots, i.e. data that is valid for content for different file types. This has been studied in the context of attacks exploiting lack of key commitment in AEAD [1].
> > 

> > In any case this generally applies to v6 signatures and the rationale seems to discourage cross-protocol use of OpenPGP keys.
> > 

> > Falko
> > 

> > [1] https://www.usenix.org/conference/usenixsecurity22/presentation/albertini
> > 

> > --
> > 

> > MTG AG
> > Dr. Falko Strenzke
> > 

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

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

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wrsEARYKAG0FgmjWxv4JEH5nYVY+/jkwRRQAAAAAABwAIHNhbHRAbm90YXRp
b25zLm9wZW5wZ3Bqcy5vcmc9vt+/EKHQJyHTFw7BNmN3F0nvPsoxqcbsjMMv
NUTqlxYhBIuVslFfa7tqthSdVX5nYVY+/jkwAACO/gEAonnwrQtFClAS5bXB
hGRBK5H7PrlKfKF9Ga7KPakLYGUBAKP3gZAkq2QUDS3pBPpp5H1mIVSvORAY
GZa1NpXf8bgM
=Im6l
-----END PGP SIGNATURE-----