Hacker News Reader

Firstly, I want to applaud mailpile for their efforts. Next, I'd like to respond to you with what our product is aiming to solve (because that is what I know best).

> All innovation in the secure email space has been blocked for the past 13 years by one primary problem: webmail.

We are working on solving this very problem. We do this via js crypto. The main problem with js crypto is modification of the crypto with the transfer. We aim to solve this via having a browser extension be the default js store (so that all the crypto is verifiable by outside sources).

> That way if the anyone compels my VPS provider for access, they just get a bunch of encrypted email.

This is also true of any service which provides end-to-end encryption (With the exception of the plaintext headers).

> So my problem isn't receiving or encrypting email, it's reading it.

We use SMIME for encryption which is supported by a variety of clients: Outlook, iMail, and our own client. For internet mail, as I said, we are working on browser extensions for gMail.

The main problem that this does not solve is the routing and timestamp metadata problem as that is still necessary for the transfer of the email.

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.

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.

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.

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/

Wouldn't Mailpile make things better even if you kept your GPG keys on the server?

Sure, if the authorities targeted you specifically, they could probably pry the unencrypted keys from the server's memory (although with considerable effort it it was a dedicated or collocated machine) but widespread adoption of that model would completely stop dragnets. Only narrowly tailored investigations would be feasible, no mass surveillance.

Can't we also make a server that is physically hardened against tampering? If servers get small enough and cheap enough and only need to support one individual, then you can always try encasing that server in some material that is physically difficult to penetrate without risking destruction of the server itself. i.e. encase the server in concrete or opaque resin with a thin lead shielding to prevent x-raying of the device for precise drilling and exposing only the power leads and the network interface. As long as the network software interface is totally secure, you leave no way for any other attacks that I can think of. You could go further and booby trap the enclosure so that it destroys it's contents. At the end of the day, many of these ideas have already been explored in the safe manufacturing industry, such as glass panels that shatter upon drilling, permanently locking the safe. A glass enclosure with a strong liquid corrosive could be used around a small server. Tampering with the outer enclosure could result in likely breakage of that glass vessel, thereby destroying the server beyond recovery.

It's called a hardware security module (HSM) [1]. The basic idea is to store the private key in the tamper-resistant hardware, along with a microprocessor to perform the basic encryption options you need. They can be relatively cheap, like a smart card + usb smart card reader, to very expensive, like an IBM 4764. Yubikey sells a usb HSM if you want to run your own authentication server for around $500.

There's a whole chapter dedicated to HSMs in Security Engineering [2], which is available online. There are clever ways to attack them, and yes, the booby trap idea has been done, typically by using something light-sensitive. I'm not aware of any concrete-encased HSMs, however...

It's an interesting topic. That are lots of challenges around them too. It will probably have a battery backup, so how do you allow someone to replace the battery without wiping the keys? Or can only people with access to the keys replace the batteries? That won't work if you're doing mathematical secret sharing, however, since there's no physical way to do that.

  [1] http://en.wikipedia.org/wiki/Hardware_security_module
  [2] http://www.cl.cam.ac.uk/~rja14/book.html

Cool info. Upvote.

As far as some of the issues you raised like battery replacement, I would treat them as disposable. In the next few years a complete computer will be available for so little that we will consider it disposable. Prepare a server once, enclose it, make sure the only way in or out is an SSH connection. When it's time to set up a clone to replace it, clone everything via an SSH session and trash the first server.

That could work, but the advantage of an HSM is that the key material is physically prevented from leaving the device, barring acid/x-rays/other attacks. All encryption happens on the device itself. With an open ssh connection you could still remove the key material from computer.

Only the public key should be stored on the virtual mail server, since all it's doing is encrypting incoming mail. It's your local email client (e.g. Thunderbird) that then downloads the encrypted emails to your local machine and decrypts them with your private key. Signing and outgoing encryption are also done locally. At that point, all that someone raiding your VPS gets is a bunch of encrypted messages, which good encryption is supposed to make worthless, and your public key, which they should already have (along with everyone else).

Sure, your local machine could also be raided and the keys grabbed from that, but that's not a problem with using a VPS so much as a problem with your local setup.

What about the VPS provider being coerced into logging network traffic to the VPS? Then incoming un-encrypted mail is compromised..

This is pretty much the reason that Silent Circle shut down their email product. Their other offerings use custom protocols with full end-to-end encryption (and are still up and running), but for email, they were trying to interoperate with the legacy stuff, which left them handling plaintext in some cases.

It's also the focus of some of the speculation about the unknown demand that triggered the Lavabit shutdown.

> All innovation in the secure email space has been blocked for the past 13 years by one primary problem: webmail. It is simply not possible to develop a secure email solution if webmail is the only viable option for accessing mail, so most people who would be interested in innovating here don't even bother. If we can successfully make the transition back to local MUAs, however, we might have a chance to try something new

The only way I can think that webmail could be secured is through changing HTTP and HTML standards to allow the web browser to arbitrarily encrypt forms and decrypt elements with keys unknown to the web server plus disable JS inspection of form elements and elements set as encrypted.

I can't imagine the difficulty in getting it through the standards process let alone implementing it securely though.

Have you looked into systems like Mailvelope? (similar to what FireGPG once was)

Private keys are kept in the domain of a browser extension, so even if your webmail provider served up malicious javascript (via xss or court order), they would not be able to directly read the contents of your emails since they are being encrypted/decrypted in a separate domain.

Ideally the crypto APIs in browsers would work nicer with hardware tokens etc, but until then, at least people can start moving towards GPG without having to trust large, scary, poorly maintained email clients like thunderbird and evolution, which tend to segfault with a terrifying frequency.

I'm currently using Geary as my local MUA (Linux only, FWIW) -- I'm unsure if it has encryption built in yet, but I know it's on the radar, and is under heavy development. Check it out, if you're a Linux user. I replaced Thunderbird with it quite successfully :)