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

Hi DKG,

Am 13.11.25 um 22:05 schrieb Daniel Kahn Gillmor:
> 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.
Thanks for these clarifications.
>
>
>
> 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?

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.

Does this make sense?

Best regards,
Falko

>
>       --dkg
>
> _______________________________________________
> 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]