Re: [openpgp] AEAD Chunk Size

"Neal H. Walfield" <> Mon, 18 March 2019 10:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 69BDD131101 for <>; Mon, 18 Mar 2019 03:53:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i3t2NGyMBZ9b for <>; Mon, 18 Mar 2019 03:53:19 -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 DAEA3127963 for <>; Mon, 18 Mar 2019 03:53:18 -0700 (PDT)
Received: from ([] by with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from <>) id 1h5ptL-0003tG-Fr; Mon, 18 Mar 2019 10:53:15 +0000
Date: Mon, 18 Mar 2019 11:53:14 +0100
Message-ID: <>
From: "Neal H. Walfield" <>
To: Tobias Mueller <>
Cc: Derek Atkins <>, 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: Mon, 18 Mar 2019 10:53:22 -0000

Hi Tobias,

On Sun, 17 Mar 2019 21:00:51 +0100,
Tobias Mueller wrote:
> On Fri, 2019-03-15 at 12:40 +0100, Neal H. Walfield wrote:
> > 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.
> > 
> >   [1]
> Maybe we're hitting a terminology issue here.

I think we do.

> For me, a plaintext is authenticated if the whole ciphertext could be
> successfully authenticated. Which seems to be very well in line with the
> definition you've linked to.

4880bis defines a chunking mechanism based on AEAD: the message is
split into multiple chunks.  In 4880bis, AEAD operates on a per-chunk
basis.  The chunking algorithm provides mechanisms for ensuring chunks
can't be reordered, detecting the end of the message, etc.  Using AEAD
to decrypt a chunk authenticates that chunk's ciphertext; for a given
chunk, the decryption operation will either return the correct
plaintext, or it will return an error.  This is exactly what RFC 5116
requires.  RFC 5116 doesn't discuss chunking; chunking is not AEAD.

The chunking mechanism in 4880bis (assuming implementors follow RFC
5116 with respect to AEAD on chunks) ensures that plaintext is only
released from authenticated ciphertext.  It does not protect against
truncation attacks.  Since OpenPGP decided to support streaming in RFC
2440 (which introduced One Pass Signature packets), this is inline
with OpenPGP's philosophy.  I don't think removing support for
streaming is useful.

You seem to think that AEAD's guarantees must apply to the whole
message.  I disagree.  I agree it is useful, but it is not possible
when streaming.

I think that even if we add a bit that says: "don't stream",
implementations will ignore it.  Moreover an attacker can just clear
it, and then the receiver streams it anyways.

> Now, if you modify a (long) ciphertext that has been broken into chunks
> near the end and a decryption routine reveals the first parts of the
> decrypted ciphertext, would you agree that revealing those parts of the
> plaintext does not meet the definition that you've linked to?

No.  AEAD is applied to chunks.

> And do you further agree that you would need to find a way to prevent
> any plaintext to be revealed unless the full message has been
> authenticated correctly in order to match the definition that you've
> mentioned?

No.  AEAD is applied to chunks.  When a chunk is decrypted, it either
returns authenticated plaintext, or an error.

Referring to <>
On Sun, 17 Mar 2019 21:01:32 +0100,
Tobias Mueller wrote:
> On Thu, 2019-03-07 at 18:09 +0100, Neal H. Walfield wrote:
> > You're afraid of bugs.  So am I.  Dynamically resizing buffers is
> > error prone.  Even computing AEAD's chunk size is hard:
> point taken. Programming is hard. Programming C is even harder. Tooling
> could be improved. We ought to write a spec that achieves a security
> goal while making it less likely that people implement the spec wrongly.

I agree.  Less flexibility in the spec is better, which is what I

You rightly argue, I think, that AEAD without chunking is easier to
implement.  But, OpenPGP supports streaming, which is incompatible
with AEAD without chunking.  Consequently, streaming using AEAD
without chunking means releasing unauthenticated (as I have defined it
above) plaintext.

Releasing unauthenticated plaintext is much worse than releasing only
an authenticated prefix.  Releasing unauthenticated plaintext allows
for an EFAIL style attack; releasing an authenticated prefix does not.
Releasing an authenticated prefix prevents ciphertext malleability.

> You've made a point but you haven't really taken a stance on the point
> that I raised. Which boils down to your proposal forcing everybody to
> use chunking which in turn can be implemented wrongly while providing no
> benefit in return.

Only releasing plaintext from authenticated chunks prevents
EFAIL-style attacks.  That is not no benefit, that is not a little
benefit, that is a huge benefit.

> I believe that the potential for releasing plaintext although the
> ciphertext has not been authenticated is higher if I need to call that
> oracle multiple times, invent a secure scheme for detecting truncation,
> and implement that scheme correctly.

I agree that the added complexity that chunking imposes is not worth
it *if* the only reason to introduce chunking is to detect
transmission errors early.  But, it is not.  It prevents modifications
to the ciphertext.

> Your proposal removes the option for the message producer to decide
> whether it wants to have the recipient (which may very well be the same
> entity) rely on an implementation which gets all that right. Because
> with the status quo, one can opt for producing one chunk which is
> trivially protected against truncation and other attacks.

You say that it is trivially protected, but this is not the case,
because exactly in those cases implementors will just stream
unauthenticated data.  They should only be able to stream data from
authenticated chunks.

> Unless I understand your proposal wrong. But then my question is, how
> would I encode a message that is not susceptible to (at least)
> truncation attacks? Again, assuming the above mentioned oracle.

OpenPGP allows streaming.  The implementation doesn't provide a
mechanism to prevent streaming.  I'm not sure it would be a good idea
to provide one, as I don't think there is a sensible way for the
sender to decide when to set that bit.

> I don't fully understand why you are mentioning dynamically resizing
> buffers. Strictly speaking, you need space for a single digit number of
> blocks (!) to decrypt an EAX or OCB message.

The size of the message is not known apriori if partial body length
encoding is used.  Even an upper bound is not known if compression is