The short answer. Your mechanism is too complicated. There is a simpler, better, more secure solution: use SSL site-wide, and set the
secure bit on all your cookies so they will only be sent over encrypted (SSL) connections.
Technical nitty-gritty. If you really want to discuss your proposed mechanism, we can talk about it, but I think the specific technical shortcomings in it are secondary to the more general point that there's a simpler, better way to do it. Here are some specifics:
If you fix these flaws, your proposal is not entirely unreasonable. For instance, ASP.NET supports encryption and authentication of cookies using a MachineKey.
However, I do not recommend you take this path. While you could probably fix these flaws given engouh effort, I'd suspect the complexity of inventing how to do this properly is probably more than you are qualified for. This is tricky stuff, and it would be easy to get something wrong. (For instance, witness the devastating flaws in ASP.NET's encryption, which allowed padding-oracle attacks to decrypt everything and defeat the security of all of the crypto.)
General advice. Instead of trying to do something funky with encrypting your cookiess, I'd suggest the following advice:
Generally speaking, be reluctant to store state in cookies. Instead, store it in the session or in the database. That way, all you need is a session cookie.
Use your web programming framework's built-in session management support; don't try to roll your own. (If you try to roll your own, you can easily end up with vulnerabilities like session fixation.)
Use SSL sitewide. Set the
secure flag on all cookies.
Use CSRF defense for all POST requests. Make sure that all GET requests have no side effects (side-effecting requests should be sent as POSTs).
Read OWASP's materials on web application security.