Imagine this:
You work for a big company. Your job is pretty boring. Frankly, your talents are wasted writing boilerplate code for an application ...
For further actions, you may consider blocking this person and/or reporting abuse
So is the solution that you should never compress when you're encrypting? Compressing before encrypting results in the vulnerabilities discussed in this post, while compressing after encrypting doesn't result in significant savings due to the entropy of the encrypted data.
I guess you could compress data, then pad it out to a fixed length (or multiple of a fixed length), then encrypt it?
I asked basically the same question on crypto.stackexchange a little while ago: crypto.stackexchange.com/questions... The replies contain some useful details.
Thanks, this is useful information!
Honestly, I don't have a universal answer here.
I wrote this article because I kept hearing compress then encrypt as a universal answer, and wanted to point out that it can lead to data leakage.
To muddle the point even further, since writing this article I've found that there's research about encrypting first and still actually compressing (see pdfs.semanticscholar.org/372d/0dae... )
I think the answer is that you have to be aware of this when designing systems that encrypt and/or compress data...
Not sure you can conclude that: http/2 dropped gzip (or whatever it was) compression after CRIME, but replaced it with another compression algorithm (HPACK). I don't know (or have forgotten) the details of what makes it more secure though.
I don't care if this is real,write a book of short stories. You'll win.
My first guess was to encrypt before you compress because your want to keep
signal / noiseas low as possible. But then I didn't think about the effect on compression :)