[Top] [All Lists]

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

2016-02-08 03:58:04
On 06/02/2016 11:32, Martijn Grooten wrote:
But these attacks also show that compression and encryption don't go well together. And crypto is hard and provides plenty of opportunities to mess up. For that reason, I would suggest following TLS 1.3 and not combine the two, as it would teach people bad habits. Martijn.

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.

So, if you came up with a compression algorithm and gave me the compressor but not the decompressor, I could still (potentially) work out what some compressed data is by using the 'CRIME' method. The encryption acting on top of the compression essentially converts the known compression algorithm into an unknown one (unless you know the decryption key).

(I may totally be misunderstanding it, but from what I've read, that seems to be the case).

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 compression.

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.

ietf-smtp mailing list