Re: [openpgp] AEAD Chunk Size

"Neal H. Walfield" <> Fri, 29 March 2019 09:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ADE5512047A for <>; Fri, 29 Mar 2019 02:23:39 -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=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4NTTRgoQZTmX for <>; Fri, 29 Mar 2019 02:23:37 -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 A66D81203CE for <>; Fri, 29 Mar 2019 02:23:37 -0700 (PDT)
Received: from ([] by with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from <>) id 1h9njT-0003ro-TW; Fri, 29 Mar 2019 09:23:27 +0000
Date: Fri, 29 Mar 2019 10:23:27 +0100
Message-ID: <>
From: "Neal H. Walfield" <>
To: Peter Gutmann <>
Cc: Jon Callas <>, "" <>, Justus Winter <>, 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 09:23:47 -0000

On Fri, 29 Mar 2019 04:17:03 +0100,
Peter Gutmann wrote:
> Neal H. Walfield <> writes:
> >Until now, OpenPGP didn't require buffering data.  A decrypted AEAD chunk
> >MUST only be released when it has been authenticated.  In the current
> >proposal, AEAD chunks are potentially unbounded (well, up to 4 exabytes...)
> >in size.  No one can decrypt such chunks without cheating, i.e., releasing
> >unauthenticated plaintext.
> This has been considered before, e.g. with S/MIME's authenticated encryption:
> and so far doesn't seem to have caused any major problems.  That is, it's not
> that there's a perfect solution, it's that actual problem situations seem to
> be pretty rare.

The advice seems pretty good:

   The exact solution to these issues is somewhat implementation-
   specific, with some suggested mitigations being as follows:
   implementations should buffer the entire message if possible and
   verify the MAC before performing any decryption.  If this isn't
   possible due to streaming or message-size constraints, then
** implementations should consider breaking long messages into a
** sequence of smaller ones, each of which can be processed atomically
** as above.  If even this isn't possible, then implementations should
   make obvious to the caller or user that an authentication failure has
   occurred and that the previously returned or output data shouldn't be
   used.  Finally, any data-formatting problem, such as obviously
   truncated data or missing trailing data, should be treated as a MAC
   verification failure even if the rest of the data was processed

It seems to me that we can take this advice at the protocol layer and
largely avoid the security concerns.  We just always use small

> If you want to do it right, you'd really want some formal academic treatment
> rather than guessing at chunk sizes and what may or may not be needed, i.e.
> typical message size X, typical chunk size Y gives these security bounds.  PGP
> is typically used to encrypt data at rest (make the chunk size the file size)
> or short email messages (chunk size doesn't matter, it's short).  That leaves
> a remainder of large emails, which we know exist but don't know how frequent
> they are or how often they're sent or from what sorts of systems.

I'm having trouble imagining why a larger chunk size would ever be
better in either of these cases.

  - File encryption: smaller chunk size means finding errors faster

  - Large emails: smaller chunk size means that it is possible to
    preview the email, which is helpful on mobile connections.

Please help me understand when a large chunk size could be better.


:) Neal