Email is frightfully insecure. Anything you write can and will be read by any number of robots or worse as it bounces across the Internet. Gmail? forget about any shred of privacy. While the Goog champions securing the data as it comes to and from their servers, once it’s there, your private life is fair game.

It doesn’t have to be that way. We can encrypt the contents of our emails so that only the intended recipients can read them. I’m not sure how many more embarrassing corporate, government, and university email hacks will have to happen before people start to take this seriously, but remember, those were only the illegal hacks. Other people are reading your emails all the time already. This bothers me.

Sorting out a solution to this problem has been like having a big jumble of puzzle pieces on my coffee table, and while I’ve pushed the pieces around to get them to fit together, it’s become apparent that there’s a piece missing — until (perhaps) now. To understand the puzzle piece, it’s easiest to start with the hole it needs to fill. Some of this you may have read in posts from days of yore.

Here’s a simplified illustration of how email encryption works. Picture a box with two locks, that take two different keys. When you lock the box with one key, only the other key can open the box again. If you want to send me a message, I give you one of the keys, and you put the message in the box and lock it. Since I’m the only one with the matching key, only I can unlock it. Sorry, Google! You just get gibberish.

Of course, there’s a catch. How do I get your half of the key pair to you? If I put it in an email, any bad guy could switch the key before it got to you, and then your secret message would only be readable by the bad guy. He’d probably pack the message back up and lock it with my key and send it on, so I might not notice right away that that the message had been intercepted.

What’s needed is either a foolproof way to send my public key to you, or a way to confirm that the key you got really came from me.

If there were a foolproof way to send the key, we’d dispense with the whole lockbox thing and just send the original message that way. So until that foolproof way arrives, we are left with the need to authenticate the key I send you, through some trusted, hard-to-fake source. There are competing ways to accomplish this, and they all have flaws. This is the hole in our jigsaw puzzle.

The most common way key-verifying is done is through a series of Certificate Authorities, companies entrusted with issuing and verifying these keys. This works pretty well, as long as every single Certificate Authority can be trusted. The moment one is hacked, the entire system has been compromised. Guess what? CA’s have been hacked. There are also several governments that are CA’s, meaning those governments can listen in on any transaction on the Web today that uses https:// – which is just about all of them. Any of those entities could send a fake key to you and your software would trust it. I don’t know which makes me more nervous, that China is on the list or the United States.

So if you can’t collectively trust a few hundred companies and governments, who can you trust? There are several competing systems now where you and all your friends only have to trust one company. As long as you and I both set up with that company, they will quite effectively safeguard our communications. Your privacy is as good as the security and integrity of a single corporation — unless a jealous government shuts them down, anyway, or they get bought by a less-scrupulous company, or a pissed-off engineer in their IT department decides to drop their corporate pants. Having a single entity hold all the keys is called the “key escrow problem”.

At the far end of the spectrum is crowd-sourcing trust. There exists a large and (alas) floundering network of people who vouch for each other, so if you trust Bob and Bob says my key’s OK, you can choose to trust my key. I’ve tried to participate in the “Web of Trust”, and, well, here I am, still sending emails in the clear.

But now there’s a new kid in town! I just got an invitation to join the alpha-testing stage for a new key-verification service, keybase.io. Let’s say you want to send me a message. You need the public key to my lockbox. You ask keybase for it, and they send you a key. But do you trust that key? No, not at all. Along with the key, the server sends a bunch of links, to things like this blog and my twitter account. The software on your computer automatically checks those links to see if a special code is there, and if it is, invites you to go and look at those links to make sure they point to things I control. You see the special code on Muddled Ramblings or Twitter or whatever that only I could have put there, and you can feel pretty good about the key. You put your own stamp on the key so you don’t have to go through the manual verification again, and away you go!

There are more features to prevent bad guys from other shenanigans like hacking my blog and twitter before giving you a fake key, but you can read about them at http://keybase.io.

The service is still in the pre-pubescent stage; I’m fiddling now to see if I can use keybase-verified keys from my mail software. Failing that, there are other methods to encrypt and decrypt messages you cut and paste from your email. Kinda clunky.

Having set up my keybase identity, I have been given the privilege of inviting four more people aboard. Good thing, too, since otherwise I’d have no one to exchange messages with, to see how it works. I’d be grateful if one (or four!) of y’all out there would like to be a guinea pig with me. Drop me a line if you’re interested. Let’s win one for the little guy!