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?
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.
Security Director at ForgeRock.
Author: https://www.manning.com/books/api-security-in-action
Cryptography and application security. PhD in AI. Secret Prolog junkie.
I asked basically the same question on crypto.stackexchange a little while ago: crypto.stackexchange.com/questions... The replies contain some useful details.
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...
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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?
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 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...