Re: [openpgp] Deprecating compression support

Jon Callas <> Thu, 21 March 2019 22:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0E25C129A87 for <>; Thu, 21 Mar 2019 15:37:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.449
X-Spam-Status: No, score=-3.449 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_MED=-2.3, 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 6kYT2-tmlWNj for <>; Thu, 21 Mar 2019 15:37:51 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D87301279A5 for <>; Thu, 21 Mar 2019 15:37:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=04042017; t=1553207869; bh=9jjeJzRv4OtyzqHKJ7+KpFN8P5g5XO4Rnc+sozOFIjo=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=tMwmvC5seKJhsM8CKFO8kxzbj7/I/ZKA6nefwElQ03BoyHGbSXeZBbkNb0BbG/04B CuhXH0ZWFTccfTyILkvJj6qn5WFGU83EMPH+k3Dh/kLrnnYK6ntwCYgFNHC6i3rFA4 RlDz6xLcXN9XtSSlLa3E4u0edV5fMtxt1q89uLGsBrdY3qRtTwJqcA38CKYmjm1DPe tGfv8MqFHeZNDRmO2VjmeLBI1AJVa6rbBOv18hCunwpRU/1qItRVEq5OOPhcv8Kqmj CVoVGqUs8FSjpUOg3fFj/3qMXMec4AUOe69rdOyle1luNt8kJqFW63CG1cTtQW3zLG 5c2XwVh7tM+Zw==
Received: from [] ( []) by (Postfix) with ESMTPSA id 9EB0F40119; Thu, 21 Mar 2019 22:37:49 +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: Thu, 21 Mar 2019 15:37:46 -0700
Cc: Jon Callas <>, " OpenPGP" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Gregory Maxwell <>
X-Mailer: Apple Mail (2.3445.102.3)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-21_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1903210157
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: Thu, 21 Mar 2019 22:37:53 -0000

> On Mar 20, 2019, at 5:30 PM, Gregory Maxwell <> wrote:
> I buy the combining encryption with compression being useful
> argument... but at the same time, openpgp compression is increasingly
> far from the state-of-the-widespread-art (e.g. xz) and there probably
> isn't much interest in updating it to chase the state of the art
> compression (and for short human texts, I think recent machine
> learning progress look like they're resulting in significantly higher
> amounts of compression, -- just no one has productionized that work
> yet).

I almost brought up that case, as I find it interesting and compelling, but it’s not the case we’re dealing with here, and I thought it would be some combination of trollish and a straw man, so I didn’t.

This is a case where there’s an issue. For those wanting a TL;DR, someone created a text ballot that got encrypted with OpenPGP and sent in an email. Because the encrypted ballot a single question and compressed to a different size, so you could tell who someone voted for by the size of the ballot (all other things being equal). [1]

This is a problem that’s worth looking at. (Also, I feel like I am a broken record here.) There is an existing workaround for this issue, and that’s to put a no-compression preference on the key people encrypt to. 

I believe this is yet another reason why the implementations might want to move towards compression off by default. 

That wasn’t what was said at the time — at the time, the debate was that because of this problem, compression should be banned in the standard, which is not only more problematic (as we’re seeing now, there are a lot of people who depend on it), and the slower way to handle things. 

I am quite sure you’re frustrated, and I am too. I agree that we ought to phase out compression, and there are a number of reasons for it. This is one of those reasons. I’m sure that I frustrate you, too, because I consider that case to be a minor reason. We are, however, on the same side on outcomes. Let’s concentrate on the outcome we agree with.


[1] Getting rid of encryption does not completely solve the ballot problem; you still need to design the ballot properly. Here’s the counter example: Consider a ballot where someone writes in either “Alice” or “Bob.” This ballot leaks the choice because Alice’s votes are two bytes longer in length. A ballot that ships “[ ] Alice [ ] Bob” and asks to put an X between the appropriate brackets is much better ballot construction. It’s still possible to get that one wrong, too, either by accident or on purpose.