On Tue, Sep 19, 2000 at 03:00:28AM -0700, David Schwartz wrote:
> While I do agree that any encryption algorithm worth using should be able
> to withstand a known plaintext, I disagree that randomizing the plaintext is
> not valuable. For one thing, it's nobody's business exactly how many bytes
> your HTTP request is. I also think encryption is valuable for other reasons,
> like saving bandwidth.
>
> As for the compression header, this can easily be fixed. Begin with 8
> random bytes of data, then put the header. This is useful anyway because
> most protocols you would layer over SSL tend to have stereotyped headers
> too. I get laughed at for this though. If I had a dime for every time I was
> told to either trust an algorithm or not use it at all, ...
>
> Basically, if you don't care about known plaintext, you shouldn't care
> about the compression header. If you do care about known plaintext, you
> should be advocating compression.
>
> I'm not so concerned about HTTPS. But I'm concerned that lots of people
> will layer all sorts of other protocols over SSL. These protocols (like
> SMTP, for example) could benefit from compression.
I think that you overestimate the value of compression a bit.
Talking about SMTP over TLS, the most significant overhead is the TLS
handshake, which may take more than 3-4kbytes depending on the length
of your certificate chain and whether there is a client certificate or not.
Then you perform the MAIL FROM:/RCPT TO: handshake, which is only several
bytes and won't lead to any significant reduction by compression.
The only thing that would have any gain would be the actual message transfer.
Most emails we have are in the range of 2-4kbyes, which is the size of the
TLS handshake bytes. Summarizing, I don't think that compression would buy
us a lot.
We could gain a lot with .doc attachments people tend to send. More sensible
persons use .zip, or .gz to send data, so compression would buy us nothing.
The same applies for http, from my experience. HTML documents tend to be
reasonable sized, the really large items are .jpeg .gif or similar types,
which are already compressed and won't gain further by applying an additional
compression layer.
>From my experience, this even holds for my ISDN at home, not to speak from
the more or less speedy Internet connection of the university.
The realy ugly thing is the overhead for very small messages (I am typing
these words via ssh), were every keystroke requires some handshake, but
compression won't help here.
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
