[openpgp] Re: multi-key collisions in OpenPGP

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).

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?

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?


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 to [email protected]

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