Re: [openpgp] OpenPGP encryption block modes (Was: The Argon2 proposal seems incomplete (Draft 6))

[Bruce Walzer <[e-mail]>]

On Mon, Aug 08, 2022 at 09:19:15PM +0200, Marcus Brinkmann wrote:
> > Am 02.08.2022 um 18:59 schrieb Bruce Walzer <[e-mail]>:
> > AEAD isn't even a very accurate term in an OpenPGP context. There is
> > no AD (associated data) exposed to the user of such a system. It just
> > doesn't work that way.
> 
> It would be very useful to expose AD in OpenPGP to users to prevent exfiltration attacks in the context of email. See our research at [1].
[...]
> [1] Jörg Schwenk, Marcus Brinkmann, Damian Poddebniak, Jens Müller, Juraj Somorovsky, and Sebastian Schinzel. 2020. Mitigation of Attacks on Email End-to-End Encryption. In Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security (CCS '20). Association for Computing Machinery, New York, NY, USA, 1647–1664. https://doi.org/10.1145/3372297.3417878
> 
> Preprint available here: https://www.nds.ruhr-uni-bochum.de/media/nds/veroeffentlichungen/2020/12/06/schwenk2020.pdf

Correct me if I am wrong, but the basic idea here is to include
information about the context that existed at the time of encryption
in the associated data (AD) of a AEAD encrypted packet. A receiver of
such a packet could then check to see if the context had changed, and
if it had, if it had changed in a reasonable way.

>From the linked paper:

> ...EFAIL-MG has been mitigated in IETF standards with the
> introduction of Authenticated Encryption with Associated Data (AEAD)
> algorithms.

I don't accept that the addition of AEAD modes to the standard
provides any benefit over what can be done with the exiting well
standardized SEIPD-MDC mode against EFAIL-MG. So I can't assume that
any mode with AD has to exist. This would have to stand as a argument
to provide such a mode on its own to be compelling to me.

Would sending this context data in plain text as AD even be the best
choice here? Wouldn't it be better to prevent attacker knowledge of
this data by encrypting it? Why give the attacker information about
the context they would have to forge?

One way this might be done would be to define a new packet type for
context and add that packet into the encrypted SEIPD-MDC packet. That,
in theory, would be entirely compatible with existing usage. That
would be as opposed to creating AEAD packets that are entirely
incompatible with existing usage.

Bruce