Picking an encryption algorithm for auth tokens passed via AJAX

Question

I'm looking for a low CPU intensive encryption algorithm, to pass around session authentication tokens.

As an example:

• The user will login in to the website (via OAuth, whether by the site as provider or an external provider)
• Regardless of how they were originally authenticated, a new, randomly produced session token (in this case a 64 character length string) is associated with their account and is stored in a cookie.
• On each new page request, the session token is taken from the cookie, encrypted with a time-based nonce (to prevent replay) and placed in the headers as a meta tag and rendered.
• The user does something which fires off an javascript AJAX request to the site's API. The javascript picks up the encrypted token from the meta tag.
• The API receives the params, takes out the encrypted info and decrypts it.
• Stuff happens…

Obviously, this could end up in a lot of encryption. Granted, the data will only be small, but it's the volume that worries me. To that end I'm looking for an encryption algorithm that:

• Is low on the CPU use
• Widely available would be nice.
• Easy to use would be nice.

I've had a look around, but the detail of some of the comparisons I've seen is beyond my knowledge to be entirely helpful. If anyone could give a suggestion, that would be helpful. Also, if anyone sees a glaring hole with the security in the above example, please let me know.

---

Extra info due to the comments:

• SSL would be used for all communication.
• The (whole) cookie is encrypted using AES. The specific key value pairs are not.
• I don't wish to manipulate the value using the browser, I want the already encrypted value to be sent via AJAX and then decrypted server side in the data API.
• I don't wish the user themselves to have access to an unencrypted session token.
• Most state is kept in the database, the session token is just there to let the API know who's making requests. Barely anything else is kept client side.

The main reason for this kind of set up is to allow many different clients to access the API via HTTPS, whether it's web or mobile or whatever, so the data API server may not reside on the same box as the website, and the website has no direct access to the database.

Answer 1

Your use case is a bit strange. As a basic rule, you need SSL if the data you exchange between the server and the Ajax client is sensitive in any way; you need it both for confidentiality and for integrity. And if you have SSL, then you have all that you need; in particular, you defeat replay attacks (that's a feature of SSL).

You would have to fiddle with encryption only if you want to offload some of your storage on the client; that is, you maintain some user-specific state but do not want to pay for the corresponding database. Instead, you send that state to the client itself, to be stored either in a cookie or in the entrails of the RAM objects maintained by the Ajax code. In that specific scenario, the client is a potential attacker, and you want that storage to be protected with both encryption and integrity, and with an additional time stamp or counter. That's still a rather edge case and it is hard to get right; it is much easier to simply store the user state in the server's database.