Re: [openpgp] Deprecating compression support

Justus Winter <> Tue, 19 March 2019 15:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DCED81313CA for <>; Tue, 19 Mar 2019 08:21:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 HMU00danrvbn for <>; Tue, 19 Mar 2019 08:21:28 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5829B12872C for <>; Tue, 19 Mar 2019 08:21:28 -0700 (PDT)
Received: by with SMTP id w1so15701649wrp.2 for <>; Tue, 19 Mar 2019 08:21:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=bc8g5oJapB77UTm5eo1F2msSUHf+7/y2UCW1jB+3URc=; b=h8ktu44N2VfK16ftkdZS6af1qU6zYBsfbunN194RcRnXygrj44VEjNWX3t1VeTSQqH Ch1f98zTu58mUbkCUd1t70leZPSO7iowvszFYfUuaqp+pTzAIcUEFnKMnxGj2RofKZAw flnBghdgQ8Tv72Sj1sIPjzJb/2flmp9VYd45PRU23KZXeyeBQ0Diul2WfRZo5bQQNaaY uVCca9+LzNpYRCdnJMTuzWG97DdpvrHfN5U+yygQvbhpqpBeiKVMEA0+IAEM9++cnE1c tD0vSXcavEBhUXVgLjc9OBUAhL6D7mRUaGDVofINkpNWuXTxhWMier9Q/itQWKdHYnGF K4ig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=bc8g5oJapB77UTm5eo1F2msSUHf+7/y2UCW1jB+3URc=; b=biiU8MNmIih+vX8bdquhuUJ8rBfj3JyP8gzDm8XfMffKPDCbTZRSKM8AMcYlBbfWK0 Sdbsm/+MOaxJ1h9LMQ3z9gW9r5bIprXTvCKUYsxdKse5PWyIQ64XCB2JVIbBK+LTq3fZ DhySvvBuHHbRJdgRfCn/QF545KcTL1Nqhnl1bN7FWnMSI2MGJHnRODVkm4wxC3Eu4SvN vh50CUUwoaNpMV4xqSwb5sYK9kniEcRMeD8ZIDH942Jy+Jgq4UphM+uehEO6+tgGrCLJ tFXBaTKyqaRjj92jZby79lJ0qgeHjmc/HMNhlIuduBvHoRbMDEVXbzsJaJ/qZ1C/PkOZ 4Ipg==
X-Gm-Message-State: APjAAAX6xXyfigXc8eMgt7fMhNG/PgFbfst7EUEagxtv+usSyQg9wv1X MAzAnnZ6VGaBbXPqj1DTPBg=
X-Google-Smtp-Source: APXvYqzSUqiW6JErK0lGhsy70ZQZJe1MUx8v6AVT21Zp9P8l92j+jGr1ys92EEyRPYlJa54TwhJJyQ==
X-Received: by 2002:a5d:4606:: with SMTP id t6mr8854288wrq.43.1553008886943; Tue, 19 Mar 2019 08:21:26 -0700 (PDT)
Received: from localhost ( []) by with ESMTPSA id q24sm4691997wmq.5.2019. (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 19 Mar 2019 08:21:26 -0700 (PDT)
From: Justus Winter <>
To: Vincent Breitmoser <>, Andrey Jivsov <>
Cc:, Jon Callas <>
In-Reply-To: <>
References: <> <> <> <>
Date: Tue, 19 Mar 2019 16:21:24 +0100
Message-ID: <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Archived-At: <>
Subject: Re: [openpgp] Deprecating compression support
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, 19 Mar 2019 15:21:31 -0000

Vincent Breitmoser <> writes:

> Andrey Jivsov <> wrote:
>> I agree with deprecation at a reasonable pace. SHOULD looks right.
> I'm unsure why both Jon and you think we need a slower "reasonable pace", when
> we have not only one but two very sharp points to make this cut as clean as can
> be? Both AEAD and the v5 key format already break compatibility. Why pull
> something over the edge that we want to phase out anyways?

Agreed.  I prepared a patch:

Author: Justus Winter <>
Date:   Tue Mar 19 16:11:03 2019 +0100

    Deprecate compression support.
    Forbid compression if encrypting a message to version 5 keys, or if
    AEAD is used.  Discourage compression otherwise.  Drop the dubious
    paragraph about security benefits of compression.
      - Compression makes it impossible to reason about the size of a
        decrypted message, requiring the use of a streaming interface even
        for seemingly small messages, e.g. emails.  Experience has shown
        that downstream users struggle with the correct use of streaming
      - Compression allows the construction of quines.
      - Compression interacts badly with encryption, see e.g. CRIME,
        BREACH, and hiding of EFAIL-style CFB gadgets [0].
      - The downstream application is in a better position to decide whether
        and how to compress data that is then encrypted using OpenPGP.
      - Compression make the standard more complex, and enlarges the
        trusted computing base of implementations.
    0: Section 5.3 of

diff --git a/middle.mkd b/middle.mkd
index 44d1246..4f88eb2 100644
--- a/middle.mkd
+++ b/middle.mkd
@@ -129,21 +129,21 @@ and a public-key signature algorithm.  The sequence is as follows:
 ## Compression
-OpenPGP implementations SHOULD compress the message after applying the
-signature but before encryption.
+OpenPGP implementations MUST NOT compress the message if the list of
+recipients includes a version 5 key, or the message is encrypted using
+Otherwise, OpenPGP implementations SHOULD NOT compress the message
+after applying the signature but before encryption.
+For backwards compatibility, OpenPGP implementations MAY handle
+compressed data packets.
 If an implementation does not implement compression, its authors
 should be aware that most OpenPGP messages in the world are
 compressed.  Thus, it may even be wise for a space-constrained
 implementation to implement decompression, but not compression.
-Furthermore, compression has the added side effect that some types of
-attacks can be thwarted by the fact that slightly altered, compressed
-data rarely uncompresses without severe errors.  This is hardly
-rigorous, but it is operationally useful.  These attacks can be
-rigorously prevented by implementing and using Modification Detection
-Codes as described in sections following.
 ## Conversion to Radix-64
 OpenPGP's underlying native representation for encrypted messages,