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.