<div dir="auto"><div dir="auto"> Den sön 7 nov. 2021 07:05Peter Gutmann <<a href="mailto:pgut001@cs.auckland.ac.nz" target="_blank" rel="noreferrer">pgut001@cs.auckland.ac.nz</a>> skrev:</div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Christian Huitema <<a href="mailto:huitema@huitema.net" rel="noreferrer noreferrer" target="_blank">huitema@huitema.net</a>> writes:<br>
<br>
>The general guidance that I read is "don't do that, because compressing<br>
>different clear texts results in different compressed lengths, and the<br>
>adversary can use the length to guess the message." But then, by definition,<br>
>compression reduces the entropy of the compressed plain text, which makes the<br>
>heuristics that you describe here harder. So, what gives?<br>
<br>
"Don't compress before encryption" applies to specific very carefully-chosen<br>
examples for conference papers (CRIME, BREACH, etc).  "Compress before<br>
encryption" applies to real life.<br></blockquote></div><div dir="auto"><br></div><div dir="auto"><span style="font-family:sans-serif">I wouldn't dismiss it that readily.</span><div dir="auto" style="font-family:sans-serif"><br></div><div dir="auto" style="font-family:sans-serif">Compression before encryption is a problem whenever secret data does not have strict domain isolation from attacker controlled data while compression is applied, which is the case especially in web browser based interactive protocols, and worsened in interactive protocols by the fact that the adversary gets multiple chances and can test a variety of patterns. </div><div dir="auto" style="font-family:sans-serif"><br></div><div dir="auto" style="font-family:sans-serif">On websites it's not uncommon to encounter ads with Javascript which may be malicious.</div><div dir="auto" style="font-family:sans-serif">Some of which might secretly try to recover your session secrets by watching for how packets gets compressed differently as the compression algorithm finds recurring patterns of different complexities in between the secret values and the attacker controlled iterating value (this is the short summary of how BREACH/CRIME works).</div><div dir="auto" style="font-family:sans-serif"><br></div><div dir="auto" style="font-family:sans-serif">Tldr if you isolate *all* secrets from attacker controlled values before compressing, especially in interactive protocols, then it can be done (more) safely.</div><div dir="auto" style="font-family:sans-serif"><br></div><div dir="auto" style="font-family:sans-serif">You can optionally improve safety a bit more by padding to predetermined multiples of a given minimum message length (perhaps even predetermined message lengths at logarithmically spaced distances, revealing less for longer messages).</div><div dir="auto" style="font-family:sans-serif"><br></div><div dir="auto" style="font-family:sans-serif">Or you can just decide not to compress packets for interactive protocols, which the major browsers has done. </div></div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div>