Re: [openpgp] Disabling compression in OpenPGP

Peter Todd <> Wed, 19 March 2014 23:12 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EEE991A07DF for <>; Wed, 19 Mar 2014 16:12:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HJDUgAExlxIQ for <>; Wed, 19 Mar 2014 16:12:55 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A10551A07DB for <>; Wed, 19 Mar 2014 16:12:54 -0700 (PDT)
Received: from ( []) by (8.14.2/8.14.2/) with ESMTP id s2JNCCQt044083; Wed, 19 Mar 2014 23:12:12 GMT
Received: from savin ( []) (authenticated bits=128) by (8.14.2/8.14.2/) with ESMTP id s2JNC8tQ041662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 19 Mar 2014 23:12:10 GMT
Date: Wed, 19 Mar 2014 19:12:30 -0400
From: Peter Todd <>
To: Jon Callas <>
Message-ID: <20140319231230.GA10573@savin>
References: <> <> <> <> <20140319204047.GC30999@savin> <> <> <20140319214118.GA17419@savin> <> <>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: e671c915-afbb-11e3-b802-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system.
Cc: Gregory Maxwell <>, " OpenPGP" <>
Subject: Re: [openpgp] Disabling compression in OpenPGP
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Mar 2014 23:12:57 -0000

On Wed, Mar 19, 2014 at 03:58:50PM -0700, Jon Callas wrote:
>> It is! It's a really cool failure mode, and I think you should write it up and submit it to some security conference.
> However, as I said, it's an exception case. It's also an exception case that you didn't explain very well. Let me try to help:
> Zelda is collecting some ballots. The ballots are all text and constant length. The voters, Vernon_i, will each edit the text ballots with their votes, but the resultant ballots will remain constant length.
> If the ballots are encrypted with compression, there may be information leaks because the different patterns of voting in the ballot. In the simplest case where there is only one item on the ballot, it is possible that vote can be discerned despite the raw plaintext being constant length.
> I think I got that more or less right.
> However, there are two workarounds for this:
> 1. Zelda adds a no-compression preference to her key.
> 2. The voting system uses the "-z 0" option in a gpg command.

I don't want a workaround; I want default behavior that is reasonably
safe for users. Removing default compression is a step forward in that

> >> However, there are still many people who consider default compression a feature and *rely* on it for their system.
> > 
> > Care to elaborate on how they rely on it? That seems highly suspect to me.
> > 
> tar -c source-tree | gpg key >source-tree.pgp.gz
> This is also what at PGP Corp we called a "PGP Zip" file, which was implemented as a PGP encrypted tarball. It's done all the time in back-end systems, and very likely the second largest use of PGP, where signing files is the most. It's a really useful idiom.
> You're asking for a change to the standard. You're not really doing that, even. You're asking for a change to the default behavior to software that's been around for 20+ years because you have a wonderful edge condition, for which there are not only per-message but per-key workarounds.
> I'm really sorry your ballots got spoiled. But you can fix that with zero changes to software nor protocol. 

Your example isn't much of a failure; the tarball will end up maybe 2x
larger than it should have been, someone might investigate, and they'll
change the command to:

   tar -c source-tree | gzip | gpg key >source-tree.pgp.gz

or something. This is a *very* low-consequence failure mode.