Earlier quoted context omitted.
@lisper Stream ciphers.
Why would you use a stream cipher to encrypt a document?
Why wouldn't you?
“Should you encrypt or compress first?”
111–120 of 249 posts
Re: “Should you encrypt or compress first?”
#112Earlier quoted context omitted.
Feel free to upload a 5MB file under your narrow restrictions and I will see if I can reduce it with one of the 20 different compression systems available to me.
The larger the random file the _less_ likely you are the successfully compress it. Everyone here is telling you that you are wrong, and have even clearly demonstrated this through both mathematical reasoning and empirical tests. Quit digging :-)
Quit digging :-)
On that note, sometimes we all get too attached to our own hard-won mistakes. We all need to remember that sometimes we should set aside pride and just say, "Whoops, my reasoning was unclear or I was misinformed, thanks for correcting my misstatent or misunderstanding."
Re: “Should you encrypt or compress first?”
#113Given the real risk of CRIME attacks, are there "compression aware" encryption algorithms?
Re: “Should you encrypt or compress first?”
#114A lot of comments here suggesting that encryption increases entropy. While true, it only adds the key's entropy to the plaintext's entropy. In most real-world cases, len(m) >> len(k), so this is usually an insignificant increase of entropy. Compression also adds a trivial amount of entropy (specifically, the information encoding the algorithm used to compress, even if that information is out of band).
I believe you confuse entropy with Kolmogorov complexity
Re: “Should you encrypt or compress first?”
#115There'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.
> If security is important, the answer to that is no It's a little more nuanced than that. Compression may cause information leaks or it can prevent them depending on the circumstances. If you're encrypting an audio stream, then compressing it first can cause leaks. If you're encrypting a document, then compressing it first may prevent leaks.
It's more about whether the attacker has control of the any portion of the compressed contents. If they have control over the stream then you don't want compression, if they don't you do.
Re: “Should you encrypt or compress first?”
#116If I compress each component (ie: attacker-influenced vs secret) separately, concatenate the results (with message lengths of course), then encrypt the whole message, is that secure?
It seems like it should be, but I'm not an encryption expert. The compression should be pretty good, though.
Re: “Should you encrypt or compress first?”
#117There'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.
The rule is: never compress something secret together with something potentially attacker-influenced. If the attacker can influence the traffic, they can potentially gather information about the secret by examining the effect of differing traffic patterns on the size of the encrypted result.
That's an excellent rule, but that doesn't cover the other example used about voice communications.
Re: “Should you encrypt or compress first?”
#118Earlier quoted context omitted.
> If security is important, the answer to that is no It's a little more nuanced than that. Compression may cause information leaks or it can prevent them depending on the circumstances. If you're encrypting an audio stream, then compressing it first can cause leaks. If you're encrypting a document, then compressing it first may prevent leaks.
Could you elaborate what kind of scenario would work on a audio stream but not on a document? In order to use CRIME, the attacker would need to repeatably injected content before the compression stage in order to test if it matches some part of the source. Audio is kind of heavy uncompressed and aren't normally streamed as such.
The original article links to a paper describing an attack against an audio stream by exploiting knowledge of how the stream is encoded before encryption, then reconstructing it from the length of the encrypted stream:
Re: “Should you encrypt or compress first?”
#119Earlier quoted context omitted.
This is exactly what the article says.
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?”
#120I picked up on the reference to Stockfighter, but does anyone know if the walking machine learning game mentioned at the end of the article exists? Sounds like a fun game.
Heh, I was referring to OpenAI Gym (https://gym.openai.com/), specifically https://gym.openai.com/envs#mujoco