views:

18

answers:

1

I'm developing a journal web app and am trying to tackle what I foresee as the biggest problem - trusting me not to read other people's entries. The solution I have so far is:

  • User gives a secret key each time they login. It is not stored with their user data and is only kept for the lifetime of the session.
  • Each entry the user writes is encrypted using this key. Similarly when they try to open an entry the entry will be decrypted using this key.
  • If an incorrect key is entered the entries given will be returned as jibberish, however this will allow the user to store entries with different keys if they wish to do so.

While the trust is then on me to not record the keys (I hope to distribute a single-user version later on which will feature the same code) I can't help thinking there is either a more common way to do this or to a flaw in this thinking somewhere (I am not very knowledgeable on security or encryption other some probably flaky understanding of md5/sha1/blowfish). Is this the best way to go about this?

+3  A: 

This is one of the rare cases where performing encryption and decryption client-side (via JavaScript) might make sense.

Encryption with a user key will protect journal data "at rest." But if I'm really paranoid, I won't trust you not to snoop on my journal entries "in flight," before they are encrypted and stored at the server. Client-side encryption eliminates that worry.

There are several JavaScript encryption libraries available. I recommend looking at JavaScrypt.

erickson
Here is an example of a web service with client-side encryption: http://www.spynote.com/about.php It uses JavaScript on client side; server side is just a DB that stores and retrieves opaque blobs of data. [Disclaimer: I'm not affiliated with that service in any way]
atzz
This looks pretty good. I'm not too sure about adding a JavaScript dependency (I browse with NoScript on) but I'll certainly add a user preference to do this.
Ross