Re: [openpgp] AEAD Chunk Size - Performance

"Neal H. Walfield" <> Fri, 01 March 2019 08:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8095512E7C1 for <>; Fri, 1 Mar 2019 00:58:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EnR3DuPmFH0x for <>; Fri, 1 Mar 2019 00:58:32 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6E54112D84D for <>; Fri, 1 Mar 2019 00:58:32 -0800 (PST)
Received: from [] ( by with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from <>) id 1gzdzy-00059y-0H; Fri, 01 Mar 2019 08:58:30 +0000
Date: Fri, 01 Mar 2019 09:58:28 +0100
Message-ID: <>
From: "Neal H. Walfield" <>
To: Bart Butler <>
Cc: "" <>, Vincent Breitmoser <>
In-Reply-To: <>
References: <> <> <> <> <>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Archived-At: <>
Subject: Re: [openpgp] AEAD Chunk Size - Performance
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 08:58:35 -0000

At Thu, 28 Feb 2019 19:11:06 +0000,
Bart Butler wrote:
> "Re. Neal's request, I didn't have the numbers anymore, so I unscientifically created some new ones
> It looks like either Chrome or we have actually fixed the performance issues there with c=8 since the last time I tested it, as for most message sizes the performance is the same as c=12 or even a bit faster, except 128KB-256KB, which fits in one chunk with c=12 and there c=8 is about 1.1x - 1.5x slower.
> In Firefox, for >=64KB messages, c=8 is still about 1.5x - 2.5x slower than c=12, however, it looks like most of the overhead of smaller chunks comes from the streams polyfill, not the web crypto API. So that should probably be possible for us to fix."

Thanks for providing these numbers!  It's particularly interesting to
hear how the performance has changed over time.

> I see your logic on 16 kiB but in particular for file encryption I think there's some value to being able to go bigger in the future (L2 cache sizes have changed in the last 20 years as well and will probably change in the next two decades), and to keep the size byte to be able to configure this rather than have an entirely new packet. I think a SHOULD for 16 kiB though is totally appropriate now though for the reasons you mentioned.

Although I have a slight preference for 16 kiB due to performance
concerns, my first priority is security.  I'd like, at the minimum, a
hard ceiling, but I'd prefer no chunk size parameter at all.  I
appreciate backwards compatibility, and I'm willing to go with
renaming "chunk size" to "magic value" and fixing that to the C
corresponding to 256 kiB chunks.