Hacker News Reader

How trust worthy is the js crypto? For a long time people believed hushmail to be safe: http://en.wikipedia.org/wiki/Hushmail#Compromises_to_email_p...

Regardless of how safe it is, the problem is still social engineering hacks, key loggers etc (you'll always have this issue) - just wondering to what lengths a government will go...

Some key differences are that we do not store your emails, your email provider does. We do not ever, at any point, have access to your unencrypted keys. Therefore, we cannot, even if forced to turn over access to your data. That being said, as with all secure systems there may be bugs. The client however, is (will be) open source so that everyone can help solve whatever problems that may arise. The key point is that the architecture is set up so that we dont ever need access to your keys or data.

So now I really don't understand how this is any different from using Thunderbird and EnigMail/PGP to encrypt your mail - and if I've understood correctly then it actually isn't any different, you are just providing a glossier interface.

I think it's a worthwhile project, but beyond the tech community, I'm not entirely sure how much traction usage will get... Thunderbird/Enigmail is a PITA to setup and use for sure. A step in the right direction, but all m00t unless everyone is using encryption and it becomes the defacto when communication via email.

It is different in that it creates a key distribution interface for the average person. This interface allows things like decrypting emails in the browser and transparent security. It also allows you to know who has security and who doesnt (this allows people to incrementally start using encryption without the headaches of wondering who else is using it). These are problems that are not solved with any PGP type interface today.

I think that what you are missing is that the server stores encrypted keys, rather than no key.

Lavabit had a similar architecture, only with the password could the server-side email be unencrypted. Although we don't know for sure, it appears that the government insisted that they trojan their client side code to retrieve the password.

Your secret sauce, if I understand it correctly, is open sourcing the client side code and providing some mechanisms to assure end users that what they are executing matches the publically published code.

That makes sense to me, but I don't see why you wouldn't go one step further and store the secret key in the browser plug-in. Is it an multiple-installation issue?

> Your secret sauce, if I understand it correctly, is open sourcing the client side code and providing some mechanisms to assure end users that what they are executing matches the publically published code.

Yes, the js client is fully intended to work exactly this way.

> That makes sense to me, but I don't see why you wouldn't go one step further and store the secret key in the browser plug-in. Is it an multiple-installation issue?

There are a few issues here.

1. The first is the general crypto principle: minimize your TCB. I want the key to have to touch as few places as possible. For this reason, I have plans on moving the keys from the server to a clients machine(s). Doing so, however, involves a lot more problems including: NAT and the lack of a fallback. In the future, when I have more time to work on these details, I want to try and make that an option for people.

2. Another problem with placing the key in the browser is as you say: it allows anyone who is able to access the browser to access your key (including malware and other users).

3. Lastly, where would this key come from (remember rule #1: the server never has access to an unencrypted key)? If it is generated on the local machine that would then mean that you have no way of distributing it to your other machines (or at least not in ways that your grandmother will be able to do). Even if there were some super snazzy interface, it would be prone to attack as well.

Thanks for the response. I would look back at some of the articles that came out on the imessage protocol several months back. They face a similar key distribution problem given that iMessages can potentially be delivered to multiple devices. I don't remember if the reverse engineering ever figured out exactly how they cracked that nut, but I seem to remember that there were some reasonable hypothesis.

they might go as far as implementing back-doors in OSes according to past rumors

I imagine that you can then solve those other problems one at a time by implementing alternatives in your webmail client. The interface to the user can stay the same, but you can add additional more secure transports underneath that the client can opt to use when there is indication that the person they are communicating with uses a mail system that supports that upgraded security solution. In the interface, you just need an indicator of what information is being leaked on a recipient by recipient basis.

At the end of the day this is how filesharing evolved... from FTP to Napster to Kazaa to Torrents to Magnet links. They slowly solved each of the attacks out there.

You are probably correct. In fact, our solution allows for this type of checking explicitly so that we can (when possible) migrate to better protocols. Interestingly enough, I like your analogy because in all honesty, email is simply file sharing with routing and in path storage.

JS crypto makes sense, but I'm confused as to why a browser extension is necessary—you can safely deliver the JS crypto solution over an https connection, so the critical component is keeping the user's private decryption key distinct from their login/password.

Seems a shame to depend on a browser extension—you lose most of the advantages of webmail when you can't log into it from anywhere.

The usual argument against JS crypto is that a compromised (either technically or legally) host could send a malicious version of the code to steal your keys/data.

A browser extension could in theory be used to verify the code against a signature or something to that effect, or it could sandbox the crypto routines and keys from the app itself (though that wouldn't prevent the app from stealing the decrypted data)

What needs to happen for this to become generally usable is for the crypto part to be built into the browser - that way you only need to trust your browser and not a somewhat random plugin, nor the .js being served from a particular server.

And it'll "just work", so ordinary people have a chance to use and trust it too.

Sure, eventually, however I'd be just as comfortable using a plugin from, say, the EFF as I would having it built into the browser. It would be a fine stepping-stone (similar to how Google Gears contained many features which influenced HTML5)

And as I mentioned, merely having the crypto parts and key management built into the browser isn't good enough because a malicious site could still trick you into decrypting data which it could then steal, even if the keys themselves are perfectly safe.

As tlrobinson says, the problem is that we dont want you to have to trust us. One of our goals is to minimize the amount of trust you have to place in us. Therefore, we want you to be safe if we are forced to try and steal your keys. See my other comment for more info: https://news.ycombinator.com/item?id=6245617

Gotcha, makes sense. Still, I wonder if there might be a clever solution which exploits the same-domain policy to isolate the decryption activity from the rest of the app. That would considerably reduce the attack surface if it handles collecting the key and then you just postMessage strings back and forth.

As you hint at in the other comment, there are various ways that third-parties could vouch for the code running on the decryption domain.

You probably realize that doing crypto right in js is very challenging. This has been discussed several times on HN, usually this article is brought up: http://www.matasano.com/articles/javascript-cryptography/

Is your browser extension a generic solution to the "browser JS crypto" problem, or specific to your application?

Solving that problem would go a long way in making secure communication more accessible, but it's a hard problem.

Rome wasnt built in a day, as the saying goes. Our solution here tries to solve a few of the problems to start with. The goal, however, is to maintain a list of urls, sha1 hashes, update times, and a list of verifiers. The sha1 hashes make sure that the js that you have is the one being distributed (although the hash may soon be upgraded to a different one). The update times and list of verifiers are used to be able to update the code as safely as possible. The verifiers are a list of people who sign the code (with a timestamp). This is used to make sure that any individual isnt sending you a modified version of the js. Those are the goals for that compartment of the code, but as is right now, we are the only signers and so the basic point of the extension is so that we ourselves cant update your code by ourselves (you'd have to update the extension). This means that if we are forced somehow to change the js to get your key, that code will be available to anyone who wants to look at the diff where it should be staring you in the face.

Is the delivered js minimized / compiled or delivered in human readable form?

The container is abstracted, so it can receive whatever type of js the server wants to send. Specifically, the js that we will use will not be compiled so that it can be verified (and it will also be open source). The main problem with this is that it wastes bandwidth which shouldnt be a problem for two reasons: the architecture can cache the js intelligently and the extension will have a lot of the crypto stuff embedded meaning that it wont need to be redistributed per access.