[Cryptography] quantum computers & crypto

[Natanael]

 Den sön 7 nov. 2021 07:05Peter Gutmann <pgut001 at cs.auckland.ac.nz> skrev:

> Christian Huitema <huitema at huitema.net> writes:
>
> >The general guidance that I read is "don't do that, because compressing
> >different clear texts results in different compressed lengths, and the
> >adversary can use the length to guess the message." But then, by
> definition,
> >compression reduces the entropy of the compressed plain text, which makes
> the
> >heuristics that you describe here harder. So, what gives?
>
> "Don't compress before encryption" applies to specific very
> carefully-chosen
> examples for conference papers (CRIME, BREACH, etc).  "Compress before
> encryption" applies to real life.
>

I wouldn't dismiss it that readily.

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.

On websites it's not uncommon to encounter ads with Javascript which may be
malicious.
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).

Tldr if you isolate *all* secrets from attacker controlled values before
compressing, especially in interactive protocols, then it can be done
(more) safely.

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

Or you can just decide not to compress packets for interactive protocols,
which the major browsers has done.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20211107/8da7f99f/attachment.htm>