Re: [openpgp] Deprecating compression support

Hello, long-time lurker, first time caller.  As I read this, this morning, I 
fail to see the advantages.  For instance, let’s look at a couple of these 
issues:

 

Compression makes it impossible to reason about the size of a

decrypted message,

 

It’s hard not to look at this and say, good!  The idea of encryption is the 
hide information and burying information about the length of the message can 
only be an improvement.

 

  - Compression interacts badly with encryption, see e.g. CRIME,

    BREACH, and hiding of EFAIL-style CFB gadgets [0].

 

I am not sure how valid this is.  For instance, in the paper cited, we see the 
following comments:

 
[F]or OpenPGP, we needed to develop more complex exploit techniques upon 
malleability gadgets because the data is typically compressed before encryption
OpenPGP’s plaintext compression significantly complicates our attack.
The difficulty here is to guess a certain amount of compressed plaintext bytes 
in order to fully utilize the CFB gadget technique. Not knowing enough 
compressed plaintext bytes is hardly a countermeasure, but makes practical 
exploitation a lot harder.
 

The problems described in the paper are not compression, but rather the sender 
drops known plaintext right into the start of the stream.  I mean, it’s not 
rocket science and in the, e.g., Facebook example, it could be addressed by 
adding a nonce string to the start of the message.  There are certain streams 
of thought which have advocated this for years, anyway.  

 

Then there’s this:

 

  - The downstream application is in a better position to decide whether

    and how to compress data that is then encrypted using OpenPGP.

 

Now, I will admit to misinterpreting this (I think) and assumed you meant 
compressing after application of PGP.  That’s, of course, silly, but since I 
did the work of showing AES cyphertext to be basically incompressible, I will 
send it out, anyway.  See the attached Excel spreadsheet for results of 
pre/post-encryption compression on the Canterbury Corpus.  Nothing here 
surprising, but data is good!

 

—James

 

From: openpgp <openpgp-bounces(_at_)ietf(_dot_)org> on behalf of Justus Winter 
<justuswinter(_at_)gmail(_dot_)com>
Date: Monday, March 18, 2019 at 11:25
To: <openpgp(_at_)ietf(_dot_)org>
Subject: [openpgp] Deprecating compression support

 

Hello,

 

I propose to deprecate compression support in OpenPGP.  The reasons

for this are:

 

  - Compression makes it impossible to reason about the size of a

    decrypted message, requiring the use of a streaming interface even

    for seemingly small messages, e.g. emails.  Experience has shown

    that downstream users struggle with the correct use of streaming

    interfaces.

 

  - Compression allows the construction of quines.

 

  - Compression interacts badly with encryption, see e.g. CRIME,

    BREACH, and hiding of EFAIL-style CFB gadgets [0].

 

  - The downstream application is in a better position to decide whether

    and how to compress data that is then encrypted using OpenPGP.

 

  - Compression make the standard more complex, and enlarges the

    trusted computing base of implementations.

 

I realize that we cannot suddenly drop decompression support, but I

would suggest to stop emitting compressed data packets.  If this

proposal gathers traction, I would be happy to suggest a change to the

standard.

 

Cheers,

Justus

 

0: Section 5.3 of https://efail.de/efail-attack-paper.pdf

_______________________________________________

openpgp mailing list

openpgp(_at_)ietf(_dot_)org

https://www.ietf.org/mailman/listinfo/openpgp

PGP-Compression-Analysis.xlsx
Description: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp