Compress before encryption. Not in place. Please reread my node.

You typically dont' want the private data read as it may contain sensitive information.

Of course, encrypting the line is wanted. But the point is on just having a cookie outside of the wire transmition. After all, encrypting any line will make it more secure. :)

Secret keys, regardless of MAC, can be broken. Don't forget that key point.

Chosen plaintext attacks don't really apply since the data in cookies come from the server. The server doesn't usually encrypt data fed from an attacker. Modern secret key ciphers are resistant against chosen plaintext attacks and brute force tends to be the best attack. They are, by far, the most secure part of any system.

Compress before encryption means to doing the compression before encryption, because doing afterwards is useless since ciphertext is uncompressable. It does not mean you have to use compression. Compression does provide some benefit by hiding the plaintext a little bit. Since cookies are so small, compression isn't all that useful.

I would say encrypting sensitive information in the cookie is silly. Either the info is sensitive, and shouldn't be put in a cookie, or it isn't and can be plaintext. For most applications, authentication is more important than hiding secrets. For example, a cookie that contains a username for authentication, leaking the username to eavesdroppers is a privacy problem. Allowing someone to tamper with or replay the cookie is a major breach.

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.

Bart: God, Schmod. I want my monkey-man.

You linked to a page titled "What is a chosen plaintext attack?" I don't see how compression is going to protect you from chosen plaintext attacks. If someone can choose plaintexts that will break your cryptosystem, it's not that much more work for them to choose plaintexts that compress to strings that also break the system.

The page also displays a lack of understanding of what a chosen plaintext is, and ignorance of the history of the Enigma machine. Find a new source of information.

Page 226 of applied cryptography. "Cryptanalysis relies on exploiting redundances in the plaintext; compressing a file before encprytion reduces these redundancies..." furthermore "The important thing to remember is to compress before encyption. If the encyption algorith is any good, the ciphertext will not be comprehsible; it will look like random data."

It is more work if a secondary algorithm adds noise. It's like tunning a radio to a station in another language by ear, while a jackhammer is going off. Sure, you may hear enough to get close just to tunning it to a station if you can hear anything at all. The sound of the radio is still there. Unfortunately, it's mixed in with other noise.

If that example doesn't jibe, think of it like trying to read text across a mirror. It comes up backwards, but if you put some concentration behind it, sure, it's easier. Now put on a pair of glasses that aren't yours, maybe something that fish-eye's. it gets even harder. The information is there still, you just can't perceive it proplery unless you break one of the "encryptions", namely reversing the effect of the fisheye first.

in both cases, it's twice the work to get to what you once had. Encrypting twice, as long the tail end of the pipe (weak encrypt then hard encrypt) makes plaintext attacks harder. It compounds the problem.

You dont' have to trust me. I don't have over 2 decades of experience quite yet, but coming close. I am not a "crypto freak", though I am familiar with the topic through various studies. It is why I haven't disagreed with you since I do recognize things like MAC, or just not presenting the data at all. If it's not there, hiding even the clue that you are mapping a user (which by using a cookie, you kinda are breaking that rule), you have nothing to worry about. But, I do trust people like Bruce Schneier (author of A.C.) and various professors, who have minimally 13 years more experience and/or specializations in the topic.

Bart: God, Schmod. I want my monkey-man.