Re: [openpgp] AEAD Chunk Size

Tobias Mueller <muelli@cryptobitch.de> Sun, 17 March 2019 20:00 UTC

Return-Path: <muelli@cryptobitch.de>
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 439D51311E2 for <openpgp@ietfa.amsl.com>; Sun, 17 Mar 2019 13:00:56 -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, 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 cLlDDwCKvsAe for <openpgp@ietfa.amsl.com>; Sun, 17 Mar 2019 13:00:54 -0700 (PDT)
Received: from bitbox.cryptobit.ch (cryptobit.ch [188.40.138.131]) (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 8F9611311E1 for <openpgp@ietf.org>; Sun, 17 Mar 2019 13:00:54 -0700 (PDT)
Received: from unibox.fritz.box (p5B0F5932.dip0.t-ipconnect.de [91.15.89.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.cryptobit.ch (Postfix) with ESMTPSA id 44Mqtr007Vz13Bb0; Sun, 17 Mar 2019 21:00:51 +0100 (CET)
Message-ID: <61e3fb9d194d0b47f21be8e176daa0b9b6c5d0a5.camel@cryptobitch.de>
From: Tobias Mueller <muelli@cryptobitch.de>
To: "Neal H. Walfield" <neal@walfield.org>, Derek Atkins <derek@ihtfp.com>
Cc: Werner Koch <wk@gnupg.org>, openpgp@ietf.org, Vincent Breitmoser <look@my.amazin.horse>
Date: Sun, 17 Mar 2019 21:00:51 +0100
In-Reply-To: <87lg1gwelf.wl-neal@walfield.org>
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> <0f7f492bf18145f96e70886ba19ba290.squirrel@mail2.ihtfp.org> <87lg1gwelf.wl-neal@walfield.org>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/WQWj7FtEMKocwRCsKymtfsCbRmA>
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: Sun, 17 Mar 2019 20:00:56 -0000

Hi,

On Fri, 2019-03-15 at 12:40 +0100, Neal H. Walfield wrote:
> I'm currently convinced that streaming authenticated plaintext is only
> possible if we use small chunk sizes.  If we allow large chunk sizes
> (e.g., 4 exabytes, which is what the current draft allows), then there
> will be cases where an implementation can stream unauthenticated
> plaintext, but not authenticated data, and, because it can, it will.
> And this is even though pretty much everyone including the IETF (see
> RFC 5116 [1]) agrees that AEAD must only emit authenticated plaintext.
> 
>   [1] https://tools.ietf.org/html/rfc5116#section-2.2
Maybe we're hitting a terminology issue here.
For me, a plaintext is authenticated if the whole ciphertext could be
successfully authenticated. Which seems to be very well in line with the
definition you've linked to.
Now, if you modify a (long) ciphertext that has been broken into chunks
near the end and a decryption routine reveals the first parts of the
decrypted ciphertext, would you agree that revealing those parts of the
plaintext does not meet the definition that you've linked to?
And do you further agree that you would need to find a way to prevent
any plaintext to be revealed unless the full message has been
authenticated correctly in order to match the definition that you've
mentioned?

Cheers,
  Tobi