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.

  • 1
    What's wrong with standard block ciphers like AES? On modern CPUs the overhead is minuscule.
    – Polynomial
    Feb 4, 2013 at 13:20
  • @Polynomial I don't know, which is why I asked the question :)
    – ian
    Feb 4, 2013 at 13:20
  • Beware : manipulating cookies with javascript will prevent you from using http only cookies, which increases the risk associated with cross-site scripting (XSS). Complexity is the ennemy of security.
    – ixe013
    Feb 4, 2013 at 14:13
  • 1
    Should you decide to do cryptography in the browser, you might want to look at the Stanford Javascript Crypto Library.
    – ixe013
    Feb 4, 2013 at 14:14
  • 1
    @ixe013 I don't wish to do any client side manipulation, but thanks for the link, very helpful. I've updated my question too to make it clearer.
    – ian
    Feb 4, 2013 at 14:40

1 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.

  • Thanks for the answer. I've updated the question with a few things that may or may not clarify things.
    – ian
    Feb 4, 2013 at 14:39
  • Having mulled it over I agree, there's no need to encrypt an identifier that is randomly generated and reasonably often regenerated. I suppose I'm just paranoid :)
    – ian
    Feb 6, 2013 at 14:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .