Re: [openpgp] AEAD Chunk Size
"Neal H. Walfield" <neal@walfield.org> Mon, 18 March 2019 10:53 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 69BDD131101 for <openpgp@ietfa.amsl.com>; Mon, 18 Mar 2019 03:53:21 -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 i3t2NGyMBZ9b for <openpgp@ietfa.amsl.com>; Mon, 18 Mar 2019 03:53:19 -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 DAEA3127963 for <openpgp@ietf.org>; Mon, 18 Mar 2019 03:53:18 -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 1h5ptL-0003tG-Fr; Mon, 18 Mar 2019 10:53:15 +0000
Date: Mon, 18 Mar 2019 11:53:14 +0100
Message-ID: <87sgvkihd1.wl-neal@walfield.org>
From: "Neal H. Walfield" <neal@walfield.org>
To: Tobias Mueller <muelli@cryptobitch.de>
Cc: Derek Atkins <derek@ihtfp.com>, Werner Koch <wk@gnupg.org>, openpgp@ietf.org, Vincent Breitmoser <look@my.amazin.horse>
In-Reply-To: <61e3fb9d194d0b47f21be8e176daa0b9b6c5d0a5.camel@cryptobitch.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> <0f7f492bf18145f96e70886ba19ba290.squirrel@mail2.ihtfp.org> <87lg1gwelf.wl-neal@walfield.org> <61e3fb9d194d0b47f21be8e176daa0b9b6c5d0a5.camel@cryptobitch.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/hKR734kH8rr_gkyI8worjNnsVFE>
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 10:53:22 -0000
Hi Tobias, On Sun, 17 Mar 2019 21:00:51 +0100, Tobias Mueller wrote: > 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. I think we do. > 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. 4880bis defines a chunking mechanism based on AEAD: the message is split into multiple chunks. In 4880bis, AEAD operates on a per-chunk basis. The chunking algorithm provides mechanisms for ensuring chunks can't be reordered, detecting the end of the message, etc. Using AEAD to decrypt a chunk authenticates that chunk's ciphertext; for a given chunk, the decryption operation will either return the correct plaintext, or it will return an error. This is exactly what RFC 5116 requires. RFC 5116 doesn't discuss chunking; chunking is not AEAD. The chunking mechanism in 4880bis (assuming implementors follow RFC 5116 with respect to AEAD on chunks) ensures that plaintext is only released from authenticated ciphertext. It does not protect against truncation attacks. Since OpenPGP decided to support streaming in RFC 2440 (which introduced One Pass Signature packets), this is inline with OpenPGP's philosophy. I don't think removing support for streaming is useful. You seem to think that AEAD's guarantees must apply to the whole message. I disagree. I agree it is useful, but it is not possible when streaming. I think that even if we add a bit that says: "don't stream", implementations will ignore it. Moreover an attacker can just clear it, and then the receiver streams it anyways. > 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? No. AEAD is applied to chunks. > 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? No. AEAD is applied to chunks. When a chunk is decrypted, it either returns authenticated plaintext, or an error. Referring to <734216a3ee1c0e252ecf0ad297be2cfdcb049c2e.camel@cryptobitch.de> On Sun, 17 Mar 2019 21:01:32 +0100, Tobias Mueller wrote: > On Thu, 2019-03-07 at 18:09 +0100, Neal H. Walfield wrote: > > You're afraid of bugs. So am I. Dynamically resizing buffers is > > error prone. Even computing AEAD's chunk size is hard: > point taken. Programming is hard. Programming C is even harder. Tooling > could be improved. We ought to write a spec that achieves a security > goal while making it less likely that people implement the spec wrongly. I agree. Less flexibility in the spec is better, which is what I want. You rightly argue, I think, that AEAD without chunking is easier to implement. But, OpenPGP supports streaming, which is incompatible with AEAD without chunking. Consequently, streaming using AEAD without chunking means releasing unauthenticated (as I have defined it above) plaintext. Releasing unauthenticated plaintext is much worse than releasing only an authenticated prefix. Releasing unauthenticated plaintext allows for an EFAIL style attack; releasing an authenticated prefix does not. Releasing an authenticated prefix prevents ciphertext malleability. > You've made a point but you haven't really taken a stance on the point > that I raised. Which boils down to your proposal forcing everybody to > use chunking which in turn can be implemented wrongly while providing no > benefit in return. Only releasing plaintext from authenticated chunks prevents EFAIL-style attacks. That is not no benefit, that is not a little benefit, that is a huge benefit. > I believe that the potential for releasing plaintext although the > ciphertext has not been authenticated is higher if I need to call that > oracle multiple times, invent a secure scheme for detecting truncation, > and implement that scheme correctly. I agree that the added complexity that chunking imposes is not worth it *if* the only reason to introduce chunking is to detect transmission errors early. But, it is not. It prevents modifications to the ciphertext. > Your proposal removes the option for the message producer to decide > whether it wants to have the recipient (which may very well be the same > entity) rely on an implementation which gets all that right. Because > with the status quo, one can opt for producing one chunk which is > trivially protected against truncation and other attacks. You say that it is trivially protected, but this is not the case, because exactly in those cases implementors will just stream unauthenticated data. They should only be able to stream data from authenticated chunks. > Unless I understand your proposal wrong. But then my question is, how > would I encode a message that is not susceptible to (at least) > truncation attacks? Again, assuming the above mentioned oracle. OpenPGP allows streaming. The implementation doesn't provide a mechanism to prevent streaming. I'm not sure it would be a good idea to provide one, as I don't think there is a sensible way for the sender to decide when to set that bit. > I don't fully understand why you are mentioning dynamically resizing > buffers. Strictly speaking, you need space for a single digit number of > blocks (!) to decrypt an EAX or OCB message. The size of the message is not known apriori if partial body length encoding is used. Even an upper bound is not known if compression is used.
- Re: [openpgp] AEAD Chunk Size Justus Winter
- [openpgp] AEAD Chunk Size Neal H. Walfield
- Re: [openpgp] AEAD Chunk Size Vincent Breitmoser
- Re: [openpgp] AEAD Chunk Size Bart Butler
- Re: [openpgp] AEAD Chunk Size Jon Callas
- Re: [openpgp] AEAD Chunk Size Bart Butler
- Re: [openpgp] AEAD Chunk Size Jon Callas
- Re: [openpgp] AEAD Chunk Size Ronald Tse
- Re: [openpgp] AEAD Chunk Size Ronald Tse
- Re: [openpgp] AEAD Chunk Size Bart Butler
- Re: [openpgp] AEAD Chunk Size Hanno Böck
- Re: [openpgp] AEAD Chunk Size - Performance Neal H. Walfield
- Re: [openpgp] AEAD Chunk Size Neal H. Walfield
- Re: [openpgp] AEAD Chunk Size Neal H. Walfield
- Re: [openpgp] AEAD Chunk Size Neal H. Walfield
- Re: [openpgp] AEAD Chunk Size Neal H. Walfield
- Re: [openpgp] AEAD Chunk Size Jon Callas
- Re: [openpgp] AEAD Chunk Size - Performance Bart Butler
- Re: [openpgp] AEAD Chunk Size Bart Butler
- Re: [openpgp] AEAD Chunk Size Bart Butler
- Re: [openpgp] AEAD Chunk Size brian m. carlson
- Re: [openpgp] AEAD Chunk Size Neal H. Walfield
- Re: [openpgp] AEAD Chunk Size - Performance Neal H. Walfield
- Re: [openpgp] AEAD Chunk Size Neal H. Walfield
- Re: [openpgp] AEAD Chunk Size Tobias Mueller
- Re: [openpgp] AEAD Chunk Size Sebastian Schinzel
- Re: [openpgp] AEAD Chunk Size Neal H. Walfield
- Re: [openpgp] AEAD Chunk Size Neal H. Walfield
- Re: [openpgp] AEAD Chunk Size Werner Koch
- Re: [openpgp] AEAD Chunk Size Vincent Breitmoser
- Re: [openpgp] AEAD Chunk Size Sebastian Schinzel
- Re: [openpgp] AEAD Chunk Size Derek Atkins
- Re: [openpgp] AEAD Chunk Size Neal H. Walfield
- Re: [openpgp] AEAD Chunk Size Derek Atkins
- Re: [openpgp] AEAD Chunk Size Neal H. Walfield
- Re: [openpgp] AEAD Chunk Size Werner Koch
- Re: [openpgp] AEAD Chunk Size Derek Atkins
- Re: [openpgp] AEAD Chunk Size Neal H. Walfield
- Re: [openpgp] AEAD Chunk Size Neal H. Walfield
- Re: [openpgp] AEAD Chunk Size Tobias Mueller
- Re: [openpgp] AEAD Chunk Size Tobias Mueller
- Re: [openpgp] AEAD Chunk Size Tobias Mueller
- Re: [openpgp] AEAD Chunk Size Tobias Mueller
- Re: [openpgp] AEAD Chunk Size Tobias Mueller
- Re: [openpgp] AEAD Chunk Size Werner Koch
- Re: [openpgp] AEAD Chunk Size Neal H. Walfield
- Re: [openpgp] AEAD Chunk Size Neal H. Walfield
- Re: [openpgp] AEAD Chunk Size Tobias Mueller
- Re: [openpgp] AEAD Chunk Size Tobias Mueller
- Re: [openpgp] AEAD Chunk Size Neal H. Walfield
- Re: [openpgp] AEAD Chunk Size Vincent Breitmoser
- Re: [openpgp] AEAD Chunk Size Peter Pentchev
- Re: [openpgp] AEAD Chunk Size Vincent Breitmoser
- Re: [openpgp] AEAD Chunk Size Neal H. Walfield
- Re: [openpgp] AEAD Chunk Size Derek Atkins
- Re: [openpgp] AEAD Chunk Size Vincent Breitmoser
- Re: [openpgp] AEAD Chunk Size Neal H. Walfield
- Re: [openpgp] AEAD Chunk Size Vincent Breitmoser
- Re: [openpgp] AEAD Chunk Size Tobias Mueller
- Re: [openpgp] AEAD Chunk Size Neal H. Walfield
- Re: [openpgp] AEAD Chunk Size Bill Frantz
- [openpgp] WTF (Re: AEAD Chunk Size) Andre Heinecke
- Re: [openpgp] AEAD Chunk Size Werner Koch
- Re: [openpgp] AEAD Chunk Size Neal H. Walfield
- Re: [openpgp] AEAD Chunk Size Werner Koch
- Re: [openpgp] AEAD Chunk Size Neal H. Walfield
- Re: [openpgp] AEAD Chunk Size Derek Atkins
- Re: [openpgp] AEAD Chunk Size Neal H. Walfield
- Re: [openpgp] AEAD Chunk Size Marcus Brinkmann
- Re: [openpgp] AEAD Chunk Size Nickolay Olshevsky
- Re: [openpgp] AEAD Chunk Size Derek Atkins
- Re: [openpgp] AEAD Chunk Size Tobias Mueller
- Re: [openpgp] AEAD Chunk Size Tobias Mueller
- Re: [openpgp] AEAD Chunk Size Derek Atkins
- Re: [openpgp] AEAD Chunk Size Neal H. Walfield
- Re: [openpgp] AEAD Chunk Size Bill Frantz
- Re: [openpgp] AEAD Chunk Size Jon Callas
- Re: [openpgp] AEAD Chunk Size Jon Callas
- Re: [openpgp] AEAD Chunk Size Neal H. Walfield
- Re: [openpgp] AEAD Chunk Size Bart Butler
- Re: [openpgp] AEAD Chunk Size Marcus Brinkmann
- Re: [openpgp] AEAD Chunk Size Bill Frantz
- Re: [openpgp] AEAD Chunk Size Jon Callas
- Re: [openpgp] AEAD Chunk Size Peter Gutmann
- Re: [openpgp] AEAD Chunk Size Peter Gutmann
- Re: [openpgp] AEAD Chunk Size Peter Gutmann
- Re: [openpgp] AEAD Chunk Size Peter Gutmann
- Re: [openpgp] AEAD Chunk Size Bill Frantz
- Re: [openpgp] AEAD Chunk Size Neal H. Walfield
- Re: [openpgp] AEAD Chunk Size Neal H. Walfield
- Re: [openpgp] AEAD Chunk Size Marcus Brinkmann
- Re: [openpgp] AEAD Chunk Size Marcus Brinkmann
- Re: [openpgp] AEAD Chunk Size Peter Gutmann
- Re: [openpgp] AEAD Chunk Size Neal H. Walfield
- Re: [openpgp] AEAD Chunk Size Peter Gutmann
- Re: [openpgp] AEAD Chunk Size Neal H. Walfield
- Re: [openpgp] AEAD Chunk Size Jon Callas
- Re: [openpgp] AEAD Chunk Size Wyllys Ingersoll
- Re: [openpgp] AEAD Chunk Size Jon Callas
- Re: [openpgp] AEAD Chunk Size Jon Callas
- Re: [openpgp] AEAD Chunk Size Jon Callas
- Re: [openpgp] AEAD Chunk Size brian m. carlson
- Re: [openpgp] AEAD Chunk Size Bart Butler
- Re: [openpgp] AEAD Chunk Size Benjamin Kaduk
- Re: [openpgp] AEAD Chunk Size Bart Butler
- Re: [openpgp] AEAD Chunk Size Benjamin Kaduk
- Re: [openpgp] AEAD Chunk Size Neal H. Walfield
- Re: [openpgp] AEAD Chunk Size Jon Callas
- Re: [openpgp] AEAD Chunk Size Peter Gutmann
- Re: [openpgp] AEAD Chunk Size Bart Butler
- Re: [openpgp] AEAD Chunk Size Benjamin Kaduk
- Re: [openpgp] AEAD Chunk Size Conrado P. L. Gouvêa
- Re: [openpgp] AEAD Chunk Size Conrado P. L. Gouvêa
- Re: [openpgp] AEAD Chunk Size Jon Callas
- Re: [openpgp] AEAD Chunk Size Neal H. Walfield
- Re: [openpgp] AEAD Chunk Size Neal H. Walfield
- Re: [openpgp] AEAD Chunk Size Derek Atkins
- Re: [openpgp] AEAD Chunk Size Neal H. Walfield
- Re: [openpgp] AEAD Chunk Size Derek Atkins
- Re: [openpgp] AEAD Chunk Size Derek Atkins
- Re: [openpgp] AEAD Chunk Size Jon Callas
- Re: [openpgp] AEAD Chunk Size Derek Atkins
- Re: [openpgp] AEAD Chunk Size Jon Callas
- Re: [openpgp] AEAD Chunk Size Heiko Stamer
- Re: [openpgp] AEAD Chunk Size Bart Butler
- Re: [openpgp] AEAD Chunk Size Bart Butler
- Re: [openpgp] AEAD Chunk Size Derek Atkins
- Re: [openpgp] AEAD Chunk Size Werner Koch
- Re: [openpgp] AEAD Chunk Size Benjamin Kaduk
- Re: [openpgp] [EXT] Re: AEAD Chunk Size Neil Hunsperger