- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Tue, 12 May 2015 18:01:56 +0000
- To: Martin Thomson <martin.thomson@gmail.com>
- cc: Amos Jeffries <squid3@treenet.co.nz>, Willy Tarreau <w@1wt.eu>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
-------- In message <CABkgnnUeGLen+UsFmuAB5Y_cao0M9q-5nebwzN2KTxEix_V+vQ@mail.gmail.com> , Martin Thomson writes: >On 12 May 2015 at 10:44, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: >> aesbla(gzip(plaintext)) >> >> since that would leak information, and she should *absolutely not* >> be able to force this distinction herself by sending an >> Accept-Encoding header. > >The current consensus is that applying compression before encryption >is not generically safe anyway. The operative word there being "generically": The application knows what is being encrypted, and can therefore take appropriate countermeasures (padding, filling, selectors, decoys etc.) This is why we should never allow encrypt(gzip(who_knows_what_kind_of_data)) And therefore, "C-E: gzip" must always happen after encryption, because we are always dealing with who_knows_what_kind_of_data. And therefore "C-E: gzip" does not make any sense if you have encryption (unless somebody invents an encryption where the ciphertext is base64 or similar) but it is just a harmless waste of electricity, it is not a security-hole. >because order matters for C-E. It describes the order of application >of the transforms. That order is at the sole discretion of the >server. I believe that A-E is not ordered in the same way, so >coercion doesn't seem to be an option. If A-E allows you to pick and choose if you want aesbla(plaintext) or aesbla(gzip(plaintext)) I'm not sure I would call it "Coercion", but I'm sure my card-carrying cryptographer friends would call it "utterly broken". -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Received on Tuesday, 12 May 2015 18:02:20 UTC