Re: [openpgp] Disabling compression in OpenPGP

Jon Callas <jon@callas.org> Wed, 19 March 2014 22:59 UTC

Return-Path: <jon@callas.org>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB49B1A07DB for <openpgp@ietfa.amsl.com>; Wed, 19 Mar 2014 15:59:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m95UfpOwlpLo for <openpgp@ietfa.amsl.com>; Wed, 19 Mar 2014 15:59:03 -0700 (PDT)
Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 886561A023C for <openpgp@ietf.org>; Wed, 19 Mar 2014 15:59:03 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 9F1354F9CBFA for <openpgp@ietf.org>; Wed, 19 Mar 2014 15:58:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at merrymeet.com
Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVYdkTPGnmmK for <openpgp@ietf.org>; Wed, 19 Mar 2014 15:58:53 -0700 (PDT)
Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 565834F9CBE6 for <openpgp@ietf.org>; Wed, 19 Mar 2014 15:58:53 -0700 (PDT)
Received: from [10.0.23.30] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Wed, 19 Mar 2014 15:58:53 -0700
X-PGP-Universal: processed; by keys.merrymeet.com on Wed, 19 Mar 2014 15:58:53 -0700
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Jon Callas <jon@callas.org>
In-Reply-To: <CAAS2fgQotHyN=CFKoWO_aUdP8bhkSixEqSDQcALZ35mG+tk1tA@mail.gmail.com>
Date: Wed, 19 Mar 2014 15:58:50 -0700
Message-Id: <E1E355B9-0906-43DC-BACD-D4A1350C537F@callas.org>
References: <CALR0uiJG6GcngWMUkg6NrP7_4uwf8+QDn6aMF-qonOpRMLdo3w@mail.gmail.com> <95BD0817-D762-41DD-8444-A0C4F7AF1003@jabberwocky.com> <CALR0uiL0-Xp8E=F3idtzBkmRNLk7K_M_cqMt+i2HdNqaNkwn=w@mail.gmail.com> <849778F8-1C16-4FF8-A039-6363C158BD1F@callas.org> <20140319204047.GC30999@savin> <DE00E9BD-1D37-4750-B156-BBDC4B59DB7F@callas.org> <CAAS2fgQZPPrdehcs6TxmYikmyyfxOJqAdngaFk5=PcSGEGnejA@mail.gmail.com> <20140319214118.GA17419@savin> <CAAS2fgQotHyN=CFKoWO_aUdP8bhkSixEqSDQcALZ35mG+tk1tA@mail.gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
X-Mailer: Apple Mail (2.1874)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/a-NtIlYXAXl7q9KXjnquKRwnhSY
Cc: "openpgp@ietf.org OpenPGP" <openpgp@ietf.org>
Subject: Re: [openpgp] Disabling compression in OpenPGP
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Mar 2014 22:59:07 -0000

On Mar 19, 2014, at 3:04 PM, Gregory Maxwell <gmaxwell@gmail.com> 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.

In the usual case, Alice sends a free-form message to a set of recipients. There's no leak in this case.

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

You're stretching it here. If those messages vary in length, there's not much of a leak. In many cases, the real thing you're doing is *signing* the control messages; in the specific example you give (route registries) the actual content of the message may not even be secret. But I know I'm quibbling.

The workarounds here are:

1. Add a no-compression flag to the receiving key.
2. Add "-z 0" to the command line that generates those messages.

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

	Jon