cryp.sr is an experimental minimal host-proof cryptographic list manager. It has no authentication, uses no cookies, no email is required for registration, and your password never leaves your browser. All encryption is done in Javascript on the client side - the cryp.sr server simply stores an opaque blob of data. There's a blog post describing the initial idea here, and another one about cryp.sr's subsequent evolution here.

cryp.sr, like all host-proof applications, relies on a community of users to provide peer review. The client-side code for cryp.sr is published here. You should also know about the #crypsr hashtag on Twitter, which is where you should blow the whistle if you notice any skullduggery. I will announce application updates and new hashes using this hashtag from the @crypsr account.

I've also published AppHash, a FireFox addon that helps you verify that a host-proof application matches a known hash. The source for AppHash lives on github. AppHash is a (cumbersome) first stab at host-proof app verification, which is an unsolved problem at the moment.

The primary intent behind cryp.sr is to have a flexible host-proof platform on which to try out some new ideas relating to host-proof applications. Keep watching this space for further developments.

"Experimental" is also code for "I won't be too afraid to piss off my users a little". Commercial host-proof applications don't have this luxury, and I think that innovation has stagnated as a consequence.

Not really, but lets make a deal:

• I will give 3 months advance warning if I ever plan to shut cryp.sr down.
• You promise not to abuse the service in any creative way.
• I may delete pads that haven't been accessed for 6 months or that show "unusual activity", where "unusual activity" means anything I consider to be creative abuse.
• You realise that your encryption password is your responsibility. If it's weak, the baddies will pwn your data. If you lose it, the contents of your pad are _gone_ - by its very nature, cryp.sr has no way to reset your password.
• If something dire happens - say, a security hole in the jsCrypto key generation function - I will destroy all user data rather than leave vulnerable pads online. So keep a copy of your cryp.sr pad somewhere.
• Lastly, I make no guarantees whatsoever. It's perfectly possible that cryp.sr will wipe your hard disk, email your porn stash to your mother, and then post the contents of your pad to /b/. The only thing protecting you from this horrible fate is peer-review of the cryp.sr client application, so it would be a good idea to pitch in and help sanity-check it.

Each locker is assigned a write key. That key is prepended to your locker data, and encrypted with your password. When you access your locker, the application picks up the write key from your decrypted data. This is all totally transparent to the user, but the upshot is that (after the first time you save your data) you can only write to a locker if you've already succesfully decrypted the locker contents.

All the cryptographic paraphernalia is provided by SJCL. I use AES in CBC-mode to encrypt data. Keys are derived with SJCL's implementation of PBKDF2. I also use SJCL's Fortuna pseudorandom generator, fed by entropy from mouse movement. SJCL is still pretty raw - if you're interested in crypto, please take some time to give it some peer review.

Yes. The point of departure for a host-proof application is that we don't trust the host. Exposing encrypted user data to the world forces us to think honestly about the implications of this stance. For example, an offline attempt at cracking encrypted pads is a near certainty - so I recommend that you choose a passphrase with a full 128 bits of entropy. The cryp.sr client can generate a strong passphrase for you. It will have 23 characters so memorizing it might not be fun, but don't worry - Bruce Schneier says you can keep it written on a slip of paper in your wallet.

Just save the page from your browser. The pad page has no external dependencies at all, so your encrypted data will be stored to disk. When you view the file, you'll be prompted for your password to decrypt the data. Note, though, that you won't be able to save data back to the server from an offline copy.

There's a 100k data size limit.

Javascript encryption is taken care of by the SJCL library. Interactive UI features were written using jQuery.