Re: [openpgp] AEAD Chunk Size

"Neal H. Walfield" <> Mon, 18 March 2019 13:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E1996127988 for <>; Mon, 18 Mar 2019 06:50:25 -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 r9q8EE-7fpa5 for <>; Mon, 18 Mar 2019 06:50:24 -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 D9CB6127598 for <>; Mon, 18 Mar 2019 06:50:23 -0700 (PDT)
Received: from ([] by with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from <>) id 1h5sei-0005jW-Rt; Mon, 18 Mar 2019 13:50:20 +0000
Date: Mon, 18 Mar 2019 14:50:20 +0100
Message-ID: <>
From: "Neal H. Walfield" <>
To: Vincent Breitmoser <>
Cc: Tobias Mueller <>,, Sebastian Schinzel <>
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 13:50:26 -0000

On Mon, 18 Mar 2019 13:23:07 +0100,
Vincent Breitmoser wrote:
> Ideally, a receiver won't ever output unauthenticated plaintext, hence ideally
> all of the chunking discussions would be moot. What chunking brings to the table
> is to give the *sender* of a message the option to *allow* the *receiver* to
> emit partially authenticated plaintext, trading a truncation vulnerability for
> the ability to process data on a smaller buffer size than the entire plaintext.
> This is useful for $large amounts of data, or streamed workflows with unknown
> data sizes.

When using chunking correctly, the emitted plaintext is not partially
authenticated; it is fully authenticated: all of the bytes are right.
As such, I'd prefer to use the term "authenticated prefix" in place of
"partially authenticated plaintext".

Some questions that come to mind:

  - Should an implementation ever be allowed to emit unauthenticated

    Is it okay to have a --do-it-anyway flag?  How to we prevent
    implementors from doing it anyways?

  - What should an implementation do if it is passed a large message
    (say n times the available RAM) and chunking is disabled?

    Should implementations be smart enough to detect that they can't
    process this apriori?  Should they wait for the OOM-killer?
    Should they panic?  High-level languages don't make it easy to
    recover from memory allocation failures.  For instance on Rust, an
    out of memory error results in a panic.  It would be a shame if
    the application crashed, or the sender could DoS the receiver.

It seems to me, if we are going to handle the complexity of chunking,
then we should just embrace it, and not make it even more complex.  If
an application wants to protect itself against truncation attacks,
then it can buffer the output, or the openpgp implementation can have
a flag.

> However, I can't see a good use case for variable size
> chunking: it adds complexity to spec and implementations in particular on the
> receiving side, and pushes the onus on reasoning about chunk sizes to the
> implementations, which is basically impossible in the face of interoperability
> concerns.

I fully agree with this.

> I'd like to bring up a new proposal then: Support either no chunking, or
> fixed-size chunking. The advantage would be that the sender's position on
> authentication is made more explicit: If they don't do chunking, they expect the
> receiver to fully buffer and authenticate before processing, which could
> currently only be achieved implicitly via a large chunk size. If they use the
> fixed-size chunking, they explicitly offer the option to emit partially
> authenticated plaintext.

I'm concerned about an attacker's ability to twiddle the chunking bit.
Do you have any thoughts on how to prevent this?