ietf-smime
[Top] [All Lists]

RE: Compressed data type for S/MIME

1999-07-29 12:14:20
Darren Harter <darren(_dot_)harter(_at_)entegrity(_dot_)com> writes:

1. Are we really concerned with saving network bandwidth these days?  If we 
are then clearly compression is essential.  If we're not, why are we 
discussing it at all?

In the examples I cited (batch EDI), compression is absolutely essential.  I 
know of at least one nontrivial project where compression was ranked far above
any kind of security in terms of importance - you simply couldn't move the 
data over ISDN, X.25, or dialup links unless it was compressed.  Given that
even for more conventional business email use you're going to have bloatware
documents (150 copies of a 1.5MB Word memo reminding people not to forget the 
company picnic, 10MB spreadsheets with last month's sales figures, etc) 
typically going over modem (RAS) or ISDN links, and that the typical PC has
CPU cycles to burn, it doesn't make any sense *not* to include compression.

2. If we need compression, how does the algorithm complexity of zlib 
compression algorithm compare with 3DES encryption?  What's its average 
compression rate?

Is it sufficient to say "b***y quick", or do I have to actually provide some 
figures:-)?  I really have no idea of the compression rate of something like 
zlib, it's hard to test by simply running zip because it's I/O bound, and a 
quick search hasn't located any details, but I can imagine that (especially 
in a speed-optimised mode like -1) it'd run circles around any crypto except 
RC4.  The only comparison figures I have are with LZO, which runs at about 
1/3 the speed of a memcpy().  zlib isn't nearly as fast, but it's much faster
than any crypto operation.  Also, don't forget that you're typically 
tripling[0] the speed not just of encryption and hashing but also the multiple
layers of base64 gunk which S/MIME wraps around every processing step.  If
nothing else, it'll stop the PGP crowd from laughing at S/MIME's 2:1 expansion
of everything you send with it while PGP gets 2:1 compression.

I think my bottom line questions here are: how important is processing speed 
compared to network bandwidth? and how much time does this aspect of the 
processing take compared with all those cert/crl processes going on in 
S/MIME and/or CMS?

You're winning on security, processing speed, and network bandwidth, at the 
cost of adding a new OID and about an hours programming time.

Peter.

[0] Based on 3:1 - 4:1 compression figures for a random collection of Word 
    documents, for EDI it's even higher.


<Prev in Thread] Current Thread [Next in Thread>