According to Ryan Singel at Wired, Hushmail, a company specializing in offering Encrypted Webmail to their customers. In my previous series on e-mail encryption, I mentioned how difficult a problem this was. My argument was two-fold. First, if you store the Private Key on the web-mail server, the key can be compromised if the server is compromised, even you passphrase is up for grabs because it has to travel accross the network, and be unencrypted on the server.

Doing the encryption/decryption on the client is difficult, because it’s not convenient. It’s impossible to do in Javascript because Javascript isn’t designed for the kind of heavy math that encrpytion requires, and it would be painfully slow to do this. Also, since Javascript can’t read data from the local disk, you’d still have to store the keys on the servers. At least this time, the passphrase to unlock the key wouldn’t have to travel across the network. Hushmail opted for a different route, the use of a Java Applet which would handle the encryption/decryption process. This works because signed Java applets can be given access to the filesystem by the user. The unfortunate part of Java Client security is that the security is an all-or-nothing deal, either you give the applet full permission, or no permission.

The benifit to this, of course, is that with Hushmail’s Java client you store your encryption keys on your local computer. Apparently, due to users complaining about the hassle of not being able to access their web-mail from anywhere (because of the requirement for the keys, and Java), Hushmail began to offer a service where you can store your key on the server, and access your mail over https. While they acknowledge the fact that this does require a user to impart a significant amount of trust on Hushmail that isn’t necessary with the Applet based solution, marketing appears to play down the danger quite a bit.

That all changed though, now that Hushmail has, due to Court Order, captured a handful of users’ passphrases, and turned over a dozen CDs worth of encrypted e-mails, along with the encryption keys and passphrases to the Government. Sure, in this case it was a part of a legitimate criminal investigation, but it exemplifies the weaknesses and challenges inherent in solving the encrypted webmail problem. It also shows that Hushmail’s non-Java Applet solution is not an acceptable channel for secure communications. The lesson is clear: Protect your keys, and your passphrases. Hushmail’s less secure option doesn’t allow you to fulfill either goal.

In the end, though, Hushmail is interested more in protecting Hushmail than their users, which is understandable from a Business perspective. The protection they offer is great for keeping your data secret from undirected attacks, but Hushmail is clearly more than willing to turn over data in response to a directed government probe. So Hushmail is perfectly safe, if you use the Java-Applet and don’t give the Government any reason to ask questions, but if they do, and a Judge signs off on it, Hushmail could even ovveride the security of their Java-applet, and odds are, you’d never know. At least their owner is honest about this fact. If anything, though, this goes to show that no web-mail based encryption system could probably ever hope to be considered secure.

I believe that as handheld computing becomes more common, protection will be easier, as we won’t have to use untrusted systems as often, and our keys can always be with us. With High-Speed Wireless communications, your handheld computer could even serve as your own personal encryption engine, where data from the untrusted machine is sent to your handheld, encrypted on the trusted platform, and sent back. With a reasonable TLS algorithm protecting that short link, the danger of interception is low. It’s something to think about for the future.