Hacker News Reader

Comment by nialo | Hacker News Reader

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.

View on HN

Seems 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.

Obvious next step: compress and pad to original length.

Obvious? 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

> 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?

D'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.

Reply on news.ycombinator.com