Re: [openpgp] AEAD Chunk Size

Tobias Mueller <> Tue, 26 March 2019 17:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5880B120419 for <>; Tue, 26 Mar 2019 10:40:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lB7nTSijMyfP for <>; Tue, 26 Mar 2019 10:40:41 -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 120681206D2 for <>; Tue, 26 Mar 2019 10:40:40 -0700 (PDT)
Received: from unibox ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id 44TJLs2PyGz13LHy; Tue, 26 Mar 2019 18:40:37 +0100 (CET)
Message-ID: <>
From: Tobias Mueller <>
To: "Neal H. Walfield" <>
Date: Tue, 26 Mar 2019 18:40:35 +0100
In-Reply-To: <>
References: <r480Ps-10143i-149CE78B9B3A43A29B3D767B6660A08D@Williams-MacBook-Pro.local> <> <> <> <>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
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: Tue, 26 Mar 2019 17:40:45 -0000

Hi Neal,

On Tue, 2019-03-19 at 11:09 +0100, Neal H. Walfield wrote:
> Can you please explain
> how the MDC helps protect against ciphertext modification in the
> streaming case, as that it still not clear to me.
RFC 4880 currently states in § 5.13:

    Any failure of the MDC indicates that the message has been modified
    and MUST be treated as a security problem. 
Further down in the security section (§ 14):

    An implementation MUST treat an
    MDC failure as a security problem, not merely a data problem [...]

    Consequently, it is important that:

     1. Implementers treat MDC errors and decompression failures as
        security problems.

There the MDC, if the spec is followed, indicates a security problem. I
guess that conversely, applications using OpenPGP thus ought to exercise
care when using that data which was flagged as having a security
problem.  So that's how the MDC protects against modification of the
Is that clear to you now?

Obviously, that didn't prevent consumers from ignoring that reported
security problem. But the spec cautions the use of the unauthenticated
data.  That's arguably too weak and it should probably say to not use unauthenticated data at all.  And implementations probably shouldn't have released plaintext early.  Or, if the application really needs to access early plaintext, because, say, it's running out of buffering capacity, then it needs to be able to deal with the fact that the data may turn out to be bad.
AFAIU, the MDC itself is not the most elegant or efficient construction,
but works just about well enough to detect modified ciphertext.

As an aside which you all of you are probably aware of: The other,
bigger, problem with SEIP packets is that they it can be downgraded [1]
which then, AFAIU, served as a another motivation to move to AEAD [2].

While "authenticated prefixes" (if used correctly) would render certain
ciphertext modifications powerless, they still leave an application
susceptible to attacks if it is not prepared to defend against them. 
Spontaneous examples that I can come up with are the script in the
backup that does "cp /foo /bar" where the attacker manages to cut off
the "bar" and causes havoc or a PDF with multiple xref tables where the
attacker manages the remove the last one. I'm sure there are more and
better examples.  I appreciate that the bar is higher for an attacker to
mount this attack if you can only cut off at the end rather than modify
anything at free will.

At the end of the day, though, the application layer has to be able to
defend against such an attack.  Now the question becomes whether
applications using OpenPGP are in such a position.  Assuming that most
of them are would make things easy, but may be a bit far fetched.  Yet,
forcing streaming onto every user and encouraging the release of
plaintext while the whole message has not yet been authenticated seems
to make that assumption.  I thus dislike the proposed removal of the
option of not dividing a message into separately authenticated pieces.
I appreciate that the authenticated prefixes reduce the attack surface
of Efail style attacks when you really can't hold all of the message. 
But they don't prevent the root cause of those attacks. Not using
unauthenticated plaintext (or parts thereof) would.

To that end, I like Vincent's idea of moving the discussion towards
fixing a chunk size for chunked mode but leaving support for a non-
chunked mode.