Re: [openpgp] Disabling compression in OpenPGP

Peter Todd <pete@petertodd.org> Wed, 19 March 2014 20:55 UTC

Return-Path: <pete@petertodd.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 B9E921A0464 for <openpgp@ietfa.amsl.com>; Wed, 19 Mar 2014 13:55:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 LTNDRG_L2tiH for <openpgp@ietfa.amsl.com>; Wed, 19 Mar 2014 13:55:15 -0700 (PDT)
Received: from outmail148161.authsmtp.com (outmail148161.authsmtp.com [62.13.148.161]) by ietfa.amsl.com (Postfix) with ESMTP id 83D281A07FE for <openpgp@ietf.org>; Wed, 19 Mar 2014 13:55:15 -0700 (PDT)
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s2JKt4xY040854; Wed, 19 Mar 2014 20:55:04 GMT
Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s2JKstCO004582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 19 Mar 2014 20:54:57 GMT
Date: Wed, 19 Mar 2014 16:55:17 -0400
From: Peter Todd <pete@petertodd.org>
To: Jon Callas <jon@callas.org>
Message-ID: <20140319205517.GA6566@savin>
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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jI8keyz6grp/JLjh"
Content-Disposition: inline
In-Reply-To: <DE00E9BD-1D37-4750-B156-BBDC4B59DB7F@callas.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: bb48ee20-afa8-11e3-b802-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR bgdMdwsUFVQGAgsB AmIbWVReVVl7XGs7 bAxPbAVDY01GQQRq WVdMSlVNFUsrA2Z6 RVptLRlycwBOejBy Y0VqWz4JDkByIBN/ QlMFQzwOeGZhPWMC AkhYdR5UcAFPdx8U a1UrBXRDAzANdhE/ BwI1Jz8pCH1zKT9c SAUMK11aSkEOBiQx XAsDGjNnHEtNYD0+ KSQJEjYB
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 76.10.178.109/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system.
Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/AHDIP0rJg3TmV4kafPrPtZOovVM
Cc: David Shaw <dshaw@jabberwocky.com>, "openpgp@ietf.org OpenPGP" <openpgp@ietf.org>, Alfredo Pironti <alfredo.pironti@inria.fr>
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 20:55:17 -0000

