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

Hi, Falko.

On 13/11/2025 09:24, Falko Strenzke wrote:
> We have written a short report about the applicability of MKC against 
> OpenPGP: https://github.com/crypto-security-tools/openpgp-mkc/releases/ 
> download/v1.0/openpgp-mkc.pdf
> 
> I have already summarised the basic conclusion below. However, there are 
> some other subtle aspects that the report covers, such as looking at 
> other uses of AEAD in OpenPGP.

Thanks for this! I have a concern about the hypothetical attack against 
SEIPDv1 described in section 5 though - this appears to only work if an 
implementation supports a hybrid but otherwise literal reading of 
SEIPDv1 from RFC4880 *and* the padding packet from RFC9580, which I 
think is an unlikely combination.

To recap, RFC4880 requires the plaintext contents of SEIPDv1 to be 
terminated with an MDC packet containing the modification detection 
code. If we were to apply RFC9580's padding requirement "MUST accept 
padding at any position" directly to the definition of SEIPDv1 from 
RFC4880, then yes it would appear to be possible to hide trailing 
parasitic data in a padding packet.

But RFC9580 also redefines SEIPDv1 to exclude the MDC packet from the 
"content" of the encrypted data, and instead defines it as part of the 
enclosing SEIPDv1 packet. This results in the same overall wire format 
under normal usage, but means that a conformant RF9580 implementation 
cannot accept a padding packet after the MDC, because the MDC is no 
longer considered part of the packet sequence. This effectively 
sidesteps the rule that padding packets may be placed "anywhere".

Either way, I think it is highly unlikely that an implementer following 
either specification would have intentionally written code that detects 
and silently ignores a padding packet in this particular context. A 
legacy receiving implementation would have to process an MDC packet 
before it detected the final block of the encrypted bytestream, which is 
an impossible scenario under RFC4880 and therefore unlikely to have been 
explicitly handled. And a fresh implementation based solely on RFC9580 
would not consider the MDC to be part of the packet sequence at all.

So I think we can also discount this attack scenario in practice.

Thanks again!

A

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