Re: [openpgp] Deprecating compression support

Jon Callas <> Tue, 19 March 2019 06:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 834A11310C4 for <>; Mon, 18 Mar 2019 23:03:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.449
X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, KHOP_DYNAMIC=0.85, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b_vpOFYkcHIk for <>; Mon, 18 Mar 2019 23:03:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AC8B51277CE for <>; Mon, 18 Mar 2019 23:03:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=04042017; t=1552975389; bh=+EzDc0U4i859SK6cn2Hp6x3VwGLdBqYlg4vSuoO3bEQ=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=PQXKMtLIw9ZRtiFPiXdslVKEpcW9prKqORW25FqdV0Z++cJTmeQW5Rb+fKuiTy2xF CLUIBNm0wBfdlSqLCChDqgJRKJG/j5udpdmsGcupg4Rk0BxY3A0sAJ/L1269J8uATV +gVKjNvUNSDUd8QkhssepTyS6m955uTCsYsIahppDeoKcxExGB20Q+cHdhS4Jk/OgT nxaFOYoBeJYPrwYRJosoxMViQZEaueTJ7TrxZKavGJN7E98TSM8DgMti5fTWNXeGb4 gUBCezkKEZ0ZhMQARlbswnkF5DBFT9GcYQ33qytcGuWXpYXhquJN86N21dIET5WGaA 7Qr2dZg7FRlOQ==
Received: from [] ( []) by (Postfix) with ESMTPSA id C6315D2025E; Tue, 19 Mar 2019 06:03:08 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Jon Callas <>
In-Reply-To: <>
Date: Mon, 18 Mar 2019 23:03:07 -0700
Cc: Jon Callas <>, Jon Callas <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Peter Gutmann <>
X-Mailer: Apple Mail (2.3445.102.3)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-19_02:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=2 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1903190046
Archived-At: <>
Subject: Re: [openpgp] Deprecating compression support
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 19 Mar 2019 06:03:11 -0000

> On Mar 18, 2019, at 5:57 PM, Peter Gutmann <> wrote:
> Jon Callas <> writes:
>> One of these differences is that zip-style compression is just not as useful
>> now. 
> There is one situation in which PGP was at one point widely used but for which
> I don't have much current data (more recent than about five years ago) and
> that's banking and medical EDI (so X12/HL7), where compression is a required
> feature, because you're moving potentially multi-megabyte text files via FTP
> to/from mainframes over slow links.

That’s precisely the use case I was thinking of when I mentioned scripts that would be annoying to update. There’s likely a lot of those still around.

> Outside of that rather specialised use, there's no reason to use compression.
>> The compression inside of OpenPGP is also hard to implement correctly. The
>> default compression, the “DEFLATE” option is a modified implementation of
>> ZIP-style programs from the era of the late 1980s. 
> To give some background to this, the original PGP use LHarc because it was
> sort-of free.  When the first InfoZip implementations came out, Phil correctly
> guessed that it would become the universal standard based on the popularity of
> MSDOS Pkzip.  However, what went into PGP 2 was a pre-pre-pre-release of Zip,
> whose format didn't settle down completely until after PGP was released.  I
> think the only reason why deflateInit() still accepts -13 as a compression
> parameter is to trigger the PGP 2-compatibility mode in the compressor.

Thanks! That helps clarify the context.

>> The underlying reality is even worse. Go look at section 5.6 of 2440, and
>> there are interoperability hints for working with PGP2 because it had further
>> limitations in it for internal table sizes. 
> That was due to 16-bit segments on the 8086, even then you had all sorts of
> hacks to get things to work.

Oh, I’m sure!

There was so much cleverness and good technology in there at the time, it’s just now we’re 28 years later, and we can move on.