<p dir="ltr">Den 9 jan 2015 18:34 skrev "Stephan Neuhaus" <<a href="mailto:stephan.neuhaus@zhaw.ch">stephan.neuhaus@zhaw.ch</a>>:<br>
><br>
> Dear list,<br>
><br>
> I have come across the recommendation to "compress before you encrypt", on the grounds that this makes plaintext recognition through frequency analysis much harder.<br>
><br>
> However, compression algorithms surely have easily recognisable headers, right? </p>
<p dir="ltr">It is a question about entropy density here. Known-plaintext attacks usually rely on knowing multiple blocks where you know with high certainty what the plaintext is. RC4 suffers from this, breaking it goes do fast for WEP because you know so much plaintext (most content in all WiFi and TCP/IP headers and HTTP headers), and because you can make statistical guesses about the plaintext (a whole lot of English).</p>
<p dir="ltr">This is because knowing that plaintext allows you to extract biases from the key stream, which reveals the encryption key. Compressing all plaintext hides those biases since it is harder to guess the individual bit values of compressed data than for raw data. </p>
<p dir="ltr">> Also, I seem to recall a paper that did interesting things with encrypted compressed plaintext, but I can't recall any details.<br>
><br>
> So, does any one know what paper I might be referring to?  Or is there any other hard evidence (not personal opinion, however well-informed, please) that compression before encryption does or does not help?<br>
><br>
> Thanks in advance,<br>
><br>
> Stephan</p>
<p dir="ltr">That's probably BEAST and CRIME for HTTPS, which turns the browser into an encryption oracle. The problem here is that the attacker controls a large fraction of of the plaintext, and can watch the sizes of the compressed ciphertext. Because  attacker controlled strings with substrings in common with the secret strings equals shorter compressed outputs, and thus shorter ciphertext, the attacker can do Hollywood style bruteforce and guess AAAAAAAA, then AAAAAAAB and watch the ciphertext get shorter as he gets more and more of the secret plaintext right. </p>
<p dir="ltr">This would typically target session cookies as they are sent with every HTTP request. All secret plaintext which the attacker can cause to be resent is a potential target. Javascript from malicious ads would be the most likely attack vector. </p>