It works great, so far everything seems to run smoothly and it wasn't really difficult to implement. The basis is still around the idea of a shared encryption key, which is never really transmitted except during the account creation process. This seems like a decent idea, I will need a chance to clean it up and attempt to implement a few more jazzy options such as encrypting arbitrary data for the communication instead of just a session key.
Also, as of right now a session and session key are all that is needed, with those one could potentially do man-in-the-middle by altering any other post/get parameters. To combat this I will be working to add a checksum into the unprotected parameters such that if anything is altered it will not match and would refuse to process. The only minor problem I have yet to consider a workaround for is dealing with the fact a person could take a given session/session key and pound the server with thousands of requests with slightly altered session keys. Since the session will wait for the correct key it is potentially possible for the correct session key to be guessed for the next session and it would then be accepted. I guess having the session always increment to the next expected value even on a bogus request would keep that from happening at the cost of broken sessions for the user when someone attempted to hijack theirs.
I have other updates to come, just need to get some stuff done before I write them up.