[Top] [All Lists]

Re: [ietf-smtp] [Shutup] Compressing SMTP streams

2016-02-08 12:08:09
On Mon, Feb 08, 2016 at 09:50:43AM +0000, Paul Smith wrote:
AFAICS, CRIME isn't really a issue of 'compression & encryption not
going together', but that the nature of compression lets you infer
information about the compressed data. It doesn't seem to attack the
encryption at all.

Well, the idea behind CRIME is that data strings compress to smaller
strings if there is more repetition in the original string and that
encryption doesn't change the length of a plaintext. So if you're able
to make small modifications to an otherwise unknown plaintext and you
can read (the length of) the encrypted output, you can determine whether
the bit you controlled occurred elsewhere in the plaintext. CRIME uses
this to step-by-step reconstructs a cookie.

These kinds of attacks are the reason why people say that compression
and encryption don't go together, even if you are technically right that
it's all compression's fault. So perhaps it would be better to say: if
it's sensitive, don't compress it.

If you do per-message compression, then I can't really see how
something like CRIME could possibly work. CRIME seems to work by
using the same compression stream over known and unknown data, so by
seeing how it compresses, you can infer something about the unknown
data because you know the known data and how the compressor works.
Also, it's a 'divide and conquer' system, so needs lots of
transactions - possibly exponentially more the bigger the compressed
data is.

So, to do it in SMTP message compression, you'd need to inject some
arbitrary known text into an unknown message. I can't see how you
could do that unless you have actually had control of the original
message - in which case the message wouldn't be unknown... In the
known HTTPS CRIME exploit, the HTTPS client can inject known data
into the HTTP request which gets added to unknown content (the web
cookies) by the web browser so you can see how they interact via the

You'd also need to do it lots of times with the same unknown
message. Probably many more times than the HTTPS exploit because a
typical RFC822 message is a lot bigger than a typical web cookie.

This is all true. I can't see how a CRIME-like attack on SMTP+TLS could
work either.

But cryptography tends to set itself very high standards, in which "I
can't see how" just isn't good enough. Even if you'd be absolutely
certain(*) that such attacks would never be found, I still think it's a
bad idea: implementing cryptography is hard enough as it is; people make
mistakes all the time. Teaching them bad practices should thus be
avoided, even in cases where it doesn't really matter.

Unless, of course, network connections around the world are falling over
because of all the emails. I don't run any large mail servers, so please
correct me if I'm wrong, but a back-of-the-envelope calculation suggests
that this is unlikely to be the case.

(*) and given that, as Aaron pointed out, mail servers aren't updated
often, you would really have to be absolutely certain.


Attachment: signature.asc
Description: Digital signature

ietf-smtp mailing list