“Should you encrypt or compress first?”
blog.appcanary.com
“Should you encrypt or compress first?”
1–10 of 249 posts
Re: “Should you encrypt or compress first?”
#2I don't understand... Why couldn't you do CRIME with no compression as well? Assuming you can control (parts of) the plaintext, surely plaintext+encrypt gives you more information than plaintext+compress+encrypt?
Re: “Should you encrypt or compress first?”
#3I thought this was common sense. Compress then encrypt. Encryption leads to higher entropy, therefore less effective compression.
Re: “Should you encrypt or compress first?”
#4If you're compressing audio, the simple solution is to compress using constant bitrate.
Re: “Should you encrypt or compress first?”
#5Logically speaking, an encrypted file should have a high entropy set of bits within it. Compressing it would be low return, but higher security since the input file contained more "random" bits.
Compressing the source material will yield smaller results but will be more predictable as the file will always contain ZIP headers and other metadata that would possibly make decryption of your file much easier.
Re: “Should you encrypt or compress first?”
#6I thought this was common sense. Compress then encrypt. Encryption leads to higher entropy, therefore less effective compression.
The article is about why that can be wrong.
Re: “Should you encrypt or compress first?”
#7I thought this was common sense. Compress then encrypt. Encryption leads to higher entropy, therefore less effective compression.
Did you read the article?
Re: “Should you encrypt or compress first?”
#8I don't understand... Why couldn't you do CRIME with no compression as well? Assuming you can control (parts of) the plaintext, surely plaintext+encrypt gives you more information than plaintext+compress+encrypt?
Crime relies on compression --- the "CR" stands for "Compression Ratio"
The idea is that the DEFLATE compression algorithm used in the TLS compression mode CRIME attacks will build and index of repeated strings and compress by providing keys to that index.
Here's a beautiful demonstration of another similar compression algorithm: http://jvns.ca/blog/2013/10/24/day-16-gzip-plus-poetry-equal...
So, if you control some subset of the plaintext you can make guesses as to what the secret you're trying to get at is, and if the size changes after compression you know that you got two hits to that bucket in the index, so your guess is right. You can use this technique to guess some string character by character -- reducing your seach space to n*m instead of n^m for a string of length m with character set of length n.
Re: “Should you encrypt or compress first?”
#9Logically speaking, an encrypted file should have a high entropy set of bits within it. Compressing it would be low return, but higher security since the input file contained more "random" bits. Compressing the source material will yield smaller results but will be more predictable as the file will always contain ZIP headers and other metadata that would possibly make decryption of your file much easier.
It's not just the headers. You could strip those off and count on the other side to put them back on.
It's that the act of decompressing arbitrary data can leak very important information to the attacker.