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

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>

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