Re: [openpgp] AEAD Chunk Size

"brian m. carlson" <> Fri, 01 March 2019 00:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A9D3A12DDA3 for <>; Thu, 28 Feb 2019 16:27:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (3072-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6J9zVnHIxW80 for <>; Thu, 28 Feb 2019 16:26:58 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B9FA412D4F3 for <>; Thu, 28 Feb 2019 16:26:58 -0800 (PST)
Received: from (unknown [IPv6:2001:470:b978:101:a4e9:9ba4:4fd2:4493]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 9F60C60429; Fri, 1 Mar 2019 00:26:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=default; t=1551399987; bh=uzlc1zF8C6fsHBr3l/LyPk0fbEgrkg0m2szQNTiOqN4=; h=Date:From:To:Cc:Subject:References:Content-Type: Content-Disposition:In-Reply-To:From:Reply-To:Subject:Date:To:CC: Resent-Date:Resent-From:Resent-To:Resent-Cc:In-Reply-To:References: Content-Type:Content-Disposition; b=DtNiWCLgEbItKAFkyD393o6H0Gn6WGUV24KFYvhhM50MGeKcKHlBCBIH5QySm9wIx ZFXLhAYaJ64FP9NqfBQoC1dVwlwHFdxQh2OQcZwbDFJnrpeqJ/pVAbCVKP8SnlgmQ4 Q/kJyontxi8W1qZUJRBsdCmmQvmsGTGLZrfFIqPv0CLx+xlpHo8QBtjOeV0PFP4huP rTpN3LwQHd1poNco2QXNKHBENR4thiL0EpejtVRSkxG/VkrEzLIAb75ueMGb83dDEx EvR+tMENFzaXzhwbtkx/PIo1c32T8m/UAUA6i7NEW+d51HNrvtmFAx8Tthsi8eSXOH 8A4eWbAfZM6I7cq01Sa7/QmC9A1QbjZT8dPmF2U9KaYvYUDnChMc3t5lz3vfL/hN0b peQuznbCAIQZHYluR7Rw/ir7GopfoNW2SHWSermU3aVrbX20Xzarylg+C3NAkm9e78 j1wfqVpVbGZKmeuQ1eHRqJhye0m4fWi7qTJ6PVIU7s/8t09zHvL
Date: Fri, 1 Mar 2019 00:26:22 +0000
From: "brian m. carlson" <>
To: Jon Callas <>
Cc: "Neal H. Walfield" <>, Bart Butler <>, "" <>, Vincent Breitmoser <>, Jon Callas <>
Message-ID: <>
References: <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="+ts6NCQ4mrNQIV8p"
Content-Disposition: inline
In-Reply-To: <>
X-Machine: Running on genre using GNU/Linux on x86_64 (Linux kernel 4.19.0-2-amd64)
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Scanned-By: MIMEDefang 2.79 on
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, 01 Mar 2019 00:27:01 -0000

On Thu, Feb 28, 2019 at 10:39:17AM -0800, Jon Callas wrote:
> The best way to deal with it in a standard is to have non-normative guidance. It is non-normative guidance that I was suggesting. Let me write an example bit of non-normative guidance below:
> - - - - -
> Implementations should pick a chunk size with care. Depending on the AEAD algorithm, large chunk sizes may limit the ability to process chunks, particularly with an AEAD algorithm that is not single-pass, and thus the system decrypting it must hold the entire chunk as it decrypts it. In general, the chunk size is irrelevant to any code outside of the chunk handling code, so smaller is better.
> An implementation SHOULD pick a chunk size of 256KiB or less. An implementation MAY use larger sizes, but this could limit interoperability with resource-limited systems and should be done with care.
> - - - - -
> I don’t think that’s perfect, but it’s okay as a first draft. I would completely support something like the text above. I’d support it if it said 16KiB too. I’ll also support hard limits, but my intuition is that that decision will come with frustration for someone else.

I think this is a good first start. However, I think we need to specify
some guidelines about what sizes are required for interoperability. I'm
happy to give people guidance, but if we state that chunk sizes up to
256 KiB (or whatever size we decide) are required to be supported, then
we let people decide whether performance or interoperability is more
important for their use case.

So I'd specify a sentence at the beginning of the second paragraph that
says, "An implementation MUST support chunk sizes up to 256 KiB."
brian m. carlson: Houston, Texas, US