Re: [openpgp] AEAD Chunk Size

"Neal H. Walfield" <neal@walfield.org> Mon, 18 March 2019 08:23 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 E5C8F128B77 for <openpgp@ietfa.amsl.com>; Mon, 18 Mar 2019 01:23:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POPjPyiB0fv0 for <openpgp@ietfa.amsl.com>; Mon, 18 Mar 2019 01:23:41 -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 8F2E112796D for <openpgp@ietf.org>; Mon, 18 Mar 2019 01:23:41 -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 1h5nYY-0002Lf-K3; Mon, 18 Mar 2019 08:23:38 +0000
Date: Mon, 18 Mar 2019 09:23:37 +0100
Message-ID: <87va0gioae.wl-neal@walfield.org>
From: "Neal H. Walfield" <neal@walfield.org>
To: "Neal H. Walfield" <neal@walfield.org>, Derek Atkins <derek@ihtfp.com>, openpgp@ietf.org, Vincent Breitmoser <look@my.amazin.horse>
In-Reply-To: <87va0g65ht.fsf@wheatstone.g10code.de>
References: <87d0n174w6.fsf@wheatstone.g10code.de> <87mumh33nc.wl-neal@walfield.org> <3GFS71V7BTJNZ.29C5TO8OY0O44@my.amazin.horse> <sjmy35isypu.fsf@securerf.ihtfp.org> <87r2bax5u2.wl-neal@walfield.org> <sjmlg1hskdq.fsf@securerf.ihtfp.org> <87pnqtwot9.wl-neal@walfield.org> <87y35hy2i0.fsf@wheatstone.g10code.de> <87k1h0we7w.wl-neal@walfield.org> <87va0g65ht.fsf@wheatstone.g10code.de>
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/aE-_PWtq8K7qV12twAdE6pA4sw8>
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: Mon, 18 Mar 2019 08:23:44 -0000

Hi Werner,

On Mon, 18 Mar 2019 07:50:22 +0100,
Werner Koch wrote:
> On Fri, 15 Mar 2019 12:48, neal@walfield.org said:
> >> > Are you arguing like Werner that catching transmission errors is
> >> > enough and that we shouldn't bother with ciphertext integrity?
> >> 
> >> I never said this.
> >
> > I was referring to this:
> >
> >   On Fri, 01 Mar 2019 15:50:15 +0100,
> >   Werner Koch wrote:
> >   > Let me repeat it again: The chunking was introduced for just one
> >   > purpose: To be able to detect rare transmission errors earlier than at
> >   > the end of the message.
> 
> Sorry, can you please explain how you can read out of this that I 
> said: "we shouldn't bother with ciphertext integrity".

I'm extremely happy to hear that I've misunderstood your position, and
that our goals are actually aligned.

Can you please explain how to get ciphertext integrity when streaming?

To be clear: for me, truncation is an orthogonal issue; my primary
concern is how to ensure that no implementations ever release
plaintext derived from modified ciphertext.

If you think that the current proposal achieves this, I've presented a
few critiques in <87mum6ekbd.wl-neal@walfield.org>
(https://mailarchive.ietf.org/arch/msg/openpgp/WvaisWDd9WzoKXL1FyHDeZNtZ2U)

  1. If messages can't be decrypted, because a chunk won't fit in
     memory, but unauthenticated streaming would otherwise "work,"
     implementors will do the latter, because security must not get in
     the way of a user getting her job done.

  2. If unauthenticated streaming is allowed or tacitly encouraged, it
     will be done first, because the set of messages that
     unauthenticated streaming can decrypt is a superset of those that
     authenticated decryption can handle, and it will perhaps be done
     exclusively because introducing a second code path that, modulo
     security concerns, is functionally equivalent to the code path
     for unauthenticated streaming is extra work, and extra
     complexity, which developers will try to avoid.

  3. If implementations revert to unauthenticated streaming for large
     chunk sizes, an attacker can conduct an EFAIL-style attack by
     changing the chunk size.

Thanks!

:) Neal