Re: [openpgp] Disabling compression in OpenPGP

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BECE61A06CF for <>; Thu, 20 Mar 2014 06:51:30 -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 Gsbbtfowbnm3 for <>; Thu, 20 Mar 2014 06:51:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B24761A069C for <>; Thu, 20 Mar 2014 06:51:27 -0700 (PDT)
Received: from tormenta.local ( []) by (Postfix) with ESMTPSA id 1424C6D4AD; Thu, 20 Mar 2014 09:51:14 -0400 (EDT)
Message-ID: <>
Date: Thu, 20 Mar 2014 13:51:12 +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:51:31 -0000

On 20/03/2014 11:55 am, Alfredo Pironti wrote:
> On Thu, Mar 20, 2014 at 12:25 PM, Werner Koch <> wrote:
>> On Wed, 19 Mar 2014 23:58, said:
>>> I'm really sorry your ballots got spoiled. But you can fix that with
>>> zero changes to software nor protocol.
>> Yep.
>> However, this a problem of the voting protocol.
> It would be, if the voting protocol was prescribing compression, or was
> using ballots of different lengths.
> Instead, here OpenPGP is to blame because it silently slips in compression.

OpenPGP doesn't make any statement about whether it preserves the
length, up or down.  Typically crypto can enlarge a packet, or it can
shrink the packet.  It's complicated, we slap on some MACs and headers
and padding and stuff, so the packet ends up growing.  Then some of that
might be clawed back by compression or ratcheting or packet slicing or

So we don't typically promise much about packet lengths.  This becomes a
bit more germane with say disk encryption, where for some reason people
insist on not losing much space, and it becomes convenient to encrypt
block for block.

It *also* becomes an analogous issue when emailing from one person to
another, as the trackability of names and times is an issue.

As soon as you start putting some attention on what the users are doing,
a generic broad protocol such as OpenPGP and also SSH and TLS and Skype
and etc start to show edge cases where they might not be quite perfect
for the task.  Which is why there is a continuous war going on between
the folks who say "use TLS and you're secure" and the folks who have to
protect real value.

It seems general-meets-specific brittleness has become an issue when
people have a single byte protocol such as the voting protocol in use.
It could be that OpenPGP could be improved for that protocol failure
case, at the expense of harming all the other people who love the

But actually, there is a wider question here.  Is the voting protocol
properly thought out, and is OpenPGP really the answer?

I doubt.  Voting is one of the really hard problems.  Most of the
old-timers I know here will be able to go in and rip the guts out of any
simple slapped-together voting protocol.  Most of the old-timers know
that voting protocols are very hard, and they don't get involved because
it's so darn depressing.

So I'd say, no.  OpenPGP isn't to blame at all, that I see. Voting is
hard, and I expect the people who put it together didn't do nearly
enough thinking, or perhaps they assumed to much.  I for one would not
use OpenPGP to do voting.  Or if I did, and it f**ked up, I'd say darn,
my fault, should have known better :)