Edit: Looks like someone is already working on it: http://stackoverflow.com/questions/10909500/use-encfs-with-j...
I bookmarked https://crypton.io/ and http://peerjs.com/ . PeerJS is p2p WebRTC, which I believe I chose because I wanted to do secure, real-time p2p file sharing.
That isn't 100% relevant for this, but downloading the file over some socket into client-memory then decoding it there sounds like something webrtc could be a good option for.
Crypton handles the crypto.
I think the biggest thing someone who tackles this needs to realize is that perfecting the crypto doesn't matter 100%. If you could get something working that's doing some kind of encryption/decryption without exposing anything to the server, crypto experts will come in and help secure everything (see: mega)
Edit: I should mention that I didn't research this extensively, and better libraries might be (and probably are) available.
Summary of the link: Since you trust the server to serve the JS files, you might as well trust it to do the decryption and present it all over SSL.
> I think the biggest thing someone who tackles this needs to realize is that perfecting the crypto doesn't matter 100%. If you could get something working that's doing some kind of encryption/decryption without exposing anything to the server, crypto experts will come in and help secure everything (see: mega)
This is an especially bad idea. Application that perform crypto should be designed properly from the start. It's not something you can just patch on later. Building crypto programs to learn/test/explore is fine but building a product for actual usage and then expecting others to fix it after the fact is a terrible approach.
[1]: http://www.matasano.com/articles/javascript-cryptography/
The main issue here is that your Javascript can potentially be owned by XSS or other approaches. If you own the javascript, you can send plaintext passwords or keys (which should have only been available to the client) back up to some server.
Even with that possibility though, I still think using browser-based crypto creates a more secure environment than the server storing unencrypted files. The author makes a good point in saying that you download javascript on each request, which makes it more susceptible to getting owned than a native-app, but I think a successful attack with this approach will still be an order of magnitude less severe than if an attacker owned a server full of unencrypted data. If the data is unencrypted, an attacker that manages to own the server has access to everyone's data. With it encrypted, the attacker will only get data from users who are using the site while it's owned.
Isn't that still a better option?
