We send and receive a lot of email. Much of it is fairly benign: newsletter subscriptions, “hi, how are you” messages from friends, perhaps emergency services alerts (living in Central Texas, my mailbox in May had an oversize number of these), or online billing notifications. While most email is not of a nature that our world would end if someone were able to read it, we still prefer some privacy. After all, the old adage “you’ve been reading my mail” is rooted in a desire to keep some things to oneself.
Common email providers tend to allow (or require) a secure HTTPS connection between the browser or email client and their servers. Ignoring for a moment the variety of flaws that have surfaced in different SSL implementations over the past year, you can be reasonably sure no one can read messages between the server and your web browser. Google made HTTPS the default for Gmail in 2010, and made it the only option last March. Yahoo made SSL the default in early 2014. Microsoft’s Outlook.com now uses HTTPS only as well.
What happens after the email leaves your browser or email client though? It's great that the message is safely transported from your browser to the mail server, but unless the message is intended for someone else using the same server, it must travel across the public Internet.
An introduction to encryption
The purpose of encryption is to scramble a message in such a way that it cannot be understood by the wrong person. The most basic (and in a computing world, useless) form of encryption is a substitution or “Caesar” cipher, in which the alphabet is simply shifted a certain number of places (each "A" in the message is replaced with "Z"; "B" is replaced with "A," and so forth).
While Caesar and other substitution ciphers will foil a casual glance, they are not particularly strong - a computer can try all possible substitutions in a matter of seconds. In fact, my 11-year-old daughter and I learned the basics of Python by writing a simple program to decode a Caesar cipher.
Modern encryption algorithms generally fall into two categories: symmetric, or “shared key” algorithms; and asymmetric, or “private/public key” algorithms. With a shared key algorithm, the same key (or password) is used to encrypt and to decrypt. The WPA2 password used to join your laptop to a wireless network is a common example of a symmetric key.
[ ALSO ON CSO: Increased encryption a double-edged sword ]
The Achilles’ heel of symmetric encryption is, how do you share the key safely? There’s a chicken-and-egg problem in that the communication is not secured until you have shared the secret key … which you wouldn’t want to share without a secure channel.
That’s where asymmetric encryption comes in. Imagine a mailbox with two keys - one key locks the mailbox, but a completely different key unlocks it. You could share the first key with anyone in the world. They could put private mail into your mailbox and lock it, knowing that only with your second key could you open the mailbox.
Now imagine that everyone in town left copies of the first key in the public library - a public key that anyone else could use. If you wanted to give a message to Joe, you would go to the library, pick up Joe's public key, deliver your message to Joe, and lock the mailbox. You would be assured that only Joe could read the message because only Joe has the private key that opens his mailbox. That is, as long as you trust the library to give you the key for the right “Joe.”
Encryption email for real people
Large enterprises solve the "library" problem by setting up a Certificate Authority - a service that manages the keys - and configuring every computer within the business to trust that service. That is reasonably easy for a business, because the business manages both the certificate authority and the computers that need to trust it.
Last spring, two developers launched the startup Keybase. Keybase is an attempt to make encryption accessible to the average user by solving the problem of that library. Rather than requiring everyone in the world to trust a certificate authority, Keybase relies on something most of us already use: social media.
When you create an account with Keybase, you can link the service to your Twitter or GitHub accounts, or to websites that you own. If I trust that you are @joe on Twitter, or that you own the website joe.com, then I can trust your Keybase identity and obtain your public key.
Last June Google announced "End-To-End," a browser plugin for Chrome that encrypts email before it ever leaves your browser. Currently, End-To-End is in the early stages of development, not a consumer-ready product. For the ambitious among us though, the existing code is available for anyone to download and compile, and it will work with public and private keys created in Keybase.
Facebook is taking the idea of encrypted email one step further: last week Facebook announced support for OpenPGP Keys - the sort of public/private keys Keybase and End-To-End use. You can enter your public key into your Facebook profile, which Facebook will use to encrypt any messages the site sends to you. (Keep in mind that this includes account recovery email, so don’t lose your private key!) The company also makes your public key available to anyone else that wishes to send you secured email.
It's not entirely seamless yet - you still must manually decrypt any encrypted messages, whether through Keybase, End-To-End, or another email encryption program - but it's a step in the right direction. Encrypted email has long been a complicated problem to solve, but a combination of Internet titans and innovative startups are working to make it practical for real people.
This article is published as part of the IDG Contributor Network. Want to Join?