Re: [openpgp] Disabling compression in OpenPGP

ianG <> Thu, 20 March 2014 13:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 317601A068F for <>; Thu, 20 Mar 2014 06:58:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XmEipDT7xr_1 for <>; Thu, 20 Mar 2014 06:57:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E71D51A03FA for <>; Thu, 20 Mar 2014 06:57:58 -0700 (PDT)
Received: from tormenta.local ( []) by (Postfix) with ESMTPSA id 420F16D4AD; Thu, 20 Mar 2014 09:57:49 -0400 (EDT)
Message-ID: <>
Date: Thu, 20 Mar 2014 13:57:46 +0000
From: ianG <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
References: <> <> <> <> <20140319204047.GC30999@savin> <> <> <20140319214118.GA17419@savin> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
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 13:58:00 -0000

On 19/03/2014 22: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. 

Is there a sense that this could be more traumatic at small packets?
Could we set a limit say 100b under which packets aren't compressed?

Actually I think not because the attack is about comparison amongst
results of different packets.  The encrypting/compressing agent only
knows about its one packet, it knows nothing about the other packets.
So it cannot know about the effect of compression on the other packet,
and how one ends up being markedly different to another.

If I get it right, it all comes back to the (hidden? agreed?) assumption
of length.  What is our preference, to meet some assumption about
length?  Or to not meet it?

Perhaps a comment needs to be put in the document "We make no claims as
to the preservation of length.  Compression can result in leaking
information which can be illuminating in known-plaintext and
multi-packet scenarios."