[openpgp] multi-key collisions in OpenPGP [was: Re: Re : on the risks of AEAD as signature]

Daniel Kahn Gillmor <[email protected]> Thu, 13 Nov 2025 16:05:46 -0500
Newsgroups	gmane.ietf.openpgp
Message-ID	<[email protected]>
Hi Falko--

On Thu 2025-11-13 10:24:57 +0100, Falko Strenzke wrote:

> https://github.com/crypto-security-tools/openpgp-mkc/releases/download/v1.0/openpgp-mkc.pdf

Wow, thank you for this in-depth analysis!  I'm still processing it, but
it's really useful to see it written down this clearly.

A couple notes from my first pass:

on p.13, you write:

  In principle, if assuming that the consuming implementation is
  supporting RFC 9580, the approach of encapsulating the trailing data
  in Padding Packets as in shown in Figure 2 could be used in the case
  of v1 SEIPD as well, since RFC 9580 requires implementations to be
  able to handle padding packets anywhere in a packet sequence.

I think this statement is backward: it's everything that *doesn't* align
with 9580 which is vulnerable, because of two factors.

1. Accepting the Padding packet is necessary for this attack, since the
   same attack could be done with the "Trust packet".  From 2440 onward,
   all standardsindicate that the Trust packet "SHOULD be ignored on any
   input other than local keyring files."
   https://www.rfc-editor.org/rfc/rfc2440.html#section-5.10

2. Unlike 4880 (and LibrePGP), RFC 9580 technically does not permit
   additional data following the MDC:

     https://www.rfc-editor.org/rfc/rfc9580.html#section-5.13.1-6

   In particular, in 9580, the MDC calculation is described as integral
   to the encryption/decryption process for SEIPDv1, not as a distinct
   packet.  Thus, no additional packets can follow it after decryption.

   See also:
   https://www.rfc-editor.org/rfc/rfc9580.html#appendix-B.1-3.6.1

   This tightening up was proposed by Daniel Huigens during the move to
   SEIPDv2:
   https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/135/diffs?commit_id=9cf53c97e909ee6ebbe259ad85d5e4c147fa0de7
   and explicitly approved on gitlab by Jeffrey Lau, Justus Winter, and
   myself; and merged by Paul Wouters.



I'm also struggling to understand this sentence in the conclusion:

    Should an implementation release AEAD-decrypted plaintext blocks
    before the verification of the final authentication tag and the
    later indication of an error in the final authentication tag should
    not prevent the further processing of the released plaintext, this
    type of attack would, however, be applicable.

Maybe something got garbled between edits -- could you try to restate it
more clearly?

     --dkg

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]
signature.asc (application/pgp-signature, 324 B)