Re: [openpgp] AEAD Chunk Size

Bart Butler <bartbutler@protonmail.com> Thu, 28 February 2019 19:28 UTC

Return-Path: <bartbutler@protonmail.com>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68BE6130EFE for <openpgp@ietfa.amsl.com>; Thu, 28 Feb 2019 11:28:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVwIKCWkM04H for <openpgp@ietfa.amsl.com>; Thu, 28 Feb 2019 11:28:44 -0800 (PST)
Received: from mail1.protonmail.ch (mail1.protonmail.ch [185.70.40.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C1FE130EE0 for <openpgp@ietf.org>; Thu, 28 Feb 2019 11:28:44 -0800 (PST)
Date: Thu, 28 Feb 2019 19:28:36 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1551382122; bh=rCrPo3OOoSwcIoE0PtuxwRmV8MZinhkNrLSQYw6lFi8=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=NjsOSSBwb6p7XRQwxGyjujz0wA2GqSyIe7AtjWLidlyuC3myBWF0K87Psfup2/Woa vj0wZgoXr16QjMZP99qmkvorniyq28LbUK1tBVy8AO7i0MCAL6wetnxn9TgUXQuD/W shLhfMqCBgQX1jUJo0BsalkRnLUflOBsr6cl38jY=
To: Jon Callas <joncallas@icloud.com>
From: Bart Butler <bartbutler@protonmail.com>
Cc: "Neal H. Walfield" <neal@walfield.org>, Jon Callas <joncallas=40icloud.com@dmarc.ietf.org>, "openpgp@ietf.org" <openpgp@ietf.org>, Vincent Breitmoser <look@my.amazin.horse>
Reply-To: Bart Butler <bartbutler@protonmail.com>
Message-ID: <sk-dPZjsiNBsTcliRrF0Y3myT9-gLOtkZ0Ps5BfSwOUSGrgHNPrR7kpuYALVEm6X3y6zAPpwowht_vp2nwJ3N4wTJP7X0EK-iCTuKq7qkuU=@protonmail.com>
In-Reply-To: <35C892F7-18A8-401E-828D-5CE180A3A731@icloud.com>
References: <87mumh33nc.wl-neal@walfield.org> <F9VLV9HZWH.3RYL3UM3BN873@my.amazin.horse> <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com> <CAB941EE-6961-4CAB-9632-DFF738980467@icloud.com> <87h8co2t4v.wl-neal@walfield.org> <35C892F7-18A8-401E-828D-5CE180A3A731@icloud.com>
Feedback-ID: XShtE-_o2KLy9dSshc6ANALRnvTQ9U24aqXW2ympbGschdpHbU6GYCTUCtfmGhY9HmOyP1Uweyandwh1AVDFrQ==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="---------------------20688ecde6120e430aaeee8dd61404a4"; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/JIbLLcHvCk2MaWDVeNrE9JLCnKU>
Subject: Re: [openpgp] AEAD Chunk Size
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Feb 2019 19:28:46 -0000

On Thursday, February 28, 2019 10:39 AM, Jon Callas <joncallas@icloud.com> wrote:

> 

> 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.
> 

> Does this make more sense?
> 

> Jon

What do you think about this? I made the last sentence a bit scarier and introduces the lower recommendation as well:

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. Small chunk sizes may introduce unnecessary overhead in decryption. In general, the chunk size is irrelevant to any code outside of the chunk handling code.
 

An implementation SHOULD pick a chunk size between 16KiB and 256KiB (c between 8 and 12). An implementation SHOULD refuse to process chunks outside this size range in federated or untrusted contexts.