Given the real risk of CRIME attacks, are there "compression aware" encryption algorithms?
I don't think it is possible - it's hard to imagine an encryption algorithm that doesn't preserve content length.
“Should you encrypt or compress first?”
181–190 of 249 posts
Re: “Should you encrypt or compress first?”
#182Earlier 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.
You can't compress after encryption. Encrypted content should be indistinguishable from random data. So encrypt than compress shouldn't be able to yield any reasonable compression.
[deleted]
Re: “Should you encrypt or compress first?”
#183Earlier 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.
"Maybe I'm too close to the problem."
Re: “Should you encrypt or compress first?”
#184Earlier quoted context omitted.
I don't understand what you mean. Your signature scheme is either secure or it isn't. If an attacker can spoof or strip the signature and have you accept it, then it isn't secure and it doesn't matter where you put it. If they can't, then you can have it be in the outermost layer.
Well the scenario I'm envisioning is that sign-then-encrypt guarantees that no signatures were stripped off in transit, that's all. It prevents people from saying that an encrypted message (which they were unable to read) came from them, even though they didn't encrypt it. I think it's probably most important in trust on first use scenarios, where an MITM in position during trust on first use can strip off a plaintex…
Encryption doesn't guarantee that the message can't be tampered with, though. In practice I believe it would be quite hard to tamper with the inner signature if you didn't have the encryption key, but relying on encryption to save you from tampering is using the wrong tool for the job. That's the whole reason you have signatures in the first place, otherwise you could just encrypt the plaintext and send it and have the fact that you knew the right key provide authentication.
Note that in the context of encryption, signatures for authentication don't mean public/private signature schemes, but just a plain MAC using a shared secret. Authentication in the sense of "Do I know I'm talking to who I think I'm talking to?" is handled at a separate level as part of the initial key exchange. For an authenticated encryption scheme, you'd exchange both the encryption key and the MAC key as part of that exchange. There's no sensible scenario where an attacker would know one of those keys and not the other, because they're generated and stored together. In fact, as far as anyone knows there's nothing wrong with using the same key for both, it's just that nobody is completely sure that's safe. Since it's easy to generate and use two keys instead, that's recommended.
Re: “Should you encrypt or compress first?”
#185Earlier 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.
You can't compress after encryption. Encrypted content should be indistinguishable from random data. So encrypt than compress shouldn't be able to yield any reasonable compression.
wit truly random data, patterns should randomly appear.
Re: “Should you encrypt or compress first?”
#186Earlier quoted context omitted.
You can't compress after encryption. Encrypted content should be indistinguishable from random data. So encrypt than compress shouldn't be able to yield any reasonable compression.
wit truly random data, patterns should randomly appear.
Re: “Should you encrypt or compress first?”
#187Can't you just add some random length data at the end. You are defeating compression a little bit, but are also making the length non deterministic. I thought pgp did that.
So long as you do not compress the random data you add it will work. Compressing it will not help the situation at all since the compression ratio will be constant for the random data. The problem is you have to then seriously negate the effects of compression.
Consider compressing "silence" in a telephone call.. You can't compress it well if you also need to have the non silence elements be indistinguishable from it by adding random noise. You must add enough random noise to cover up any compression differential, otherwise statistical artefacts still persist. That amount of random noise will be up to the maximum compression ratio you can achieve.
Re: “Should you encrypt or compress first?”
#188Earlier quoted context omitted.
That'll make an attack significantly more time-consuming, but won't prevent it. Instead of instand feedback whether they guessed correctly, an attacker would instead need to send a bunch of requests to determine if the average request size has decreased.
What if the number of padding bytes is a function of the contents?
You can achieve this effect by having the compressed content have the same length regardless of attacker input. i.e. don't include any mutable information in your compression.
Re: “Should you encrypt or compress first?”
#189The OP should take https://www.coursera.org/learn/crypto
Re: “Should you encrypt or compress first?”
#190Earlier quoted context omitted.
Why is the debate about "compress/encrypt then sign" vs "sign then compress/encrypt"? Is there a non obvious problem with sign then compress/encrypt then sign again? (overcomplicated or unnecessary?)
It's pointless. If you sign the encrypted data, then once the signature is verified in the receiver, you know that the decrypted data is also good. Repeating the signature just wastes time and space.
Compress, encrypt and then MAC. If MAC fails, don't decrypt. If decryption fails, don't (and can't) decompress. If decompression fails, throw away data, because compression-to-encryption time corruption occurred.