Hacker News Reader

Comment by tptacek | Hacker News Reader

As drily as I can, given the rules of Show HN, but it's not end-to-end if the crypto is delivered over browser Javascript. Every time a user's browser touches your server for any reason, the server has the option to fatally compromise security. End-to-end means you don't have to trust the server; that's real privacy.

So, given that this is a proof-of-concept, my advice is to back off on the web app part of this, and develop an installable client.

View on HN

In the same way that we trust bcrypt when we get the source from somewhere we know, it would be possible to make an encryption module in JS that gets imported from a trusted location eg https://github.com/shaneGirish/bcrypt-nodejs/blob/master/bCr.... So long as the web app imports that version, and checks it against a hash from another trusted location then it would be possible to get true end-to-end encrpytion entirely in a browser without trusting some random server. You'd 'just' have to trust Github (or any other trustworthy server) instead.

[1] That's specifically for Node, but it could be tweaked to work in browsers.

No, you can't do that, because browser Javascript lacks a mechanism to segregate one "module" from another. In fact, any page that merely populates the DOM can override any security decision made by any Javascript file.

This idea comes up a lot, and nobody's ever explained to me a workable method for doing an integrity check of the entire Javascript runtime associated with a specific site. It's not as easy to do as it sounds.

You're right, but these sorts of browser apps will continue to be made because of the convenience.

The cheapest browser-app integrity check that I know of is shipping the dev code, complete with source maps. Allow anyone to read and debug what is going on inside your app.

That doesn't work either, because the app users read can be totally different than the app that ends up running the next time the DOM updates itself in the background.

See? "Fun" problem.

I agree 100%, and yes, this is a proof of concept. I want to get a desktop version completed asap & app for iOS/Android/Windows.

It will speed up the whole encryption/decryption progress too.

How about this:

I install git server, I add a person's public key to authorized_keys to allow him to git checkout/clone, and I keep committing with my own username and push whenever I want to update.

Is this similar to what you are trying to do?

tptacek is right. In order to trust your crypto we have to trust that your server isn't compromising your crypto via malicious JavaScript, so when you claim that we don't have to trust the server, you're asking us to both trust and not trust the server.

You could do a Chrome extension with all the frontend code baked into the extension's static JavaScript. Firefox still has no sandboxing for add-ons, so you wouldn't have luck there.

Desktop / installed apps would be the way to go. See https://turtl.it for an example of this (shameless plug)

I wonder if it'd be possible to sign the JS a site serves you, so you know it's unchanged from when you originally got it?

You can sign it, but then your clients would have to install an extension to verify it.

I think it's theoretically possible to use Service Workers to do this, giving you a TOFU trust guarantee, although I think there are some issues due to the spec-mandated auto-updating of Service Workers every 24 hours.

There's an FAQ about this that some kind, unknown soul from the ether of the Internet wrote awhile back:

http://matasano.com/articles/javascript-cryptography/

Indeed. Protonmail has the same issue. However, I'm wanting to release a desktop & mobile app as soon as possible, to phase out the browser version. This is just a proof of concept for now.

What about something like this?

http://substack.net/offline_decentralized_single_sign_on_in_...

Edit: This article describes a solution that uses an appcache manifest with a far-future max-age that stops the browser from refetching the application code. It then uses an alternative mechanism to load updates presumably with a future option capable of verifying the legitimacy of the code with some sort of public key infrastructure ala Microsoft's Authenticode.

Instead of focusing on an installable client you should use these new techniques: http://substack.net/offline_decentralized_single_sign_on_in_...

Reply on news.ycombinator.com