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
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp