Email encryption is a topic that comes up frequently in both technical and privacy circles. Pretty much everyone with any sense agrees that it would be a good thing — or at least a better situation than we have right now — if encryption was more widespread and not limited to geeks and the occasional criminal, but exactly how to get encryption into the hands of the masses in a usable form remains a challenge.

One of the problems is that most email-encryption products that offer end-to-end privacy (as opposed to simple transport-layer privacy, like SSL) are designed as part of a traditional desktop MUA, and many people are moving away from POP-based email and desktop MUAs in favor of server-stored messages and webmail.

This presents a problem, since without a desktop MUA, it’s not clear where the encryption/decryption logic will live. Some schemes in the past (e.g. HushMail, at least based on my understanding of how it works) that offer ‘encrypted webmail’ do the message encryption on the server, relying on transport-layer security to get the message to and from the user’s web browser.

This approach is seriously flawed: it requires that the user trust the webmail provider, something I think they probably should be wary of doing. (After all, the webmail provider may not be ‘evil,’ but almost certainly has priorities that are different from those of any randomly-chosen individual user.) Once you send your unencrypted message off to the server, even if it’s via SSL, you really have no idea what becomes of it or who can read it.

For real security, you need to encrypt the message before you let it out of your sight. What’s needed is something that combines the security of end-to-end encryption and client-side logic, with the convenience of webmail.

Naturally, I’m not the first person to have gone down this path. Herbert Hanewinkel, of Hanewin.net, even has a nice example implementation of GPG encryption in Javascript, under a freely-modifiable and re-distributable license. With it, you can plug in a public key, type some text, and have it encrypted for that key, all right in your browser. As he points out, this has several advantages:

• All code is implememented in readable Javascript.
• You can save the page and verify the source code.
• No binaries are loaded from a server or used embedded.
• No hidden transfer of plain text.

As-is, this is a nice way to submit forms (he has a contact form on his site that encrypts the message with his public key and sends it); combined with a matching decryptor, it could be the basis for a secure webmail system that doesn’t require the user to trust their ISP or the mailserver operator. (Sort of, anyway: the user would have to be constantly vigilant that the JS applet that they were being sent was the real thing…)

John Walker at Fourmilab.ch has a more generalized version called Javascrypt that does both encryption and decryption. (Hanewinkel’s encryptor seems to be based on Walker’s, but includes some performance enhancements.) His page also has a nice summary of the benefits of browser-based cryptography and some of its weaknesses and vulnerabilities.

While it would be nice if Google built a JavaScript implementation of GPG into its next version of Gmail, I’m not going to hold my breath (for starters, it would make their business model — basically data-mining all your stored messages — impractical). But I don’t think it would be too difficult to take the examples that are around right now, and work them into some of the more common OSS webmail packages.