We send and receive a lot of email. Much of it is fairly benign: newsletter subscriptions, \u201chi, how are you\u201d 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 \u201cyou\u2019ve been reading my mail\u201d is rooted in a desire to keep some things to oneself.\n\nCommon 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\u00a0Gmail\u00a0in 2010, and made it the only option last March.\u00a0Yahoo\u00a0made SSL the default in early 2014.\u00a0 Microsoft\u2019s\u00a0Outlook.com\u00a0now uses HTTPS only as well.\n\nWhat 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.\n\nAn introduction to encryption\n\nThe 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\u00a0\u201cCaesar\u201d 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).\n\nWhile 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.\n\nModern encryption algorithms generally fall into two categories: symmetric, or \u201cshared key\u201d algorithms; and asymmetric, or \u201cprivate\/public key\u201d 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.\n\n[ ALSO ON CSO: Increased encryption a double-edged sword ]\n\nThe Achilles\u2019 heel of symmetric encryption is, how do you share the key safely? There\u2019s a chicken-and-egg problem in that the communication is not secured until you have shared the secret key \u2026 which you wouldn\u2019t want to share without a secure channel.\n\nThat\u2019s 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.\n\nNow 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 \u201cJoe.\u201d\n\nEncryption email for real people\n\nLarge 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.\n\nLast spring, two developers launched the startup\u00a0Keybase. 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.\n\nWhen 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.\n\nLast June\u00a0Google announced "End-To-End,"\u00a0a 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.\n\nFacebook is taking the idea of encrypted email one step further: last week\u00a0Facebook announced support for OpenPGP Keys\u00a0- 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\u2019t lose your private key!) The company also makes your public key available to anyone else that wishes to send you secured email.\n\nIt'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.