Earlier quoted context omitted.
The article is about why that can be wrong.
But in almost all cases it's right.
"Don't compress at all" is the better default answer.
Noting that "compression after encryption is stupid."
“Should you encrypt or compress first?”
21–30 of 249 posts
Re: “Should you encrypt or compress first?”
#22So if the length of the resulting message is leaking information, salt it by adding some extra random bits to the end to increase the length by a random amount.
Re: “Should you encrypt or compress first?”
#23This blog is an interesting way to advertise to their target market: us.
By eliciting damnfool responses from people that haven't read the article?
Re: “Should you encrypt or compress first?”
#24Logically 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.
> Compressing the source material will yield smaller results but will be more predictable
This depends on the susceptibility of the ciphers to known-plaintext attack; I'm not sure if today there are scenarios where using such ciphers makes sense.
Re: “Should you encrypt or compress first?”
#25Earlier quoted context omitted.
But in almost all cases it's right.
"Don't compress at all" is the better default answer. Noting that "compression after encryption is stupid."
The correct default answer is encrypt after compress.
"Don't compress at all" doesn't help you if you need to reduce bandwidth.
What good is a secure channel if no one uses it because of its high bandwidth requirements?
Re: “Should you encrypt or compress first?”
#26There'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.
This is exactly what the article says.
Re: “Should you encrypt or compress first?”
#27Earlier quoted context omitted.
"Don't compress at all" is the better default answer. Noting that "compression after encryption is stupid."
The correct default answer is encrypt after compress. "Don't compress at all" doesn't help you if you need to reduce bandwidth. What good is a secure channel if no one uses it because of its high bandwidth requirements?
A lot, possibly a majority, of the major breaks in crypto systems (certainly the interesting ones) in the past decade have been because of compressing before encrypting. If someone wants to compress first, demand that they justify the reduced bandwidth usage.
Re: “Should you encrypt or compress first?”
#28Re: “Should you encrypt or compress first?”
#29A 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 data before having checked the signature - neither uncompress nor decrypt nor anything else.
Re: “Should you encrypt or compress first?”
#30There'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.
This is exactly what the article says.
The troublesome part is the headline.