Re: [openpgp] AEAD Chunk Size

"Derek Atkins" <> Mon, 18 March 2019 13:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B7D29127598 for <>; Mon, 18 Mar 2019 06:57:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ss_Kul5LqyJu for <>; Mon, 18 Mar 2019 06:57:41 -0700 (PDT)
Received: from (MAIL2.IHTFP.ORG []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3263D127970 for <>; Mon, 18 Mar 2019 06:57:41 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 96C85E2040; Mon, 18 Mar 2019 09:57:39 -0400 (EDT)
Received: from ([]) by localhost ( []) (amavisd-maia, port 10024) with ESMTP id 32594-05; Mon, 18 Mar 2019 09:57:38 -0400 (EDT)
Received: by (Postfix, from userid 48) id F2A78E2042; Mon, 18 Mar 2019 09:57:37 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1552917457; bh=hzvRMupgav/ErSnGE+Mbam4xvLAAWLIeMdU70glCyRs=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=psQqFIx7xuBMro8Qf/ki1FAYs0RnbwQjlTorschR7a8AlbFPmQNvvRdSGO5eBpgSm XFFEemEWnAUg/pdq6GeQMK9y3igshXIBLgzPSA8p2D32AresQGOmTfchbk12SNHNdI s1mH4IA5f4aC0Y4A3gzb6+fDDfgr8eoMU9FVBn7A=
Received: from (SquirrelMail authenticated user warlord) by with HTTP; Mon, 18 Mar 2019 09:57:37 -0400
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
Date: Mon, 18 Mar 2019 09:57:37 -0400
From: "Derek Atkins" <>
To: "Neal H. Walfield" <>
Cc: "Neal H. Walfield" <>, "Derek Atkins" <>,, "Vincent Breitmoser" <>
User-Agent: SquirrelMail/1.4.22-14.fc20
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: Maia Mailguard 1.0.2a
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:57:46 -0000

Hi Neal,

On Mon, March 18, 2019 4:23 am, Neal H. Walfield wrote:
> Hi Werner,
> Can you please explain how to get ciphertext integrity when streaming?
> To be clear: for me, truncation is an orthogonal issue; my primary
> concern is how to ensure that no implementations ever release
> plaintext derived from modified ciphertext.

With or without AEAD?

> If you think that the current proposal achieves this, I've presented a
> few critiques in <>
> (
>   1. If messages can't be decrypted, because a chunk won't fit in
>      memory, but unauthenticated streaming would otherwise "work,"
>      implementors will do the latter, because security must not get in
>      the way of a user getting her job done.
>   2. If unauthenticated streaming is allowed or tacitly encouraged, it
>      will be done first, because the set of messages that
>      unauthenticated streaming can decrypt is a superset of those that
>      authenticated decryption can handle, and it will perhaps be done
>      exclusively because introducing a second code path that, modulo
>      security concerns, is functionally equivalent to the code path
>      for unauthenticated streaming is extra work, and extra
>      complexity, which developers will try to avoid.
>   3. If implementations revert to unauthenticated streaming for large
>      chunk sizes, an attacker can conduct an EFAIL-style attack by
>      changing the chunk size.

Which implementation?  The sender or the receiver?  Also, who is the
attacker?  The Sender?  Or a third party?

Note that the way I see Chunking + AEAD working together is that there is
a 1:1 mapping of Chunk to AEAD block.  I realize this is probably a change
in the way it's currently working (and it's been 20 years since I wrote
the original chunking code), but I feel that AEAD and Chunking go
hand-in-hand.  Specifically, I see chunking as a way to splice a bunch of
separate AEAD blocks together into a chain to ensure you don't drop or
reorder the AEAD chunks.  The only attack is a DoS if the end is
truncated, and the earlier (valid) chunks have already been released.

In other words, AEAD is used for each chunked block as a single, coherent
piece.  Also I don't see how an attacker (third party) could leverage this
at all.  They couldn't change the chunk size enroute.  Granted, if the
attacker is the sender they could do much worse things, so you just need
to ensure that, as you say, unauthenticated plaintext isn't released.  But
that cannot happen given the context above.  Each chunk is either
authenticated, or an error occurs.  On error, it wouldn't be released.

Chunk sizes SHOULD be limited to ensure processing capability, which is
where this conversation started.  Of course, this assumes chunked mode. 
It should still be allowed to have a single AEAD "chunk" if the sender
wants to buffer the message.

> Thanks!
> :) Neal


       Derek Atkins                 617-623-3745   
       Computer and Internet Security Consultant