Re: [openpgp] Disabling compression in OpenPGP

Gregory Maxwell <> Sun, 13 April 2014 22:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E5F0C1A0251 for <>; Sun, 13 Apr 2014 15:52:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 09EtpCzq-Nvv for <>; Sun, 13 Apr 2014 15:52:57 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c03::22f]) by (Postfix) with ESMTP id CAE311A0241 for <>; Sun, 13 Apr 2014 15:52:56 -0700 (PDT)
Received: by with SMTP id pn19so5047654lab.6 for <>; Sun, 13 Apr 2014 15:52:54 -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=DfUavmWG9CBXWcGKKj6szfazrVkduEJs2xpXoimyzhw=; b=G5daFlAs2xpO3zHF8fGbjyXQxywxHldng6kxwYnJzRRl4Mlr0LaK8WrvAob5ZNd0Lu Ue32H4DhKPq8J/7cq3LS8HRsapHwmWTGhbYZILyojQrY5BqaXbtnaGgxnWJvZsSJnGLH tNAKP6obcVQLJf3vakjepKJ37rhZk/tw/rwidHLmcokx2OOlJKh/ZRhjUdtttp4RRDb7 unxehxF2Jpcwkisr5yD3QWaw3VNGAzzBW2ETRRDFvD/rWxbljtitrWl8tFV/SaurLU8f HKHA1RZJPPC5texrPs2KZPZXyVETI+gfa4q4CQClNT13llLVgm/le/TZDqQncMxG6poL wslw==
MIME-Version: 1.0
X-Received: by with SMTP id kq1mr27173891lac.6.1397429573989; Sun, 13 Apr 2014 15:52:53 -0700 (PDT)
Received: by with HTTP; Sun, 13 Apr 2014 15:52:53 -0700 (PDT)
In-Reply-To: <1581476.osxlhUbTDj@inno>
References: <> <> <> <1581476.osxlhUbTDj@inno>
Date: Sun, 13 Apr 2014 15:52:53 -0700
Message-ID: <>
From: Gregory Maxwell <>
To: Hauke Laging <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: " OpenPGP" <>
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: Sun, 13 Apr 2014 22:52:59 -0000

On Sun, Apr 13, 2014 at 3:30 PM, Hauke Laging
<> wrote:
>> There are many cases where the size of the message reveals something
>> about the content, compression or no compression.
> Would it help to have to possibility to add a certain amount of
> (ignored) random data to an encrypted packet?
> In that case an OpenPGP application could – regardless of compression –
> be configured (in appropriate situations) to create packets which e.g.
> a) have a certain minimum length
> b) have a length which is a multiple of a block size (e.g. 1K, 2K but
> not 1234 bytes)

Yes, I believe many of the most devastating cases would be addressed
by quantizing the sizes. There may still be cases where the user is
compromised— where the revealing data is only a single bit and where
the sizes put it near a quantization threshold, but the number of
cases where the user's privacy is quietly compromised would be fewer.

I continue to hold the view that an implementation which expects
perfectly informed users to be aware of and avoid subtle,
unadvertised, and format specific information leaks will (and, as I
pointed out, has) fail to produce real users with the advertised and
expected level of security. The great challenge of a general tool is
that you cannot assume a narrow threat model or a sophisticated user.
In some cases the attacker may even be the party specifying the
protocol, relying on subtle behavior the underlying trusted components
(like openpgp) to compromise the system. As a result perfect security
is almost certantly impossible, but there are implementation
optimizations like disabling compression for small messages, where it
is never very useful and sometimes actively harmful, and quantizing
sizes which can provide a practical improvement in a world where users
aren't perfect and attackers don't play nice. I think these
optimizations should be well specified and recommended at the SHOULD

As an aside, I note that RFC6562 SHOULD NOTs variable rate compression
for the application of secure VoIP for highly sensitive information.