Re: [openpgp] AEAD Chunk Size

Jon Callas <> Fri, 29 March 2019 02:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C0ABE1200EA for <>; Thu, 28 Mar 2019 19:19:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.85
X-Spam-Status: No, score=-1.85 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, KHOP_DYNAMIC=0.85, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xtvLrXv8t9NS for <>; Thu, 28 Mar 2019 19:19:43 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DD84812001A for <>; Thu, 28 Mar 2019 19:19:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=04042017; t=1553825982; bh=7bzuQxAeNddbxdLtvjLclOo5se2q7S0Um+j1uuDo5Mk=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=T62depTQlOR/T2i1p2g/Ep7/9fko1B6xKDy2oCDlAMLdHMw/WZIpBZNoT0aji4RWS AIdOOQkA6PzPEDoFpeirjfFFGhxBSvAaNR7orYC2dF2W3glAftqmCQP6a2D7T3I9Im nto4sKM4ZJHWbinl5B7tbsp8PGVMaWZ89f+HmX73beTZIFywlTfsFS1McTG5h7JI/2 eHSnDp4R9DxUt+BL7RKA8j4B6bxMTVv0SNtLUZEvTXDDXzjKFAwg2n+4KHMR0/gXO7 ccM3zUVfcaIsMctiQdAfxlg5KMiQi71ED7HKJ+0P65cy8Xp97MOF/mvzyT+eztX6FD FMq+jj0A7FvFQ==
Received: from [] ( []) by (Postfix) with ESMTPSA id 8DB40C013C; Fri, 29 Mar 2019 02:19:41 +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: Thu, 28 Mar 2019 19:19:39 -0700
Cc: Jon Callas <>, Jon Callas <>, Justus Winter <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: "Neal H. Walfield" <>
X-Mailer: Apple Mail (2.3445.102.3)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-29_02:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1903290016
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 02:19:46 -0000

I wrote a point-by-point reply and decided that that’s not productive. I’m going to try to cut to the chase on this, so forgive me if I have dodged an important point. I’m happy to come back to it later.

Like some interim replies, particularly Bart Butler, I thought we had a rough consensus and that it was approximately:

* MUST support 16KB chunks.
* SHOULD support 256K chunks, as these are common (Protonmail).
* MAY support larger up to the present very large size.
* MAY reject or error out on chunks larger than 16KB, but repeating ourselves, SHOULD support 256K.

I think it’s also reasonable to just simplify it by making be MUST support up to 256K. I don’t like getting rid of the SHOULD clause, thus making it be either 16K or off in squishy land, but I wouldn’t wring my wrists, I’d merely be a bit unhappy.

I could also get behind a hard limit of 2^30 on the grounds that that’s what we had for partial body lengths, but I understand the comment that there are things like multi-terabyte S3 buckets and out and out forbidding those to be single-chunk is a bit churlish, but only a bit.

If we really want to tie a bow around everything, then define some notation or other marker so that an implementation can mark in a key what the max chunk size is.

How’s that?

Now with some other points, I found myself going especially Socratic because the missives that you and Justus wrote weren’t *actionable*. When I was editor, a thing I would say from time to time is at about 90% of the time someone would say, “Please change X to Y for reason Z” it would be a no-brainer to do so. Most of the remaining 10% would end up with some reasonable debate than then an answer. But if someone said, “I think X is wrong” then 90% of the time nothing would happen because there’s nothing actionable there, meaning that there’s no clear point for the editor to be doing. All of these standards are at some level compromises and there’s an old aphorism that the best compromise is one where everyone is equally unhappy.

In my particular case, I thought I mostly agreed with where you wanted to go, but I completely disagreed with some of your premises, and disagreed with some of the reasoning that got us to the conclusion I agreed with. That’s why I was being so Socratic. I thought before the missives today that we had a rough consensus and that I agreed with y’all at some basic level. Then I thought we really disagreed, and I gradually realized that we agree on the destination, but not on the path of how to get there.

If I may give some advice, it is better to make sure that your requests are actionable. If they’re not, then you’re less likely to get what you want, if for no other reason than the rest of us don’t know what you want, we’re having to guess. The basic argument that you were making — that implementations such as yours need tight constraints — is one we all can get behind. The other side here — they want to do something kinda wacky (like terabyte chunks) — can be pushed off into the land of MAYs. 

Okay, anyway.

How’s that proposal I wrote above? Does it work for you? Does it need tweaks?