IETF Logo Mail Archive

Re: [openpgp] AEAD Chunk Size

"Neal H. Walfield" <neal@walfield.org> Fri, 29 March 2019 13:20 UTC

Return-Path: <neal@walfield.org>
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 7AF79120279 for <openpgp@ietfa.amsl.com>; Fri, 29 Mar 2019 06:20:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 0LLitqt_NByq for <openpgp@ietfa.amsl.com>; Fri, 29 Mar 2019 06:20:24 -0700 (PDT)
Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70EB4120252 for <openpgp@ietf.org>; Fri, 29 Mar 2019 06:20:24 -0700 (PDT)
Received: from p57b22663.dip0.t-ipconnect.de ([87.178.38.99] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from <neal@walfield.org>) id 1h9rQj-0006gl-Kx; Fri, 29 Mar 2019 13:20:21 +0000
Date: Fri, 29 Mar 2019 14:20:21 +0100
Message-ID: <87d0m9hl62.wl-neal@walfield.org>
From: "Neal H. Walfield" <neal@walfield.org>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Cc: "openpgp@ietf.org" <openpgp@ietf.org>, Justus Winter <justuswinter@gmail.com>, Jon Callas <joncallas@icloud.com>, Jon Callas <joncallas=40icloud.com@dmarc.ietf.org>
In-Reply-To: <1553864014737.31739@cs.auckland.ac.nz>
References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> <E65F6E9D-8B0B-466D-936B-E8852F26E1FF@icloud.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (Gojō) 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: <https://mailarchive.ietf.org/arch/msg/openpgp/IMp2Hz4_htWusRvkpx-W2IEEXQk>
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: Fri, 29 Mar 2019 13:20:27 -0000

On Fri, 29 Mar 2019 13:53:42 +0100,
Peter Gutmann wrote:
> 
> Neal H. Walfield <neal@walfield.org> writes:
> 
> >I'm having trouble imagining why a larger chunk size would ever be better in
> >either of these cases.
> >
> >  - File encryption: smaller chunk size means finding errors faster
> 
> See my followup messages, for data at rest you probably don't care about
> errors at all, and if you really do then having the report at the whole-file
> level is fine.  What's the benefit gained from knowing that the 64kB block at
> offset xyz is corrupt?

But what is the cost?  I would say there is basically none.  So it
makes no sense to me to optimize for this case.  It's irrelevant.

So, why make the important case (when you actually do want to stream)
more complicated?

> As I mentioned earlier, we really need some data on real-world use cases
> rather than hypothesising problematic corner cases that will rarely, if ever,
> occur.

Efail occured.  Why is that not enough?

v2.23.0 | Report a Bug | By Email