[openpgp] AEAD Decryption

Marcus Brinkmann <marcus.brinkmann@rub.de> Mon, 27 June 2022 14:02 UTC

Return-Path: <marcus.brinkmann@rub.de>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 90DD3C15AAC4 for <openpgp@ietfa.amsl.com>; Mon, 27 Jun 2022 07:02:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rub.de
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Gle3zA9Pj_46 for <openpgp@ietfa.amsl.com>; Mon, 27 Jun 2022 07:02:29 -0700 (PDT)
Received: from out2.mail.ruhr-uni-bochum.de (out2.mail.ruhr-uni-bochum.de []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4039FC157B36 for <openpgp@ietf.org>; Mon, 27 Jun 2022 07:02:28 -0700 (PDT)
Received: from mx2.mail.ruhr-uni-bochum.de (localhost []) by out2.mail.ruhr-uni-bochum.de (Postfix mo-ext) with ESMTP id 4LWqDJ6BZbz8SX1 for <openpgp@ietf.org>; Mon, 27 Jun 2022 16:02:24 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rub.de; s=mail-2017; t=1656338544; bh=J2r2cDrgv/BCDKcgEd6X17kI+k8NzK9OLWnFrko8hDc=; h=From:Subject:Date:To:From; b=VELJ98FpPZkeIY7nf5dT2b/m9bu0FglX2UcOpTSPswkvDzl3snHk126dTQcLLSt8b 3shpbLlgA3O33a+FkcZUI5XxfdkWeOgF6OxrqnUt4j+H0+sP/SaHSTRQ/IhwPdXOWd O3CDXUFcHXkEsnAkcxSjwnAPyKpfu0yJtW3+/BhQ=
Received: from out2.mail.ruhr-uni-bochum.de (localhost []) by mx2.mail.ruhr-uni-bochum.de (Postfix idis) with ESMTP id 4LWqDJ5Yqlz8SWP for <openpgp@ietf.org>; Mon, 27 Jun 2022 16:02:24 +0200 (CEST)
X-Envelope-Sender: <marcus.brinkmann@rub.de>
X-RUB-Notes: Internal origin=
Received: from mail2.mail.ruhr-uni-bochum.de (mail2.mail.ruhr-uni-bochum.de []) by out2.mail.ruhr-uni-bochum.de (Postfix mi-int) with ESMTP id 4LWqDH2zXtz8SHY for <openpgp@ietf.org>; Mon, 27 Jun 2022 16:02:23 +0200 (CEST)
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.104.1 at mx2.mail.ruhr-uni-bochum.de
Received: from smtpclient.apple (int-63-16.vpn.ruhr-uni-bochum.de [IPv6:2a05:3e00:c:5::a05:3f10]) by mail2.mail.ruhr-uni-bochum.de (Postfix) with ESMTPSA id 4LWqDH0HR0zDh1n for <openpgp@ietf.org>; Mon, 27 Jun 2022 16:02:22 +0200 (CEST)
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.104.2 at mail2.mail.ruhr-uni-bochum.de
From: Marcus Brinkmann <marcus.brinkmann@rub.de>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.\))
Message-Id: <1268B7E7-9548-4AD0-8649-0E99229F2C13@rub.de>
Date: Mon, 27 Jun 2022 16:02:21 +0200
To: openpgp@ietf.org
X-Mailer: Apple Mail (2.3693.
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/tN2jWx4hUtiMGSo8-ILRXYNumVY>
Subject: [openpgp] AEAD Decryption
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jun 2022 14:02:33 -0000


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.


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