Putting aside the work itself of creating a UI (this is just a simple install guide), that's not possible without exposing the encfs keys to the remote server. In this setup the client data is all encrypted before it reaches the server. The server is just a sync point for multiple clients.
You could have a UI (web or otherwise) on a separate client but it would have nothing to do with the server. It would just be a client that provides a UI interface to the decrypted encfs filesystem.
Theoretically, it should be possible to have a web UI running on the server itself. You just need a decent AES implementation in Javascript to do client-side decoding of filenames and files. Any volunteers? :-)
I've looked into this before and concluded it was possible, although I forget exactly how.
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.
It's a really interesting idea (and sounds really fun to build) but a bad idea from a security perspective. Javascript crypto in the browser just doesn't make sense[1].
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.
Err I don't think this would stop me. But let me preface this by saying I learn something new about security quite frequently, so if there's a major premise I'm missing, I am both interested in learning about it and not completely surprised.
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.
On the contrary go right ahead. Learning through doing is the way to go. I'm just saying there's a big difference between testing/learning/prototyping and releasing something that is claimed to be secure. Otherwise you end up with Cryptocat[1].
> Even with that possibility though, I still think using browser-based crypto creates a more secure environment than the server storing unencrypted files.
If you're using any JS then you have to completely trust the server that is serving it. At any point the server could replace "good.js" with "bad.js" and the browser will happily execute it. Any encryption you perform on the client side would be moot as "bad.js" could do whatever it wants with your plaintext and your encryption keys.
> 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.
Again you're trusting the server to not save your encryption keys though by serving you "good.js" and not "bad.js"! All roads lead back to you trusting the server to play nice.
Unless you use untrusted remote services as opaque object stores and handle all encryption via secure code on the client side with proper signatures to prevent remote tampering[2], you're trusting the server not to compromise you.
[2]: Tarsnap (https://www.tarsnap.com/) is a perfect example of a client not trusting the server. The tarsnap service stores it's data on S3 but first all data is encrypted client side on your own machine. From the tarsnap service's perspective it's just storing a bunch of random binary blobs and that's all your client sends/recieves. Encryption/decryption happens locally on your machine.
You could have a UI (web or otherwise) on a separate client but it would have nothing to do with the server. It would just be a client that provides a UI interface to the decrypted encfs filesystem.