- From: Willy Tarreau <w@1wt.eu>
- Date: Tue, 12 May 2015 21:25:56 +0200
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Amos Jeffries <squid3@treenet.co.nz>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
On Tue, May 12, 2015 at 12:07:03PM -0700, Martin Thomson wrote: > On 12 May 2015 at 11:01, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > > 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. > > Not that this is practically relevant, but you can actually compress > encrypted data. There's a paper proving that it's possible from about > 10 years back. It's certainly not gzip though. For sure you can, the best demonstration is that by chaining the decryption to a generic compression algo, you'll get the same compression ratio as before encrypting. So *at least* one operation exists that way. But others certainly do as well, as encryption doesn't add entropy, it just makes it much harder to recognize the original data. I would not be surprized if people who invent crypto algorithms would also be able to invent filters for their algorithms that help to compress the data (or invent the two at once in order to satisfy both purposes). Willy
Received on Tuesday, 12 May 2015 19:26:38 UTC