Re: [openpgp] AEAD Chunk Size

Peter Gutmann <> Fri, 29 March 2019 13:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 08AEA12036B for <>; Fri, 29 Mar 2019 06:43:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RAZXLP112a-D for <>; Fri, 29 Mar 2019 06:43:40 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 744C1120254 for <>; Fri, 29 Mar 2019 06:43:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=mail; t=1553867019; x=1585403019; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TU78U/Fchkjnddw4xuxdSe0aXkjkLrDlxXH9daOZAPc=; b=hYuXIpcA41EqNfVdAlYCyS/QJv2QgZWlGkb3wZQb2Fteva8ZrnQwSWm8 RaEKES60yKTLfj5h/8yRPd6sWyVJVEq2GXdcHJUM6leTRXWZs8jCHpna9 ADQfena+q4HlajyapNOHvWBUK0uu1r4gmcLFGlmzO21yl9zei2D22o9/L YgvA5gqZCw96uT0EjxmwKnFqBGR9kuJOnUfMVB9TWC11OZPgGSTzL5KY0 1ra4gtbJR38U4W1u15ucIDZMxRRcaAJkGX0FP8g5ZLyQs5Jjoywd8f3GM wkNGnb3sA1IJsHLEF0cPGJhDDIViMTzNAIP0UI0bBZu9eNcHJ2N1xYaX2 Q==;
X-IronPort-AV: E=Sophos;i="5.60,284,1549882800"; d="scan'208";a="53656676"
X-Ironport-Source: - Outgoing - Outgoing
Received: from ([]) by with ESMTP/TLS/AES256-SHA; 30 Mar 2019 02:43:36 +1300
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 30 Mar 2019 02:43:36 +1300
Received: from ([]) by ([]) with mapi id 15.00.1395.000; Sat, 30 Mar 2019 02:43:36 +1300
From: Peter Gutmann <>
To: "Neal H. Walfield" <>
CC: "" <>, Justus Winter <>, Jon Callas <>, Jon Callas <>
Thread-Topic: [openpgp] AEAD Chunk Size
Date: Fri, 29 Mar 2019 13:43:35 +0000
Message-ID: <>
References: <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [openpgp] AEAD Chunk Size
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 29 Mar 2019 13:43:49 -0000

Neal H. Walfield <> writes:

>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.

There is a significant cost in terms of implementing, debugging, and interop-
testing every implementation that wants to do this.  If no-one cares about
auth protection of data at rest, and in the complete absence of real-world
data I'm going to claim no-one does because you can't prove otherwise, using
what we currently have has zero cost because it's already implemented.  Adding
blocked auth protection has a distinctly nonzero cost.

>Efail occured.  Why is that not enough?

That was due to broken email apps.  If I can convince your email app to
forward the plaintext of a decrypted message to me, you lose no matter what
encryption mechanism you use.

Admittedly CBC/CFB made this easier, but it was the email apps that needed
fixing, not PGP.

I'm not saying it's not worth addressing, but before endlessly debating
solutions we need to figure out what problem we're solving.  "We have this
cool AEAD mode lying around and want to apply it to something" isn't a
problem, or at least not a problem that a PGP user cares about solving, it's
something interesting for geeks to play with.

In the last five years or so I've received approximately zero PGP-encrypted
emails, and I'm one of the people who helped write the thing.  OTOH I've
probably encrypted gigabytes of data with it, almost always symmetric-key with
the key communicated out of band.  In none of those cases would blocked auth
protection have been useful.