HN Explorer

Ask HN: Which technology should I use for client-side web encryption?

5 points by lukev ↗ HN
I'm moving forward with developing a prototype of a cryptographically secure social networking site/messaging service/photo service.

All encryption will take place on the browser, using Open PGP standards. The server will see only encrypted data.

I can't decide between using Javascript/HTML5 and a hidden Java applet to do the bulk of the work.

Advantages of Java:

* Much faster for bitwise crypto operations (a significant concern).

* With the right permissions, it can load files directly from the hard drive and encrypt them in memory. As far as I know, this isn't possible with Javascript - the only way to upload a file is to submit it directly to the server though a form. This could be a dealbreaker for Javascript - though alternatively, I could use Java for only this specific task and everything else could be in JS.

* I can use direct socket communication to reduce latency (the page is likely to be very chatty).

* More crypto libraries already exist.

Advantages of JS/HTML5:

* Not Java

* Will work on the iPhone/iPad immediately (otherwise, if I went commercial, I'd have to develop an app).

* More transparent, giving technical users a greater sense of security.

Thoughts?

10 comments

[ 2.6 ms ] story [ 31.1 ms ] thread
johnm
What are the threat models that you care about (in some sort of rough rank order)?
lukev
The primary threat this protects against that other services don't is that the service hosting your data cannot mine it, their engineers cannot snicker at it, and they cannot accidentally release it.

It's not tremendously secure from a client-side perspective: if the client machine is compromised, so is your data. But that's not the goal. This is not a tool for spies, this is a tool for everyday people so they can have an unimpaired communication tool while having complete peace of mind that nobody is mining, selling or distributing their data.

shrughes
The host can still mine data. It doesn't know the content of the data itself, but it knows who's looking at whose data, and what IPs they're coming from and what browser fingerprint they have. The only thing you're protecting against is the accidental release of customer data. You'd be better off programming the server in some theorem-proving language that proves sensitive data isn't leaked.

What you end up with is a slow, unintelligent website, with fewer features and untargeted advertising that can't recommend friends. It can't do anything useful that social networking butterflies are interested in, and it's one that people who use secure services because it's fun to be paranoid aren't interested in either, because it's not actually secure, and it's a site that's more expensive to run and more complicated.

Don't do it.

kls
This was my thought given the browser trust model, the server would just have to deliver a payload to the client and let the client send the encrypted data back to it.
cperciva
All encryption will take place on the browser, using Open PGP standards. The server will see only encrypted data.

You've already lost. If someone can compromise your server, they can serve up a web page containing modified code.

lukev
Granted - You do need to trust the server to that extent.

However, the client-side code will be open source and digitally signed.

It's not perfect, and you shouldn't use it for state secrets, but it's a damn sight better than anything out there right now.

ig1
It depends if you consider a false sense of security better than no security.
shrughes
How is what you're designing any more secure than a typical website that communicates over HTTPS? The user can't prevent you from sending a broken Java applet or a webpage with broken encryption code, so the user still has to trust you. Look at what happened with Hushmail.
klodolph
If you did use a dedicated client-side app, it could be made more secure than HTTPS for those who don't trust the CA system. The explicit trust of all CAs (and there are many, scattered throughout the world) makes HTTPS a lot weaker than the algorithms alone would suggest.