"David Schwartz" <[EMAIL PROTECTED]> writes:
> 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.
This is why SSL allows variable length padding, up to 255 bytes.
> 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.
This adds no value whatsoever. It's trivial for an attacker to
throw away the first cipher block and attack the second. Remember,
the IV for the second cipher block is the previous block of
cipher text. Similar comments apply to stream ciphers. Known plaintext
at any fixed position in the cipher stream allows keysearch attacks.
> 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, ...
If you don't trust your encryption algorithms against known plaintext,
you've got problems compression is not going to solve.
> 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.
See above.
> 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'm perfectly willing to grant you that compression would provide
non-security benefits. I just don't buy the security argument.
As I said previously, the reason compression isn't in SSL isn't that
it wasn't a good idea. It was that there were IP concerns.
-Ekr
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
