Earlier quoted context omitted.
Does this really need to be said though? I may be too close to the problem. I've had to explain this to project managers and customers of course, but this is hacker news. It feels like a three page article on why you should put your socks on before your shoes and not after.
It's not just you. I've never used encryption or compression in any serious way, but the right answer seems obvious if you know the definitions of encryption and compression.
“Should you encrypt or compress first?”
131–140 of 249 posts
Re: “Should you encrypt or compress first?”
#132There'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?”
#133Earlier quoted context omitted.
Imagine a voice call, using a variable-bitrate codec, broken into small packets (not necessarily over the internet), of interest to a passive eavesdropper who cannot decrypt the content, but can observe metadata: the timing of packets and their sizes. Feed that information into a prebuilt phoneme-in-context model trained on that codec and language, and said eavesdropper could probably reconstruct a pretty good estima…
So, it's not just compression per se, but compression plus real-time plus some knowledge about the underlying information. These sorts of attacks don't matter against a compressed and then encrypted file of indeterminate data, correct? Similarly, an amalgamation of many types of data, such as a disk or archive?
Re: “Should you encrypt or compress first?”
#134Earlier quoted context omitted.
Imagine a voice call, using a variable-bitrate codec, broken into small packets (not necessarily over the internet), of interest to a passive eavesdropper who cannot decrypt the content, but can observe metadata: the timing of packets and their sizes. Feed that information into a prebuilt phoneme-in-context model trained on that codec and language, and said eavesdropper could probably reconstruct a pretty good estima…
So, it's not just compression per se, but compression plus real-time plus some knowledge about the underlying information. These sorts of attacks don't matter against a compressed and then encrypted file of indeterminate data, correct? Similarly, an amalgamation of many types of data, such as a disk or archive?
Re: “Should you encrypt or compress first?”
#135Earlier quoted context omitted.
Are you talking about compressing plain text larger than a block, then encrypting per each block of the compressed output?
Yes, of course. What would be the alternative?
Re: “Should you encrypt or compress first?”
#136Earlier quoted context omitted.
Does this really need to be said though? I may be too close to the problem. I've had to explain this to project managers and customers of course, but this is hacker news. It feels like a three page article on why you should put your socks on before your shoes and not after.
Cut the arrogance. It's not obvious to all of us, we're not all cryptonerds.
Re: “Should you encrypt or compress first?”
#137Re: “Should you encrypt or compress first?”
#138Re: “Should you encrypt or compress first?”
#139There may be compensating controls that invalidate the perceived needs for encryption or compression, for example. i.e. don't design in the dark.
Of course, the interviewer may just want a canned scripted answer - but the interview is your chance to shine, showing how you can discuss all the angles.
Re: “Should you encrypt or compress first?”
#140Earlier quoted context omitted.
> It wont be a huge difference in file size, but it will be smaller. may be smaller, not all outputs will be smaller, this is true of all lossless compression algorithms: https://en.wikipedia.org/wiki/Pigeonhole_principle
This is literally all I was saying and people went on a downvote frenzy. People are literally saying that a encrypted output can NEVER be compressed. I was saying that it can (although not all the time!) and the gains would be minimal. Ive corrected the first post with the word 'may'