[openpgp] Re: multi-key collisions in OpenPGP

Hi Daniel,

Am 14.11.25 um 18:00 schrieb Daniel Huigens:
> Hi Falko & dkg,
>
> Thanks for the analysis!
>
> I want to backtrack a bit to understand the (potential?) attack, before
> we jump to the conclusion that OpenPGP implementations shouldn't emit
> plaintext AEAD chunks (whose tags validate) before having validated the
> final empty chunk, because I think that would be an unfortunate
> outcome (as it partly defeats the purpose of having chunks at all).
Releasing plaintext before the final chunk is only a problem if the 
message isn't cancelled after seeing the final authentication tag or the 
lack of it. If incompletely verified plaintext in this sense is rendered 
to the user or otherwise processed, this is a problem first of all due 
allowing truncation attacks. The possibility of MKC would only be 
further problem. But for MKC to be a real problem, we need a special 
setting (see my example below).
>
> I assume the attack is that you could craft a single SEIPDv2 message
> that can be decrypted (up to the final tag) by different parties to
> different plaintexts. Is that true?
Yes. In our analysis, we make the assumption of just a single chunk 
before the final authentication tag. Multiple message chunks would 
require per-chunk engineering in the attack.
>
> Even if that attack is possible, do we think it enables things you can't
> already do?
> Obviously, you can just send two recipients a different message, for
> example.
> In the context of RFC9788(-to-be, at the time), I brought up the topic
> of To header spoofing; i.e. you could pretend (in protected headers)
> to have sent the same message to another recipient, while in fact you
> didn't. At the time this wasn't seen as a super serious concern because
> you could do the same thing with two separate SMTP submissions.
> (In principle, the SMTP server could check that the outer To headers
> are correct, but it's unclear whether most servers do so.)
> But, maybe there are (non-email) scenarios where this is normally not
> possible?

In principle we didn't mean to make any statement as to whether there is 
an actual practical attack. However, the fact that it is possible to 
send different messages to different recipients seems rather obvious. In 
contrast, with MKC, you can create a single message that decrypts to 
different messages for different recipients, which is not necessarily 
obvious to everyone as the examples of vulnerable real-world systems in 
the literature show.

Assume the following setup in a financial institution, which is by 
regulation required to record all communication with customers in 
plaintext. When an employee sends an OpenPGP encrypted message, his mail 
client always encrypts the message additionally with keys for the mail 
proxy that records the messages in plaintext. With an MKC, as it might 
be possible against v1 SEIPD, a malicious employee might craft a message 
that decrypts differently to the gateway than to the customer. But with 
OpenPGP AEAD, I don't think it would be possible.

Best regards,
Falko

>
>
> Separately: I looked at the sage code for a multi-key collision against
> GCM, and it seems to assume that both messages have the same nonce.
> I tried to adapt it to use different nonces, but it didn't work;
> but maybe I missed something. Do you know if this is required for
> the attack to work?
>
> As Andrew said, in the case of GCM, the HKDF step in SEIPDv2 generates
> 4 random bytes for the nonce, which is not a lot but it would still be
> interesting to know whether the attack requires brute-forcing the
> session key to lead to two identical nonces or not..
>
> Best,
> Daniel
>
>
> On Friday, November 14th, 2025 at 15:10, Daniel Kahn Gillmor wrote:
>
>> On Fri 2025-11-14 09:48:46 +0100, Falko Strenzke wrote:
>>
>>> What the paragraph is meant to say is that the plaintext of decrypted
>>> AEAD chunks might be output by an application before the verification of
>>> the final authentication tag. In that case, if this plaintext is
>>> processed, and the error of the failing verification of the final
>>> authentication tag was ignored, MKC is possible.
>>
>> Yes, this does make sense, thanks.
>>
>> This seems like a challenging thing to test, given the wide variety of
>> OpenPGP APIs out there, let alone the range of consumers of those APIs
>> and their various tolerances for ignoring errors.
>>
>> I suppose a baseline test would be to have an artifact with a broken
>> final tag, and see how various implementations behave when processing
>> it via their sop interface:
>>
>> - do they emit any cleartext?
>>
>> - do they validate any signatures found in the data leading up to the
>> failed tag?
>>
>> I've opened
>> https://gitlab.com/sequoia-pgp/openpgp-interoperability-test-suite/-/issues/171
>> to track that suggestion.
>>
>> --dkg
>> _______________________________________________
>> openpgp mailing list [email protected]
>> To unsubscribe send an email [email protected]
> _______________________________________________
> openpgp mailing list [email protected]
> To unsubscribe send an email [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]