[openpgp] AEAD Decryption

[Marcus Brinkmann <[e-mail]>]

Hi,

As the discussion about AEAD has resurfaced, I want to remind the working group that AEAD is not only about encrypting and tagging, but more importantly what happens when the verification of the tag fails after decryption, as I have pointed out to this WG in 2018, 2019, and 2020. Here is a summary of my concerns.

RFC5116 (Section 2.2) is very clear that the outcome of authenticated decryption is either an authenticated plaintext (with high probability), or an error symbol FAIL. In fact, this rule is what cryptographers expect when they see that an AEAD cipher mode is deployed. Any unauthenticated plaintext or partial plaintext that is output or internally processed (for example with a decompression engine) can lead to malleability attacks, defeating the purpose of using an AEAD cipher in the first place.

For unbounded data, a chunked AEAD mode is used, which can not prevent truncation attacks at the chunk boundary. However, for practical purposes, truncation seems much less harmful than other plaintext manipulations. For example, it’s an accepted risk in TLS that data can be truncated, but it is not acceptable that bytes can be altered.

Unfortunately, the current bis draft (draft-ietf-openpgp-crypto-refresh-06, Sec. 14.7) lumps malleability attacks on AEAD chunks in the same group as malleability attacks on any legacy cipher in OpenPGP, allowing conforming implementations to parse or release decrypted data and continue processing without an error even if validating an AEAD chunk or secret key fails:

"When an OpenPGP implementation discovers that it is decrypting data that appears to be malleable, it MUST indicate a clear error message that the integrity of the message is suspect, SHOULD NOT attempt to parse nor release decrypted data to the user, and SHOULD halt with an error.  Parsing or releasing decrypted data before having confirmed its integrity can leak the decrypted data [EFAIL], [MRLG15].“

The risk is not only EFAIL attacks, but also the whole canon of malleability attacks on TLS (Bleichenbacher Padding Oracles, CRIME, etc), as well as fault injection attacks such as Klima and Rosa and the recent key overwriting attacks by Bruseghin, Paterson, and Huigens. All these can be prevented by an AEAD cipher mode, but only if decryption and verification is implemented strictly.

I have just verified that the most recent development version of GnuPG (99d29318) does in fact internally process and output unauthenticated plaintext. Encrypting a large file containing the sentence „The quick brown fox jumps over the lazy dog“ over 800k times, and then modifying random bytes in the resulting cipher text, leads to two outcomes:

1. With compression, GnuPG shows the error message: 
gpg: Fatal: zlib inflate problem: incorrect data check
This indicates that GnuPG is processing unauthenticated plaintext after decryption with zlib, possibly leading to format oracle attacks.

2. Without compression, GnuPG outputs among other correct plaintext the following string:
The 9���=qu�-|�S��{jumps over the lazy dog
This indicates that the decryption of a manipulated block was output, leading to all kinds of malleability attacks.

In either case, GnuPG shows an error message and halts with an error at the end of the chunk modified chunk.

I recommend that the WG updates the draft to distinguish between legacy ciphers and AEAD ciphers in Section 14.7., and changes all SHOULD rules in the quote above to MUST for the new AEAD ciphers.

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