Re: [openpgp] Disabling compression in OpenPGP

Nicholas Cole <> Thu, 20 March 2014 07:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C36BF1A0674 for <>; Thu, 20 Mar 2014 00:53:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4
X-Spam-Status: No, score=-4 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, GB_I_LETTER=-2, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3wXQNX5HAJw4 for <>; Thu, 20 Mar 2014 00:53:32 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4013:c00::236]) by (Postfix) with ESMTP id 493C11A066E for <>; Thu, 20 Mar 2014 00:53:32 -0700 (PDT)
Received: by with SMTP id d49so314484eek.27 for <>; Thu, 20 Mar 2014 00:53:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=CtqTsObcUbqp/4pPiC04vCgYY2oFgrrbxMSjRSwts48=; b=r7L4oqufLwaCsc93nkWVhCG/94F0zm6zZ+kgI+N2dUwlqu2xWuxYfn83Frz0G9QL/U CRcowyG+5YXP/Fcd1jFLGMr50zfB4fN2wbFDofxuYTZYfOjqQOu5vhDOtibG91C7sBmN +Qu01BJh/lcmeNa74aGE7WPXurQlysQG3EHhMxgypVVqwvU83IA6/fT2BK874x844w/0 r3BDrWXeO2tg7evbT5iuGe7ZnbdV/08LtbNlfZf9PzpKfcv2RuIIrYjbAWeOAgsf2vQ1 9ud2115IKa6Vu57FTc8HAADe45W9WxamMQMmslE0sqJ2dFljOLhhunz0Ud9e7ZRveVNa qrrA==
MIME-Version: 1.0
X-Received: by with SMTP id y9mr40306798eeu.12.1395302002826; Thu, 20 Mar 2014 00:53:22 -0700 (PDT)
Received: by with HTTP; Thu, 20 Mar 2014 00:53:22 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <20140319204047.GC30999@savin> <> <> <20140319214118.GA17419@savin> <> <>
Date: Thu, 20 Mar 2014 07:53:22 +0000
Message-ID: <>
From: Nicholas Cole <>
To: "" <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
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: Thu, 20 Mar 2014 07:53:34 -0000

On Wed, Mar 19, 2014 at 10:58 PM, Jon Callas <> wrote:
> On Mar 19, 2014, at 3:04 PM, Gregory Maxwell <> wrote:
>> It's a very highly surprising failure mode which leaks information
>> about the plaintext by encoding it into the size, one which baffels
>> otherwise expert users of the sort who would post to the openpgp list
>> to exclaim "What's being leaked by compression? Really, I don't get
>> it."
> 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.
>> Voting isn't the only case where compression leaks data about the
>> plain-text, it's just one where I know that it cause and actual
>> compromise, with actual expert users, in actual practice.
> Please give other cases.

This discussion reminds me (trivially) of the example of university or
job acceptance or rejection letters.  In most cases the size of the
envelope usually reveals the content of the message, since an
acceptance letter will come with all sorts of additional forms etc.
There are many cases where the size of the message reveals something
about the content, compression or no compression.

Less trivially - voting systems online are really hard.  I remember
that _Applied Cryptography_ devoted a whole chapter to the issue.
In this case compression unexpectedly (for the users) added to the
message frustrated efforts at secrecy that were based on assumptions
about message length.    It is worth someone writing up this
experience (I can't find any documentation of it online).  I think it
is a bit of a stretch to say that compression itself is bad.  It just
happened to be unhelpful in this case.  As you note above, Jon, the
key used for voting could have had no compression preference and all
would have been well.