Re: [openpgp] AEAD Chunk Size

"Neal H. Walfield" <> Fri, 15 March 2019 11:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4431F12AF7C for <>; Fri, 15 Mar 2019 04:40:18 -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 H_Z3XzxwNVSY for <>; Fri, 15 Mar 2019 04:40:15 -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 4B47C128B36 for <>; Fri, 15 Mar 2019 04:40:15 -0700 (PDT)
Received: from ([] by with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from <>) id 1h4lC8-0004A3-I5; Fri, 15 Mar 2019 11:40:12 +0000
Date: Fri, 15 Mar 2019 12:40:12 +0100
Message-ID: <>
From: "Neal H. Walfield" <>
To: "Derek Atkins" <>
Cc: Werner Koch <>,, Vincent Breitmoser <>
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, 15 Mar 2019 11:40:18 -0000

Hi Derek,

Thanks for your comments.

On Thu, 14 Mar 2019 15:17:41 +0100,
Derek Atkins wrote:
> On Thu, March 14, 2019 9:47 am, Neal H. Walfield wrote:
> > AEAD catches not only these errors, but also providers ciphertext
> > integrity.
> >
> > Are you arguing like Werner that catching transmission errors is
> > enough and that we shouldn't bother with ciphertext integrity?
> I don't see how these two are mutually exclusive.

These issues aren't mutually exclusive, and I apologize if I gave you
the impression that I thought they were.  I think everyone agrees that
catching transmission errors is desirable.  At least, I do :).  The
sticking point, AFAICT, is that Werner disagrees that the
specification should guarantee cipher text integrity when streaming.

I'm currently convinced that streaming authenticated plaintext is only
possible if we use small chunk sizes.  If we allow large chunk sizes
(e.g., 4 exabytes, which is what the current draft allows), then there
will be cases where an implementation can stream unauthenticated
plaintext, but not authenticated data, and, because it can, it will.
And this is even though pretty much everyone including the IETF (see
RFC 5116 [1]) agrees that AEAD must only emit authenticated plaintext.


Implementations will stream unauthenticated plaintext for
interoperability purposes.  Failing to decrypt, because the device
doesn't have enough resources, will prevent users from getting their
work done.  And, if security prevents users from getting their work
done, then the security mechanism will be worked around.

Implementations will stream unauthenticated plaintext to keep their
code simple.  If we allow implementations to stream unauthenticated
plaintext, then streaming authenticated data becomes a special case.
And, no one likes to maintain two code paths.

Will this happen in practice?  IT'S ALREADY HAPPENED.  There is
already an OpenPGP implementation written by one of 4880bis's editors
that emits unauthenticated plaintext.  Now, this puts pressure on
other implementations to follow suit, because users will inevitably
ask why FooGP can decrypt some messages that BarGP can't.

I think the only way to prevent this is to ensure that unauthenticated
streaming provides as few advantages over authenticated streaming as
possible.  This means ensuring that the amount of data to be buffered
is small, and making the implementation work as simple as possible by
using a fixed chunk size.

When I originally thought about this problem, I thought that
introducing a soft threshold could be an option.  But, I've since
concluded that this doesn't help.  Although a sender could use a small
chunk size to ensure that a compliant receiver doesn't emit
unauthenticated data, an attacker can change the chunk size in the
intercepted message, and successfully conduct an EFAIL-style attack.
(See [2].)


Derek, I hope this clarifies my position.  Do you now also agree that
ensuring cipther text integrity when streaming is desirable?  If not,
what concerns do you have?


:) Neal