

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

I'm moving forward with developing a prototype of a cryptographically secure social networking site/messaging service/photo service.<p>All encryption will take place on the browser, using Open PGP standards. The server will see only encrypted data.<p>I can't decide between using Javascript/HTML5 and a hidden Java applet to do the bulk of the work.<p>Advantages of Java:<p>* Much faster for bitwise crypto operations (a significant concern).<p>* 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.<p>* I can use direct socket communication to reduce latency (the page is likely to be very chatty).<p>* More crypto libraries already exist.<p>Advantages of JS/HTML5:<p>* Not Java<p>* Will work on the iPhone/iPad immediately (otherwise, if I went commercial, I'd have to develop an app).<p>* More transparent, giving technical users a greater sense of security.<p>Thoughts?
======
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.

------
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.

~~~
rnicholson
You should read <http://corte.si/posts/security/hostproof.html> and
<http://corte.si/posts/security/crypsr.html>. Was also discussed here -
<http://news.ycombinator.com/item?id=1226277>

