[Top] [All Lists]

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

2016-02-08 17:44:51
* Russ Allbery <eagle(_at_)eyrie(_dot_)org> [08/02/2016 17:56:37] wrote:
Paul Smith <paul(_at_)pscs(_dot_)co(_dot_)uk> writes:

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.

The potential for an attack like this on per-message encryption comes from
the fact that the leading data in email messages is fairly predictable
(the same few headers, and a given client is likely to generate them in
roughly the same order).  That's where you get the known data from.

Previous posters to the SHUTUP mailing list (maybe also this one?
just joined) suggested only compressing the message data, that would
improve security there by a bit.

I've done implementations of CRIME on custom protocols a few years
back, to be effective an attacker must be able to alter parts of the
response ciphertext in order to guess using compression for the
attack. This isn't easy in SMTP as other people pointed out in the
thread already.

Of course, this is way worse with the full SMTP dialog, since the various
SMTP-level commands are even more predictable.  But at least in theory one
might be able to derive some information about the contents of messages by
using the known text in the message headers.  (In practice, I think this
would be substantially harder than CRIME.)

Most certainly. But I'm still unsure what the added value of
compression in SMTP is there. Ideally I'd like to see some
measurements, these days most messages are rather short.


Attachment: signature.asc
Description: Digital signature

ietf-smtp mailing list