Public-Key Cryptography: Private Email and Secure Signatures
[Hogmartin]

Commenter Hogmartin knows a thing or two about hogs. And martins. And secure email communication (he does computer stuff for pay) which, if things go pear-shaped the way some people expect, will be quite useful in the not-so-distant future.

And even if you think everything will be just wonderful, keeping private communication private is a quintessentially free man's behavior. It doesn't matter if you are swapping recipes or plans for thermonuclear devices; it isn't anyone's business but yours and the recipient.
-- CBD

You might have heard the saying, "never send anything in an email that you wouldn't send on a postcard". It's true. Email might be secure in transit - between your computer and your mail server - but it's not guaranteed. And it's even less likely that email is secure at rest: on your computer, on the recipient's computer, or even on the mail server. The document that established a common internet email system was built on earlier work that just wasn't designed for a massive public internet. If we want to be able to send and receive email that we can trust, the two main flaws that we want to address are:

1. Encryption: How can I be sure that the mail I send is only readable by my intended recipient(s)?


2. Signing & Validation: How can I be sure that email I receive was actually written by the person who claims to have written it?

• It's free. It doesn't cost anything to install or use. There's no monthly fee, no service provider. You don't need any special hardware besides your computer.


• Once you catch on to how it works, it's pretty easy to use.


• You can use it alongside the rest of your email, in the same email account. You don't need a special address or anything.

There's one big caveat, though: you will need to install a local mail client (in this example, I'm using Mozilla Thunderbird). You can use it alongside your ordinary webmail from outlook.com or gmail.com, but you absolutely cannot send and receive encrypted messages, nor sign and verify signed messages, from the web client. If you could, you'd be handing the keys to the kingdom over to Microsoft or Google anyway. So let's not do that.

Installing and setting up Thunderbird for your mail provider is outside the scope of this tutorial. I chose it for the example because it's free, and GPG/OpenPGP functionality is built in. There's nothing else you need to download or configure, just Thunderbird. The brief summary is that you download it, install it (with the standard options - the "keep clicking next" approach), and when it starts up, it'll ask if you want to configure an existing email address. For many of the more common mail providers - gmail, Hotmail, outlook.com, verizon.net - you just tell it your email address and it'll get all the settings for you. If you're using a dedicated pseudo-anonymous address, like an 'aos.nickname@gmail' address or 'mynick@moronhorde.com', be sure not to give your real name here, just the nickname. Enter your password and you're ready to go. If you encounter any problems, you'll want to search for "configure thunderbird for verizon mail" (whatever your provider might be) to get that set up, or seek assistance from your local nerd. It might be a good idea to install Thunderbird on your preferred computer right now, and let it configure itself for your email address, just to get a feel for how it works. It should keep all the mail on the server (look for the term "IMAP" in the auto configuration screen to make sure), so you can always go back and use your webmail as usual, or switch back and forth between the web mail client and Thunderbird.

How it works

Full disclosure: this is the "hard part". It might take a while to get a handle on what's going on. Take your time. The way I'm explaining it might not be the best way for you to understand it, so feel free to ask questions in the thread or search around for other tutorials. Once the whole scheme "clicks", then you'll be able to understand it intuitively, but don't proceed until you "get it"; there's no point in generating a keypair or sending public keys around just following instructions by rote.

It might help to watch this video first, then read the steps below

Public-key cryptography is based around the idea that with a pair of related keys (the private key and the public key), you can do some interesting one-way functions. With a public key, you can encrypt a message that can only be decrypted with the corresponding private key, and with a private key, you can sign a message that can be verified with the public key.

1. Alice and Bob, on their own, generate their own keypair. Now Alice has her private and public key, and Bob has his private and public key.


2. Alice and Bob exchange public keys. Now:
   
   
   
   • Alice's keyring has her private key, her public key, and a copy of Bob's public key.
   
   
   • Bob's keyring has his private key, his public key, and a copy of Alice's public key.
   
   
   • Alice and Bob keep their private keys secret! They only exchange public keys.
   
   


3. Alice wants to send a message to Bob, that only Bob can read. She types her message and encrypts it with Bob's public key, then sends the encrypted message to Bob.


4. Bob receives the encrypted message from Alice. Since he has his private key, and the message was encrypted with his public key, he can decrypt and read it.


5. Bob wants to reply to Alice's message. In this example, the reply doesn't need to be encryped - he doesn't care who reads it - but he wants Alice to know that he, Bob, was the one who sent the message, without any doubt.


6. Bob types the reply and signs it with his private key, then sends it to Alice.


7. Alice, and anyone else who gets the message, can use Bob's public key to prove that the message came from him. Only his private key could have signed the message, and anyone with his public key can validate that.


Since Bob and Alice each have a copy of the other's public key, they can go around and around sending encrypted messages with the other's public keys and decrypting them with their own private keys. They can even sign and encrypt a message in one step - sign it with their own private key and encrypt it with the other's public key, and on the other end the message is decrypted with the private key and the signature is validated with the public key.


Now, they want to include Carol in the conversation. All they need is a copy of Carol's public key, and when Alice sends a message to Bob, instead of just using Bob's public key to encrypt it, she uses both Bob's and Carol's public key. The encrypted message can now be decrypted by either Bob or Carol with either of their private keys. Pretty handy! But what if Carol can get a copy of her public key to Bob, but not to Alice? That is, someone who claims to be Carol can get a copy of a public key to Alice, but Alice has no idea who it really is. Alice does trust Bob, though. Well, remember how Bob can sign a message with his private key - that only Bob has - and Alice can trust that the message really came from Bob? They can do the same thing with public keys. Bob can add a signature with his private key to Carol's public key before passing it on to Alice. Alice doesn't necessarily have to trust Carol, but she can look at Carol's public key and verify that Bob vouches for they key's authenticity by verifying his signature on Carol's public key, using her copy of Bob's public key. It might be easier to think of Carol's public key as an ordinary message: if Bob signs a message, you can be sure that it came from him. If Bob signs Carol's public key, he's vouching for its authenticity.

And then it gets a bit complicated. Here's the link to the whole thing. And I will put a link to this post on the sidebar for reference. [CBD]


posted by Open Blogger at 04:00 PM

| Access Comments