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

[Marcus Brinkmann <[e-mail]>]

Hi,

> Am 19.08.2022 um 22:44 schrieb 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.

That’s one way to do it, but what we are proposing is more severe: The context is not included in the message, but has to be reconstructed at the recipient side from the actual context that is seen there. So, if the context changes, the recipient can not decrypt anymore.

There is a tradeoff made here.

* Not including the context protects against implementation errors, because it is much harder for developers to accidentally or on purpose ignore context changes and subsequently process unauthenticated plaintext. Which was exactly the failure mode responsible for Efail (recall that Efail worked despite SEIPD-MDC because implementations revealed unauthenticated plaintext and ignored integrity check failures).

* Including the context allows recovery of plaintext in case the context is lost, for example when relevant email headers are changed by email servers during transport (false positive). We evaluated that for the email servers we tested, email headers and MIME structure were preserved (with the exception of Outlook, which has since been fixed AFAIK).

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

In an earlier revision of our paper we included a security proof for a legacy construction based on a PRF with a collision-resistant hash function and a CPA-secure and INT-CTXT secure cipher. This can be shown to be equivalent to an AEAD construction.

SEIPD-MDC is not quite there. We don’t have any security proofs for this construction, but just from looking at it, it can at best only achieve INT-PTXT (because the MDC protects the integrity of the plaintext, rather than the ciphertext). So, you will never get the same security notion from SEIPD-MDC as for an AEAD mode. However, if plaintext integrity is good enough for you, SEIPD-MDC can certainly also be extended to include a context in a similar way as we did.

My personal opinion is that the stronger security notion INT-CTXT that you get from an AEAD mode is strongly preferable, as it protects against format oracle attacks such as the Vaudenay-Oracle. Now, it’s a happy circumstance that OpenPGP uses a variant of CFB rather than CBC, so it does not have a padding scheme. This means that Vaudenay is not directly applicable. However, the plaintext does have internal structure and validity checks, so other oracles are potentially possible (a well known example is the „quick check“ that is mentioned in the spec, but there are more, for example decompression failures, as I reported recently on this list even for AEAD in GnuPG). These attacks are well understood by the academic research community, but they do require an oracle that can be queried multiple times by an attacker to be exploited. Such oracles are difficult to construct for OpenPGP only because of its limited use in the real world, not(!) because of its security notions. From my perspective, this is just an accident waiting to happen. Anyway, that’s the case I would make for AEAD (or any other INT-CTXT-secure encryption mode).

> 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?

Thank you for this question. As I said above, our proposal is not to include the context explicitly in the OpenPGP data, but to let the recipient infer it from the actual context seen. This also implies that the context can only include things that are public.

This may be seen as a disadvantage in some use cases, but note that the sender decides what the context is (our proposal includes a way for the sender to specify the decryption context policy, and of course the sender also sets the actual headers and MIME structure of the outgoing email). So, a sender that has privacy concerns can limit the context in any way that seems appropriate to their use case.

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

The principled argument against that construction is that it requires the recipient to process unauthenticated plaintext, which gives the attacker an attack surface to launch oracle attacks. However, there are also non-legalistic arguments against this. Consider an Efail-attacker with a malleability gadget, and a vulnerable implementation that does not achieve even INT-PTXT security (as was the case for email clients vulnerable against Efail). It is conceivable that this allows the attacker to construct a cipher text with a context that matches the attack email, defeating the whole purpose of the context parameter. This is a chicken-and-egg problem: The context can’t be included in the cipher text (or plaintext), because it is intended to authenticate the cipher text (or plaintext).

Thanks,
Marcus

—
Dipl.-Math. Marcus Brinkmann

Lehrstuhl für Netz- und Datensicherheit
Ruhr Universität Bochum
Universitätsstr. 150, Geb. ID 2/461
D-44780 Bochum

Telefon: +49 (0) 234 / 32-25030
http://www.nds.rub.de/chair/people/mbrinkmann