[openpgp] Re: on the risks of AEAD as signature [was: Re : draft-ietf-openpgp-persistent-symmetric-keys-02.txt]

We have written a short report about the applicability of MKC against 
OpenPGP: 
https://github.com/crypto-security-tools/openpgp-mkc/releases/download/v1.0/openpgp-mkc.pdf

I have already summarised the basic conclusion below. However, there are 
some other subtle aspects that the report covers, such as looking at 
other uses of AEAD in OpenPGP.

Falko

Am 11.11.25 um 08:18 schrieb Falko Strenzke:
> Am 10.11.25 um 17:24 schrieb Andrew Gallagher:
>> On 10/11/2025 13:52, Daniel Huigens wrote:
>>> The reason we added an HKDF step for AEAD in SEIPDv2 and S2K usage
>>> octet 253 was to thwart cross-AEAD-mode attacks, not key commitment.
>>
>> Right, I thought we also got key commitment as a side effect, but 
>> after doing the maths it seems any protection given is minimal.
>>
>> The HKDF output is shared between the message key and the IV, so if 
>> you generate two message keys via HKDF you also get two different 
>> IVs, and the attack described relies upon the IV/nonce being the same 
>> between both ciphertexts. To make the salamander attack work in 
>> practice you need two different message keys with the same IV, 
>> therefore you need to find two HKDF outputs with N-64 colliding bits 
>> in the appropriate place... so at first glance that's good.
>
> In [1], for neither GCM nor OCB3 
> <https://www.usenix.org/system/files/sec22-albertini.pdf#page=6> it is 
> apparent to me that the IV has to be equal for multi-key-collisions 
> (MKC). It doesn't enter the equations for computing the tag. For GCM 
> it is especially easy to show that the IV isn't relevant. Let's assume 
> a 2-key-collision attack. For the encryption / decryption, the IV 
> affects only the key stream, since it forms the predecessor of the 
> first counter block for the CTR encryption. In ranges where bits in 
> the resulting plaintext have to be controlled in both plaintexts, 
> finding keys that satisfy the required bit values have to be found by 
> brute force anyway. It doesn't matter whether the key candidates for 
> both plaintexts are used to encrypt the same counter block or 
> different ones. In either case, the brute force effort is 2^x trial 
> encryptions, where x is the number of bits that have to be controlled 
> in both plaintexts. For the remaining bit positions in the plaintext, 
> the value matters only in either one plaintext and thus can be 
> controlled by bit flips in the ciphertext, causing no effort in any 
> case. The tag repair is done entirely only through an area that must 
> be random in both plaintexts.
>
> In case you are referring to [2] for the assumption that nonce has to 
> be equal, then this might be easy to resolve: In the attacked scheme 
> <https://eprint.iacr.org/2019/016.pdf#page=7>, the nonce is prepended 
> to the ciphertext, thus must be committed to by the attacker, and for 
> this reason has to be equal for both keys.
>
> What in my understanding reliably prevents the known attacks against 
> GCM and OCB3 in OpenPGP is the final authentication tag computed over 
> an empty input. All attacks known in the literature require a certain 
> amount of attacker controlled space in the message:
>
> - For AES-GCM:  one block at the same position in both plaintexts or 
> in the additional data
> - For OCB3:  2b blocks at the same position in both plaintexts, where 
> b is the block cipher’s block size in bits
>
> With the empty plaintext and the additional data determined by the 
> message and chunk index, it is not possible to achieve an MKC with the 
> attacks given in the literature. If an application releases plaintext 
> early during decryption, and the final error message is ignored, then 
> MKC is possible, but this is true for attacks shortening the message 
> as well.
>
> Falko
>
> [1] /How to Abuse and Fix Authenticated Encryption Without Key Commitment/
> Ange Albertini and Thai Duong, Google Research; Shay Gueron, 
> University of Haifa
> and Amazon; Stefan Kölbl, Atul Luykx, and Sophie Schmieg, Google Research
> https://www.usenix.org/conference/usenixsecurity22/presentation/albertin
> https://www.usenix.org/system/files/sec22-albertini.pdf
>
> [2] /Fast Message Franking: From Invisible Salamanders to Encryptment/
> Yevgeniy Dodis, Paul Grubbs, Thomas Ristenpart, Joanne Woodage
> https://eprint.iacr.org/2019/016.pdf
>
>>
>> But. GCM uses a 12-octet nonce (i.e N=96), leaving only 32 bits in 
>> the IV - which is practically nothing, equivalent to colliding a 
>> short keyID. Yikes.
>>
>> A
>>
>> _______________________________________________
>> openpgp mailing list -- [email protected]
>> To unsubscribe send an email to [email protected]
> -- 
>
> *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>
>
-- 

*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>

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