Re: [openpgp] Deprecating compression support

Andre Heinecke <> Wed, 20 March 2019 14:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 61FE31295D8 for <>; Wed, 20 Mar 2019 07:54:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xeYgUxg-cbL6 for <>; Wed, 20 Mar 2019 07:54:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7A0171310FC for <>; Wed, 20 Mar 2019 07:54:01 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 406903ED45; Wed, 20 Mar 2019 15:54:00 +0100 (CET)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W_TxGO9BRNnC; Wed, 20 Mar 2019 15:53:59 +0100 (CET)
Received: from esus.localnet ( []) (Authenticated sender: by (Postfix) with ESMTPSA id 0723F3E8A9; Wed, 20 Mar 2019 15:53:58 +0100 (CET)
From: Andre Heinecke <>
Cc: Justus Winter <>
Date: Wed, 20 Mar 2019 15:53:58 +0100
Message-ID: <2181951.mQFCbn3PMz@esus>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1902347.Q2Mb2DpkOF"; 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: Wed, 20 Mar 2019 14:54:08 -0000


Vincent said that my mail was too rambling. I agree. Here is the short 

* Compression is good and necessary.
* Standardized compression is good.
* I don't want to use unstandardized compression only because you do not want 
to implement compression in sequoia.
* There is no reason the change the standard. Compression has been around for 
ages. It is _standard_ and working well.

Here is where annoyed rambling about unproductive suggestions starts:

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

Whose expericence? Not mine. It's OpenPGP and S/MIME. You have to handle this 
even if you don't like it. Compression does not change this.

> - Compression allows the construction of quines.

Yeah that sucks. But a downstream application would still be affected. e.g. a 
MUA or Kleopatra if you move compresssion out of the standard.

>  - Compression interacts badly with encryption, see e.g. CRIME,
>    BREACH, and hiding of EFAIL-style CFB gadgets [0].

*rolleyes* Was OpenPGP affected? Nope.

> - The downstream application is in a better position to decide whether
>    and how to compress data that is then encrypted using OpenPGP.

Nope. Because the downstream application does not know anything about the 
sending application because it is not standardized in you proposal.

  >- Compression make the standard more complex, and enlarges the
  >  trusted computing base of implementations.

Nope. Removing it makes handling it more complex because we are working with a 
well established standard. So you still need to handle old messages so you 
still need to handle compression. But Oh! Now you also have to handle non-
standard compression. Fun! Complexity -> Increase!


-- - a brand of g10 Code, the GnuPG experts.

g10 Code GmbH, Erkrath/Germany, AG Wuppertal HRB14459
GF Werner Koch, USt-Id DE215605608,

GnuPG e.V., Rochusstr. 44, D-40479 Düsseldorf.  VR 11482 Düsseldorf
Vorstand: W.Koch, M.Gollowitzer, A.Heinecke.    Mail:
Finanzamt D-Altstadt, St-Nr: 103/5923/1779.   Tel: +49-2104-4938799