41–50 of 249 posts
I thought this was common sense. Compress then encrypt. Encryption leads to higher entropy, therefore less effective compression.
Compressing then encrypting gives you more effective compression and (somewhat) less effective encryption. Encrypting then compressing gives you more effective encryption and less effective (almost ineffective) compression. So, depends which one you want more. :)
A more interesting question is whether to compress or sign first. There's an interesting article on that topic by Ted Unangst: "preauthenticated decryption considered harmful" http://www.tedunangst.com/flak/post/preauthenticated-decrypt... EDIT: Although the article talks about encrypt+sign versus sign+encrypt, the same argument goes for compress+sign versus sign+compress. You shouldn't do anything with untrusted dat…
I 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…
I thought this was common sense. Compress then encrypt. Encryption leads to higher entropy, therefore less effective compression.
Compressing then encrypting gives you more effective compression and (somewhat) less effective encryption. Encrypting then compressing gives you more effective encryption and less effective (almost ineffective) compression. So, depends which one you want more. :)
There's no compress or encrypt _first_. It's just compress or not, before encrypting. If security is important, the answer to that is no, unless you're an expert and familiar with CRIME and related attacks. Compression after encryption is useless, as there should be NO recognizable patterns to exploit after the encryption.
Not to nitpick, but this is incorrect. A encrypted file can very well have something like 100 X's in a row which the compression system could turn from XXXXXXXXXXXXXXXX.... into (100 x's go here) - Lousy example I know but it gets the point across.
Its also easy enough to test- Just encrypt a file then compress it. Sometimes it will be smaller. (Your reply indicated that in 100% of attempts compression is impossible)
Would adding some tiny random size help? Based on my poorly understanding, if after compress, but before encrypt we add random 0 to 16 bytes or 1% of size that could defeat quite a lot of attacks (like CRIME).
A more interesting question is whether to compress or sign first. There's an interesting article on that topic by Ted Unangst: "preauthenticated decryption considered harmful" http://www.tedunangst.com/flak/post/preauthenticated-decrypt... EDIT: Although the article talks about encrypt+sign versus sign+encrypt, the same argument goes for compress+sign versus sign+compress. You shouldn't do anything with untrusted dat…
I think, you mean whether to encrypt or sign first.
Although the article talks about encrypt+sign versus sign+encrypt, the same argument goes for compress+sign versus sign+compress.