Re: [openpgp] AEAD Chunk Size

Derek Atkins <> Wed, 20 March 2019 13:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 791D7127B50 for <>; Wed, 20 Mar 2019 06:24:35 -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 D1xy5jIUz0TB for <>; Wed, 20 Mar 2019 06:24:33 -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 7FEC0127963 for <>; Wed, 20 Mar 2019 06:24:33 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 28F41E2044; Wed, 20 Mar 2019 09:24:31 -0400 (EDT)
Received: from ([]) by localhost ( []) (amavisd-maia, port 10024) with ESMTP id 20162-10; Wed, 20 Mar 2019 09:24:30 -0400 (EDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "", Issuer "IHTFP Consulting Certification Authority" (not verified)) by (Postfix) with ESMTPS id 22F4CE2040; Wed, 20 Mar 2019 09:24:30 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1553088270; bh=h4lAfCNHwyJLm+nabDjB560d+RvQG7CBDRO6YRoQi7c=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=PtmUykKvm52w/w+YK4s7w3i4yrkNLEYn8EkdlX9fR9JjFkmBpZZ4MDH7E8UkUghcB QKu7dWoKMevJrwuPvL+V4HvHbLW8wudqnY7AT7H5lOi0JgyX6rq8+zA9MWLrab6XER GBBzkzjeXBRTanUqZ2XiA0/Csa+ZZIjC1BZcDnoo=
Received: (from warlord@localhost) by (8.15.2/8.15.2/Submit) id x2KDONBY008937; Wed, 20 Mar 2019 09:24:23 -0400
From: Derek Atkins <>
To: "Neal H. Walfield" <>
Cc:, Vincent Breitmoser <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Wed, 20 Mar 2019 09:24:22 -0400
In-Reply-To: <> (Neal H. Walfield's message of "Tue, 19 Mar 2019 19:10:18 +0100")
Message-ID: <>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
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: Wed, 20 Mar 2019 13:24:36 -0000


"Neal H. Walfield" <> writes:

> Hi Derek,
> Thanks for your analysis.  I think the AEAD chunking algorithm is
> sound, if it is used correctly.
> My issue is that I don't think it is possible to use the chunking
> algorithm correctly for large chunk sizes.  For instance, what should
> an implementation do if it encounters a chunk size of 16 TB (and there
> really can be >16 TB of data using a small decompression bomb)?
> Should it be allowed to emit unauthenticated plaintext?

Aha, and we have come around full circle again.

The chunk size needs to be small enough that the receiver can process
it.  If it's too big, then it cannot be processed and the receiver
either must buffer it or will decide to release the plaintext prior to
the chunk being completed.

> So, my conclusion is, we must prohibit implementations from emitting
> unauthenticated plaintext *and* remove any incentives to do so.  For
> me, this means a small, fixed chunk size.

There is no way to prohibit the implementation from emitting
unauthenticated plaintext.  Implementations will do what they want/need
to do.

I still don't think we need a fixed chunk size.  Different use cases may
dictate different ideas.  It's a tradeoff, of course.  The hope would be
the receiver can signal to the sender what it should do.

I DO believe that recommended chunk sizes should be smaller than, say
4TB (let alone exabytes).  I am happy to have the range be anywhere from
1KB to 128MB (give or take), but I still don't think we should outright
prohibit smaller or larger.  Considering the chunk size should be part
of the protected data, I don't see how an attacker could modify it, only
a sender that doesn't pay attention.

Specifically, if the sender and receiver have some out-of-band knowledge
about each other I still think it's perfectly reasonable for them to
make their own choices.

> Does this clarify my concerns?

I think so, and we ARE on the same page, I think.

> Thanks!
> :) Neal

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