On Wed, Mar 19, 2014 at 01:47:01PM -0700, Jon Callas wrote:
> > That's the job of encryption, and modern encryption does that job very
> > well.
> > 
> > I strongly support turning off compression by default. That the length
> > of the data being encrypted is leaked is pretty easy for a non-advanced
> > user to figure out - just compare the encrypted and unencrypted file
> > lengths, or for that matter, just think about it rationally. But the
> > fact that information on the contents of the file is being leaked too -
> > exactly what encryption is supposed to prevent - is not at all obvious.
> 
> What's being leaked by compression? Really, I don't get it.
> 
> Consider an OpenPGP blob that is compressed and encrypted. Consider that it is intercepted by whatever means. What's the leak?
> 
> Here's an example, where an unknown plaintext is encrypted both to a key, and to a passphrase:
> 
> -----BEGIN PGP MESSAGE-----
> Comment: GPGTools - http://gpgtools.org
> 
> hQEOA2EbpgyFsrXlEAQAs63hznff9WCrq9xpT5s8dbmoabOQpfV/Crzaqn5diiCp
> x1kyqqTCpSJQ648O3bF3GYq0KfqWhzc3S+rK7yrSpSA8UDWWifVfSBKmVDvYUD/g
> GPURwlTKtUp00MzlKrT083oq/aQEotO/7botgihpEbWPrEO3ZZIFwwxmNfwUUtED
> /jyNjMfPTmeLYvPdMLFiy+AuMbGnE3L0M9+iTLJZHW6Hb/hn0TLJk69RdDkmyiql
> VaZNYE+9l1AiZpEVddmoKOTPPV0EtzeNqVZtVr3yCH0rBrN54GjHoWAnD8/IhuX8
> T11kixGJhs1228xlhK+3UTp15VGrKNQsLoGpUd45iewPjCYEAwMCe35rGZQc7xjR
> gk41KuP8CsROH0ulK1pzm/zH2gZbzhY068np63ZvnfxTQyaYBV+MRAhN2NOF1XkW
> 4QtFr2bfJCYiCzS6vuwxjRicfU9kwHaI+G3XfJGXVB/qtcgEV7JWG81VDnU2zKSh
> h1KATe/zU5zJ7RM6mwrL37Ve4SY5tLPvpxSahu8fRffeU8/pBeQCcZyKa7ZGxiFB
> xjFLBB2a3N77Bf0VZ+nRS9nE6SpTEx8tF8b8l3qMa+lzJKVZk7cP2Yc0POHtBCT6
> F2TlnMDEvRvFmbz+3Z592OCXaZoBG6fU7VKALzZ/kl6usm6mvKAtrbNQfTk5MM38
> fqwUrcLOHpxWVNKcDvmOGdsODq5lX2coHfsix8aBoRBz/q1HiOGV3F0C9hudag01
> P199G1PCYuxzX9OvJPKEZnzf6+jEZ3vE8dhkRZPrhs/Xo7A7ryj++GSKFCSyVaHk
> PryGNgJnAp82uimr9FYT8Wmwoy42o1pPCAyVoquowHxpXAgADhmwpk0wbbE5vaD/
> 81uh1843VRySOpuQCkIkI7PhIy3HBbs349FVLKnC07VF0vMHzW3QeY9JVZJH6RlJ
> DQP0G2TjBaneHRPhdoNKzWLhTfKuaDo9FkJaaTzeB/gVKnPfovcdDjZefmflCQXR
> PvtYDsms4m5slCo/MTToM4oGuBBZqqcLIv5ZSRWYr/Gu2w9ZLkysb92dtfJe4+nw
> y2Bqk9UKInw3WAbAs0rCUlPBpAOFxNHdjkzjthGx6P3W5ZI+nG9aXyB1XNeHaTYL
> /Sx0SEFU1fmlKaIynY4reM3qJjjXi/PAWn5piTrH/G0LI3CUEgXa3Mw3sG3ArbAw
> PleXVP3QWt8jf418bDA4BLH4DFhYLQk2Ayss1M/snoRip/iUqKEu0OsUJtaspHDY
> Xt2bksh35paCav0rEtGfhxC0ks7UTdRQDP4l9tX24unQZfWAEfZkPhQPh+mkDA+H
> 3u6VfmN+5QXqph8//Qk7LSTsiBgG+EswRpqDRhNjV2ibCWjMmggtJZyKq/oOsQpS
> oCQqkpgjrv+GSGCgEwIKeUZfnTtVTpKX0EiDjUTQ5Cuq1VR+NsIfHdo2ZSVQ0+mS
> D9sGjILD87c80Pcfd3i9NtZoZqX46p4CVOReaFEvll1X9YqEaX4uDPCPoubSHsqR
> EfqIT2AYRegF1Grjr16YTzqiqkfL/4lOKQHyRwGLjq8pag888IXdbKIxWbXtMESs
> =Uqr6
> -----END PGP MESSAGE-----
> 
> What's the leak? What's the vuln?

Having a completely unknown plaintext is the best case; having
plaintexts that are not completely unknown to the attacker is both
common, and reasonable to defend against.

If I knew that the plaintext was either 1KB worth of uncompressable binary garbage,
or 1KB worth of text, it'd be pretty easy for me to figure out if I was
looking at garbage or text.

Gregory Maxwell's example of the Wikipedia vote's privacy being broken
by compression-by-default shows this is a real world risk that users are
not thinking about.

-- 
'peter'[:-1]@petertodd.org
000000000000000067c4c46a5fa2d2686559607d14450497efb2826234b18d87