Re: [openpgp] Disabling compression in OpenPGP

Gregory Maxwell <> Wed, 19 March 2014 22:04 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 30B951A07E2 for <>; Wed, 19 Mar 2014 15:04:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3aGoONFXdfl6 for <>; Wed, 19 Mar 2014 15:04:48 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c03::22d]) by (Postfix) with ESMTP id 1C3A51A07A1 for <>; Wed, 19 Mar 2014 15:04:47 -0700 (PDT)
Received: by with SMTP id hr17so6431893lab.18 for <>; Wed, 19 Mar 2014 15:04:38 -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 :cc:content-type:content-transfer-encoding; bh=GiJtGgrVO3cmhRqO31Nv2iaI6cYxdVrL+WKBn6Jh5+Q=; b=n76XLTQN2AjoJz3Jb2/alnoL7DIZSY/NiC/YYBqO8M+Ot/CTkr6He8gHDcqCjIvshb HxE4F3PtEOspR8CF6K8dGnyQfgHlMp/lZ8a6Z9MkPxeWiUmKL5/8cplPe1UjN96WH/1K MlyeitQ7ZXhAUBarH17iJlDGRZZlEnxvaFPeZTRfO6DlYUCmM0ATurpNQu+1BfZXMsmj W2u4RMInebgzXnWMQbWJK3cVMOba6SE555Vi7dHS0eeoqEHDRtQgFF0Ts4o+ZlRQagTZ UpsbwXeEn1sHNIVakl1KilWg+70jv4HdINXEcZqPxp/cNvqnkKim+fCIrAKNzHJy2BPO iq7Q==
MIME-Version: 1.0
X-Received: by with SMTP id aj3mr26023174lbd.20.1395266678721; Wed, 19 Mar 2014 15:04:38 -0700 (PDT)
Received: by with HTTP; Wed, 19 Mar 2014 15:04:38 -0700 (PDT)
In-Reply-To: <20140319214118.GA17419@savin>
References: <> <> <> <> <20140319204047.GC30999@savin> <> <> <20140319214118.GA17419@savin>
Date: Wed, 19 Mar 2014 15:04:38 -0700
Message-ID: <>
From: Gregory Maxwell <>
To: Peter Todd <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: David Shaw <>, " OpenPGP" <>, Jon Callas <>, Alfredo Pironti <>
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 22:04:53 -0000

On Wed, Mar 19, 2014 at 2:41 PM, Peter Todd <> wrote:
> After realizing that I needed to account for the size of the "Version:"
> string I got the exact same size as your secret for ballot.1, so I'm
> guessing that was your vote.
> Am I right?

Indeed, you are.  password:

On Wed, Mar 19, 2014 at 2:37 PM, Jon Callas <> wrote:
> But it proves nothing here. It's a really, really interesting exception case. We're talking about a default. We're also talking about the protocol definition, and not implementation software.

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

Even thoughtful users who take care to make their messages constant
length will have the implicit compression sneak up and bite them.  Of
course, you could compress and pad up to the original sizeā€¦

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.

There are a great many people who use gpg to encrypt a small number of
control messages (e.g. for updating route registries and such) where
compression can leak information about the content.

> Compression is on by default because it improves security. It meets that goal. It is, however, a default. Defaults can be changed.

It does not improve security in any practical sense. The presence of
compression harms security severely and in a very practical way in at
least some applications. No cipher should be used where the entropy of
the input is believed to be security relevant, and if one were used,
the compression in gpg still leaves non-trivial known plaintext in
cases where the input begins with known plaintext (in addition to
additional compression headers giving more known plaintext even when
the message is otherwise completely unknown).

(It's possible to design compression systems where the output is
indistinguishable, e.g. arithmetic coders bijective termination, but
none of the supported compressors are designed this way... they will
allow you to detect an incorrect symmetric key with overwhelming
probability with just a dozen bytes of decrypted output or less)

> Moreover, there's a way to work around the issue in the existing standard. Make the vote-submission key not support compression. Poof, it works.

Yea, sure, don't aim the gun at your foot and your foot will not be
shot.  It's true, but it's not always useful.  What do you care about
a specification and software? real engineers encrypt their messages by
hand with pen and paper.

Part of the purpose of the specification and software is that doing
everything 'manually' is too costly and difficult, the specification
hopefully embodies the collected wisdom of careful consideration by
the best available experts.

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

Compression is a useful feature, it's nice that often the base64
encoded encrypted versions are not a ton longer than ascii text... but
if we're going through the trouble of encrypting something then the
encryption really ought to not invisibly leak data about the
plaintext. When something is a general tool used for many applications
then we ought to be assuming a sum-of-all-attacks and not just a very
narrow threat model.

Obviously a size side channel still exists, and might be worth
reducing (e.g. by quantizing message size to a multiple of 512 bytes)
but at least that side channel is highly visible to technical users.