Yes, cookies come from the server. But the point of encrypting and all this rigmarole, is if you put user data, other than a number, inside a cookie. Assume that not a password, but if someone's age, maybe their login and some other info is in there for SOME reason. Either for performance reasons, not having to deal with clustering.. there is always a reason someone may want to do it. Heck, even a timestamp.

Yes, compress before encryption. Not after. I thought I said that, but if I was confusing, yes, we agree on that. Compression for size doesn't help all that much, 'cause you are right. Small data won't compress that much smaller percentage wise, but you still get the obfuscation, which is a bigger selling point.

But, the point of the exercise is, giving people some data and at the same time, keeping it private for some "good" duration. Not forever. given infinite time, any encryption scheme would be breakable, except for one way hashes. After all, a hash doesn't guarantee against collision... usually.

And yes, allowing modification of the data in the cookie is bad. More reason to compress, md5 the compressed part, take the two and encrypt that together. Thus, if you change one block, either the md5 gets mucked, or the data gets mucked. But the md5 of the data block will no longer be valid. Mathematically, you'd be more likely able to brute force and may even cryptoanalize (horrid spelling there :) the data before you can generate one that respects an md5, compression and encryption all in one.

The comperssion and what not does make things harder. I think we agree on that. But if you have to put some data out there because of some requirement, it's best to do it the best way you can do it.