Re: [openpgp] AEAD Chunk Size

Jon Callas <> Wed, 27 February 2019 22:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B8DEA1311A4 for <>; Wed, 27 Feb 2019 14:37:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id um1zrF-pbWDq for <>; Wed, 27 Feb 2019 14:37:22 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EE95C1311A3 for <>; Wed, 27 Feb 2019 14:37:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=04042017; t=1551307041; bh=AWoaPfUcSrMuZyLmnoxWh74zZ3I9z8gB1mt9BaPI9O0=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=gOteEXmrOxkVUcboxRpAaUV+DBTxqj6ydrJtB4U1xvz+PiHKGZLTUkbV8Lqnoo8Pz cdEk5ZRUZ/3xQ0iJSik0o5ruSa1wEWZyrHN/qzOPVbiZupMlv0TeHWwNvr9gDECLZ/ l9rcuyfthiiMfQAoVoguT5JASj5RgLvk9HrjWy3s8rWl6o49qLBTQfel0UlxO2qLYD Mgo0eLMr4BJ36vJvwPGH0KSgWUOeqe39HdA/eDizHuNpAviR5QmV6BMK8JWXX8Yjly 41beXpZCKbfJzQN/IFpHuK8J+pl64ZpbM+EhcY5LhEawQVH+EIAG/E0OwapIgfI6yQ qD24gF4i7RB+g==
Received: from [] ( []) by (Postfix) with ESMTPSA id 2B63C7200E7; Wed, 27 Feb 2019 22:37:21 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Jon Callas <>
In-Reply-To: <>
Date: Wed, 27 Feb 2019 14:37:20 -0800
Cc: Jon Callas <>, Vincent Breitmoser <>, "" <>, "Neal H. Walfield" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Bart Butler <>
X-Mailer: Apple Mail (2.3445.102.3)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-27_15:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1902270147
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, 27 Feb 2019 22:37:24 -0000

> On Feb 27, 2019, at 1:34 PM, Bart Butler <> wrote:
> Hi all,
> We (Sunny Rajan and I) definitely agree with reducing the range of allowed sizes, because both 4 exabyte chunks and large messages composed of 64-byte chunks are clearly not optimal.
> In our AEAD implementation for OpenPGP.js we settled on a default `c` of 12 rather than 8 after some performance benchmarking showed that 256 kiB chunks were more performant for the most common message sizes. Our result was specific to the web crypto API, and therefore specific to OpenPGP.js, but in general libraries may want to use different default sizes depending on implementation details like this.
> So ideally we’d prefer to keep the size byte, but to shrink its range in both directions. For example, the RFC could state that the chunk SHOULD be 16 kiB (or 256 kiB, hint hint), but decryption MUST be available for `c` values between 8-12 inclusive. This would also allow us to be backwards-compatible with messages that have already been created following the current version of the draft, which do exist given the benefit that AEAD provides and that OpenPGP.js has supported the current draft in experimental mode for most of the last year. 

I think this is a reasonable way to have it to put an upper limit with a SHOULD.

I believe that if we limit it to 16K, we *will* regret that, for performance or other reasons. And while some of the upper sizes are presently absurdly large, one never knows what happens a couple decades from now. 

Moreover, forbidding it says that we state now that no one could ever have a reasonable use; my experience is that categorical statements like that are just asking the fates to bite us in an uncomfortable place. Amazon S3 increased their max object size to 5TB a few years ago. I’m not saying it should be that large, but I think this is a pretty convincing argument that 16K is too small.

So I think that a SHOULD is the right way to put it. I care less about what the SHOULD limit should be, but a small hard limit sounds like a bad idea.