12 ms·
This is the obvious intuitive response, but it turns out that it's broken: Compressing data before encryption can give attackers a new side channel to recover
by nialo 13y ago
This is the obvious intuitive response, but it turns out that it's broken: Compressing data before encryption can give attackers a new side channel to recover the plaintext, by just watching the message length, and seeing when the compression is more or less effective. See, for example, the CRIME attack on TLS.
- p0ckets 13y agoObvious next step: compress and pad to original length.
- rmidthun 13y agoObvious? Didn't that word already cause enough trouble? What are you going to pad it with? Random values? In that case, I'll just make two requests for the same information and clip it where they differ. Some sort of value based on the message? That also has issues, see link below. So far it doesn't seem like there are any obvious crypto ideas that are not also wrong. http://en.wikipedia.org/wiki/Padding_oracle_attack http://en.wikipedia.org/wiki/Padding_oracle_attack
- nknighthb 13y ago> I'll just make two requests for the same information and clip it where they differ. So, byte 0? You're not really using ECB, are you?
- rmidthun 13y agoD'oh. Good point. At least I can point to it as another example of someone not expert in the field making a stupid statement about crypto... I think the general problem of padding with random values resulting in non-determinism would still matter in some cases, but IANAC.
- Tloewald 13y agoSeems to me that the inherent problem here was that you could get the sender to send messages of your choosing, which is always going to be a vulnerability. Consider that this entire line of discussion is redundant if (a) the encryption key is public (as stated above) or (b) you know what the plaintext looks like for some encrypted examples.