Re: [openpgp] AEAD Chunk Size

Jon Callas <> Fri, 29 March 2019 20:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E8FD3120356 for <>; Fri, 29 Mar 2019 13:49:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.849
X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, KHOP_DYNAMIC=0.85, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id we7gO5ZmaBB5 for <>; Fri, 29 Mar 2019 13:49:01 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C5052120366 for <>; Fri, 29 Mar 2019 13:49:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=04042017; t=1553892541; bh=fs6gred3Je7rUtRv8bGcTj+JBbMwY0m+gjIcQPczZFQ=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=vjzmRVJzNmPSNbb/Bh7TZnVPH6rCiZAJ9t7lNzzrId8MLF1mi0+ZOx8vXZ/FMYnNC WgKYNjtMFyqz6ViraMIn5rOEKXxuC6O3HaqmKHhUjdcEuIHoCYYcO1+8Fi9grh+ucQ I0A9Inm+FcqfrpkDf8rRLRepX6BNaHrLc5Z6Fom+Ck8WT4tjXge/j+VqLWwW4kLWKE uuGYU1hoffbDav88VZN2PuNz9X6FrzhyUXY7gYWwrmKxtLhVwzEiXbQIEMMEhTyPPd wdlt2LNYXuoH+KqRvW7v+aqWZOJwJ2wJBTOKhM//s9I1LbIdi6kNFrwcV9BHIieZ/w Qu1y4DtoPRMzg==
Received: from [] ( []) by (Postfix) with ESMTPSA id BF5809000DE; Fri, 29 Mar 2019 20:49:00 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Jon Callas <>
In-Reply-To: <>
Date: Fri, 29 Mar 2019 13:48:59 -0700
Cc: Jon Callas <>, Peter Gutmann <>, "" <>, Justus Winter <>, Jon Callas <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: "Neal H. Walfield" <>
X-Mailer: Apple Mail (2.3445.102.3)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-29_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=800 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1903290143
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 20:49:04 -0000

> On Mar 29, 2019, at 7:37 AM, Neal H. Walfield <> wrote:
> Ok.  Is your position that the working group should remove AEAD from
> 4880bis until there is an academic study proving people need it?

I think that if Peter wanted to remove AEAD, he’d just say that.

But no, the whole reason he and I and others are debating is that we think that AEAD in OpenPGP is a Good Idea.

>>> 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 see it differently.  I would say it was a combination of the email
> applications needing fixing and PGP needing fixing.

Before I go further, it’s OpenPGP. This working group is OpenPGP.

PGP is a software product owned by Symantec. It implements OpenPGP, as well as S/MIME, X.509, and a whole lot of other things.

> PGP encourages implementations to support streaming, and most do.
> But, using 4880, this means that an application may see plaintext from
> unauthenticated ciphertext.  Efail shows how that can be exploited by
> ***modifying the ciphertext*** (a PGP problem) to create a potential
> exfiltration channel.  Using chunked AEAD correctly, this type of
> attack is not possible: it is possible to stream, and only release
> plaintext from authenticated ciphertext.
> Now, applications could have protected themselves from this attack if
> they had backed out the message on MDC failure.  But, they didn't.
> And, I'd argue that a major reason that they didn't was because this
> type of attack is not well understood by application developers.
> Application developers understand truncation.  But, ciphertext
> modification is something that most have probably never heard of.
> Since we can protect application developers from ciphertext
> modification, I would argue that not doing so is negligent.
> So, if we are distributing blame, and I'd rather not play that game,
> then I'd place 90% of the blame on the WG and the PGP implementations,
> and only 10% on the mail application developers.

Then why does it work with S/MIME? Do they get 90% too?

That brings us up to 190% of the blame, which might be called for, given that it is a major cluster, but I think it’s orthogonal to what we’re talking about here.

How about if we just work on AEAD instead of debating Efail? Especially since we agree on AEAD being needed.