Re: [openpgp] AEAD Chunk Size

Tobias Mueller <muelli@cryptobitch.de> Sun, 17 March 2019 19:33 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 7E64C12D829 for <openpgp@ietfa.amsl.com>; Sun, 17 Mar 2019 12:33:16 -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] 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 Tc1TTMMZcW34 for <openpgp@ietfa.amsl.com>; Sun, 17 Mar 2019 12:33:14 -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 8487812B001 for <openpgp@ietf.org>; Sun, 17 Mar 2019 12:33:14 -0700 (PDT)
Received: from unibox (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 44MqGw08gnz13BZY; Sun, 17 Mar 2019 20:33:11 +0100 (CET)
Message-ID: <1f19ab4087fbcd92d085730e38617ab06f0e9954.camel@cryptobitch.de>
From: Tobias Mueller <muelli@cryptobitch.de>
To: Sebastian Schinzel <schinzel@fh-muenster.de>, openpgp@ietf.org
Date: Sun, 17 Mar 2019 20:33:11 +0100
In-Reply-To: <e66e0572-ea5e-c691-b188-25784a206e21@fh-muenster.de>
References: <87mumh33nc.wl-neal@walfield.org> <87d0n174w6.fsf@wheatstone.g10code.de> <e66e0572-ea5e-c691-b188-25784a206e21@fh-muenster.de>
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/RLTU2vF-GcmY9hX-HMlOJsR9CVM>
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 19:33:17 -0000

Hi,

On Wed, 2019-03-13 at 07:32 +0100, Sebastian Schinzel wrote:
> > Without sufficient storage a smaller chunk size does not help you in
> > any
> > way.  You can still run a truncation attack and by that time the
> > preceding chunks have already been processed in some way because,
> > well,
> > there was no way to store the entire message.  Without the final
> > chunk
> > you have an incomplete and thus unauthenticated message because the
> > sender authenticated the entire message and not certain parts of it.
> 
> Chosen ciphertext attacks and truncation attacks are two different
> attack classes, with different assumptions on the plaintext format and
> the necessary attacker capabilities.
> 
> Neal's proposal to mandate a small and fixed chunk size can solve
> ciphertext malleability for future OpenPGP applications. Waving this
> proposal off, just because it won't also solve truncation attacks,
> does not make sense.
I don't understand why you bring up malleability.

As far as I understand Werner, he is concerned with the proposal still
forcing clients to buffer the whole message if the implementation wants
to release authenticated data only. Which is how AE is defined. So
fixing any chunk size does not work.  But I may stand corrected.

Cheers,
  Tobi