Re: [openpgp] Backwards compatibility

Paul Wouters <> Wed, 18 October 2023 18:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A4622C14CE24 for <>; Wed, 18 Oct 2023 11:19:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Status: No, score=-7.105 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_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EI6xN-89BZK2 for <>; Wed, 18 Oct 2023 11:18:58 -0700 (PDT)
Received: from ( [IPv6:2a03:6000:1004:1::85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 09EBDC14F5E0 for <>; Wed, 18 Oct 2023 11:18:57 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 4S9fHf1kK0z38K; Wed, 18 Oct 2023 20:18:54 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1697653134; bh=W0zHpr0F4RR2suzhWzSCzIBmcs6xXSxZc1dEZ399pDs=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=ETXfObMlwcLgTWZvO6wLwC+3kCO8EK2OZoLm6FikZ6G2wqpDdJB6NtJRZ2V8rRmhJ weSvI9LgndmyIExaU3/N1SB/99yf9eT7GW8jhU9LfjIoZsRzshreS88BZeMl7nc37H sLtW0yGPmkbekZnu/qRN5+diI6OmM9tGMQufKYU4=
X-Virus-Scanned: amavisd-new at
Received: from ([IPv6:::1]) by localhost ( [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id h93yEKEeQY4G; Wed, 18 Oct 2023 20:18:52 +0200 (CEST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Wed, 18 Oct 2023 20:18:52 +0200 (CEST)
Received: by (Postfix, from userid 1000) id 4CDD8109744B; Wed, 18 Oct 2023 14:18:51 -0400 (EDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4BE70109744A; Wed, 18 Oct 2023 14:18:51 -0400 (EDT)
Date: Wed, 18 Oct 2023 14:18:51 -0400
From: Paul Wouters <>
To: Werner Koch <>
In-Reply-To: <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [openpgp] Backwards compatibility
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 18 Oct 2023 18:19:02 -0000

On Wed, 18 Oct 2023, Werner Koch wrote:

>> But without some “added complexity” those deployments are vulnerable
>> to various real world attacks. The document needed to address those
> Please describe them while

Discussion can be found here:

You can also use the "git blame" command on any line in the repository
leading to a commit message that explains the change. Together, these
tools will give you an easy answer to why certain changes we deemed
neccessary by the OpenPGP Working Group. If you find any particular
mistakes, please describe these on the list or during IETF Last Call.

A number of known attacks (eg EFAIL) are informatively references in the
document to explain to the reader why there might be some "added

A general summary of why openpgp changes were needed can be found in the
charter text, which you yourself worked on as well.

> taking in account that the addition of GCM is in itself a real world attack.

I'm sure the CFRG would be interested in hearing about GCM attacks.

But even if so:

 	It is assumed that only the combinations of algorithms listed are
 	supported by the recipient's implementation, with the exception of the
 	mandatory-to-implement combination of AES-128 and OCB.

AES_GCM is not mandatory to implement, so as per your:

 	> OpenPGP have been deployed in highly critical environments and were
 	> often preferred over CMS/X.509 when it came to the replacement of
 	> symmetric encryption by public key encryption.  Willfully destroying
 	> backward compatibility and adding extra complexity is not what such
 	> deployments need.

These systems will not be affected.

There was a lengthy discussion on AES_GCM. I understand that you are
focused more on the BSI than NIST, but there are good reasons to support
AES_GCM and many people needed it for FIPS compliance and prefer to have
CPU hardware accelerated algorithms. Luckily, the resulting document can
be used by those who want and those who do not want AES_GCM, and the
complexity of a code point in addition to EAX and OCB is well, miniscule.
I find it hard to believe that all other IETF protocols can safety
support AES_GCM, but not OpenPGP.