Re: [openpgp] AEAD Chunk Size

"Neal H. Walfield" <> Fri, 29 March 2019 14:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 22A671202AE for <>; Fri, 29 Mar 2019 07:37:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qS5M1lK0UTJ7 for <>; Fri, 29 Mar 2019 07:37:17 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EBE2E120249 for <>; Fri, 29 Mar 2019 07:37:16 -0700 (PDT)
Received: from ([] by with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from <>) id 1h9sd7-0007bi-A2; Fri, 29 Mar 2019 14:37:13 +0000
Date: Fri, 29 Mar 2019 15:37:12 +0100
Message-ID: <>
From: "Neal H. Walfield" <>
To: Peter Gutmann <>
Cc: "" <>, Justus Winter <>, Jon Callas <>, Jon Callas <>
In-Reply-To: <>
References: <> <> <>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Archived-At: <>
Subject: Re: [openpgp] AEAD Chunk Size
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 29 Mar 2019 14:37:20 -0000

At Fri, 29 Mar 2019 13:43:35 +0000,
Peter Gutmann wrote:
> Neal H. Walfield <> writes:
> >But what is the cost?  I would say there is basically none.  So it makes no
> >sense to me to optimize for this case.  It's irrelevant.
> There is a significant cost in terms of implementing, debugging, and interop-
> testing every implementation that wants to do this.  If no-one cares about
> auth protection of data at rest, and in the complete absence of real-world
> data I'm going to claim no-one does because you can't prove otherwise, using
> what we currently have has zero cost because it's already implemented.  Adding
> blocked auth protection has a distinctly nonzero cost.

Ok.  Is your position that the working group should remove AEAD from
4880bis until there is an academic study proving people need it?

> >Efail occured.  Why is that not enough?
> That was due to broken email apps.  If I can convince your email app to
> forward the plaintext of a decrypted message to me, you lose no matter what
> encryption mechanism you use.
> Admittedly CBC/CFB made this easier, but it was the email apps that needed
> fixing, not PGP.

I see it differently.  I would say it was a combination of the email
applications needing fixing and PGP needing fixing.

PGP encourages implementations to support streaming, and most do.
But, using 4880, this means that an application may see plaintext from
unauthenticated ciphertext.  Efail shows how that can be exploited by
***modifying the ciphertext*** (a PGP problem) to create a potential
exfiltration channel.  Using chunked AEAD correctly, this type of
attack is not possible: it is possible to stream, and only release
plaintext from authenticated ciphertext.

Now, applications could have protected themselves from this attack if
they had backed out the message on MDC failure.  But, they didn't.
And, I'd argue that a major reason that they didn't was because this
type of attack is not well understood by application developers.
Application developers understand truncation.  But, ciphertext
modification is something that most have probably never heard of.
Since we can protect application developers from ciphertext
modification, I would argue that not doing so is negligent.

So, if we are distributing blame, and I'd rather not play that game,
then I'd place 90% of the blame on the WG and the PGP implementations,
and only 10% on the mail application developers.