Re: [openpgp] Encryption and signature context parameter (Was: OpenPGP encryption block modes)

[Marcus Brinkmann <[e-mail]>]

Hi Daniel,

> Am 17.08.2022 um 16:15 schrieb Daniel Huigens <d.huigens=[e-mail]>:
> On the one hand, I personally think that supporting multiple encrypted
> parts, or mixing encrypted and unencrypted parts, and replacing an
> encrypted MIME part with an unencrypted part in-place, is fraught, and
> in ProtonMail we don't support it. Nevertheless, I know it's something
> that is done, and some users expect it.
> 
> On the other hand, I agree that having some binding between the
> encryption and the email context would be valuable. In an ideal world,
> we would all be using PGP/MIME with protected headers, but as you point
> out, PGP/MIME can also be downgraded to PGP/Inline, so that might not
> even be sufficient.

Yes, and we limited our investigation to email encryption only because that was a nicely scoped academic research task. Even just adding some mime type, file ending, or any other meaningful label as context parameter would be useful to disable potential attacks that exploit context confusion across different application domains (for example stuffing email ciphertexts into OpenOffice documents should they support public key document encryption in the future).

> So, I agree it could be valuable to add something like this, though
> it's a bit last minute. But we could indeed do so for SEIPDv2 without
> breaking stuff. However, to do so we would need to define somewhere
> what the AD should be, for example in a spec about PGP/MIME, and
> perhaps also for PGP/Inline, etc.

It would be great to get some consideration to this, so I am glad to help in any way I can.

In the paper we describe a simple approach where the context data is just the AD. In OpenPGP, the AD already contains some metadata. Here I would suggest to add a variable length field to the AD of every chunk with a two-octet length followed by raw context parameter that would be provided upon encryption and decryption by the implementation. Note that in general the context parameter should not itself be included in the OpenPGP data structures, because that would invite implementations to „cheat“ and to use the included context parameter instead actually deriving the context parameter from, well, the context.

Some design options (feel free to ask for more details):

* Use a fixed length field instead of a variable length field, and define how the context parameter is compressed into it with a hash function. Don’t recommend, because it adds an extra assumption to the security reduction and duplicates what the AEAD already does. (In the rare case where the AD is massive and slows down chunk verification, it could already be hashed by the application instead at the application’s own peril). Also, if no context parameter is used this is less efficient and requires a default value.

* Use a PRF to include the context data in the key derivation (similar to how the per-message salt works). This is an alternative for legacy (non-AEAD) ciphers. We have a security proof for this based on the PRF assumption, the collision-security of the hash function used by the PRF, and the CCA and INT-CTXT security of the encryption. Don’t recommend, because why bother with this? Just use an AEAD mode.

* For recovery and debugging purposes, one might optionally want to include the context parameter in the OpenPGP packet (not just the AD during encryption/decryption) despite the risks that this entails. This is dangerous, because it allows applications to „cheat“ and decrypt outside of the intended context at will. However, there may be use cases where it is important to be able to decrypt even if the original context is lost. Don’t recommend because it feels like a trap to me, but it could alleviate some valid concerns.

> As a slightly orthogonal point, there have also been security issues
> with signatures being reused in different contexts. The Intended
> Recipient Fingerprint subpacket fixes one of those, but not all.
> I think it would be valuable to have a `context` parameter in OpenPGP
> that is used for both signatures and encryption, and then the
> higher-level spec or application using OpenPGP can define how the
> context should be computed. That might also address some of the
> concerns in your other message about email signature spoofing,
> perhaps.

Yes, thank you for raising the subject of signatures. I do agree there is value in signing contexts. For example, a PGP/Inline attachment is a signature over the raw binary content of the attachment, and that could possibly be substituted as a Debian package or Git commit signature in a phishing attack. To prevent this entirely, adding a context label to signature generation and verification would be helpful. A more relevant example would be MIME wrapping signatures from our „Johnny you are fired!“ paper, where a valid signature is included in a larger MIME email with multiple parts, and possibly the ID attacks from that paper depending on how emails implement the context derivation.

We did discuss signing contexts shortly at the time, but decided to not cover them in the paper. First, focussing on encryption made sense for the purpose of academic review and publishing. But also because cryptographically the solution is pretty simple: Just hash more data when signing. This does not strictly require a new API. However, to make this actually work in practice there has to be a global policy for a guaranteed length field or separator that can not be omitted and that ensures that messages with different contexts (including no context) can not overlap. This is something that would need be best specified in the OpenPGP standard to be effective. I do regret now that we did not at least mention this explicitly in future work.

> If there is interest in this, I can make some MRs proposing changes to
> that effect.

Happy to review and/or help in any way I can.

Thanks,
Marcus

> ------- Original Message -------
> On Monday, August 8th, 2022 at 21:19, 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].
>> 
>> Thanks,
>> Marcus
>> 
>> [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
>> 
>> —
>> 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
>> 
>> _______________________________________________
>> openpgp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/openpgp

—
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