> "David Schwartz" <[EMAIL PROTECTED]> writes:
> > Speaking of which, does anyone know why SSL doesn't support any
> > compression? Not only would it save bandwidth, but it seems to
> > me that it
> > would improve the strength of the encryption by randomizing the
> > 'plaintext'.
> It does support compression. It just doesn't define any algorithms.
> There were intellectual property concerns. Basically, Netscape
> and later the TLS Working Group couldn't agree on an algorithm
> that everyone was convinced was unencumbered.
That's sad.
> That said I don't buy the 'randomizing the plaintext' argument.
> Any encryption algorithm worth having doesn't need this randomizing.
> Moreover, compression algorithms often have a stereotyped header
> that gives you known plaintext.
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.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
