ietf-openpgp
[Top] [All Lists]

Re: [openpgp] Deprecating compression support

2019-03-18 19:58:13
Jon Callas <joncallas=40icloud(_dot_)com(_at_)dmarc(_dot_)ietf(_dot_)org> 
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.

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.

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.

Peter.

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