Re: [openpgp] Disabling compression in OpenPGP

ianG <> Thu, 20 March 2014 14:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 878711A075C for <>; Thu, 20 Mar 2014 07:09:38 -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 gVLAoeCjb1Yw for <>; Thu, 20 Mar 2014 07:09:37 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0B1601A08DA for <>; Thu, 20 Mar 2014 07:09:37 -0700 (PDT)
Received: from tormenta.local ( []) by (Postfix) with ESMTPSA id 711A26D4AD; Thu, 20 Mar 2014 10:09:27 -0400 (EDT)
Message-ID: <>
Date: Thu, 20 Mar 2014 14:09:25 +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> <> <20140319205517.GA6566@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 14:09:38 -0000

On 20/03/2014 13:56 pm, Alfredo Pironti wrote:

> In this discussion, the "input distribution" argument has already been
> debunked: a good crypto scheme works equally well regardless of the input
> distribution.
> Also attacks that seemed to be thwarted by compression turned out to be
> actually thwarted by the different message format that compression implies.
> What other security arguments would remain in favor of compression?

At the margin, if a protocol finds itself finding 2x sized messages, it
may simply fail.  This leads to a security failure if the result is that
the user switches away or does something else like cleartext message
delivery (the failure known as S/MIME).

This is a very meta-argument, in that usability over time is more
important than anything else.  It's not a particularly good theoretical
argument because it lacks context, it's more like one of those
unforeseen consequences you can only find out by trying it.  We may find
on trying it that we lose half our user base because all their backups
break;  or we may not.

It's also the case that we tend to prefer to protect our existing users
and their apps more than we tend to help people who aren't as yet firmly
in that set and dependent.  This is a tendency that I argue against
vociferously in any other context except an IETF WG ;)

Or in simpler terms, if it ain't broke, don't fix it.

iang, amused that I find myself defending the old, crusty ways!