On 7/3/03 6:56 PM, "Derek Atkins" <warlord(_at_)MIT(_dot_)EDU> wrote:
Just to play devil's advocate, why do we need yet another compression
algorithm?
I'm not the person asking for them, so I may be inadequately explaining
this. Nonetheless, here goes.
The argument of "no new algorithms unless one is broken" makes more sense
for things like ciphers than it does for compression. Compression in OpenPGP
doesn't have the same sort of security implications that a cipher does, and
so one doesn't need to be as conservative about it.
The practical technical reason for bz2 is that it compresses better. In a
test I saw, it compresses 12% better than Deflate, and 7% better than zlib.
That test was with a backup of a server. Here's the actual results:
Original tar file: 1,739,950,080 bytes (1.62 GB) 100%
.tar.pgp file : 730,450,065 bytes (696.6 MB) 43%
.tar.gz file : 694,085,841 bytes (661.9 MB) 40%
.tar.bz2 file : 648,270,622 bytes (618.2 MB) 38%
The practical product reason is that there are a number of storage archival
systems that are adding in crypto. Many are encrypting some compressed data
with PKCS7 or some home-brew thing. I've been getting questions about using
OpenPGP as an archival primitive, especially since it includes compression.
I would like to be responsive to this, and say that OpenPGP is a great
system to use for encryption and compression, and why sure, just code it up
this way. It would similarly pain me to have to say that OpenPGP isn't
suitable for encryption and compression of large amounts of data, please go
shop at Gimble's.
Yes, I know that there are potential interoperability issues when keys get
migrated around, but I also of the opinion that when an implementation
imports a key, it should make sure that the preferences reflect what it
supports.
Jon