Basics of Encryption pt. 4 (Public Keys and Trust)

Add comments

In the last few articles on GPG encryption, we talked about software, and generating a private key. Now we come to the part where we put out our public key which will let others send us encrypted messages, and get other people’s public keys which let us send messages to them.

Ideally, you would personally give your public key to a friend, and they would give you theirs. You would know 100% it came from them. However, sometimes you want to send things to people you can’t meet, and it’s also possible for someone to falsify an encryption key with someone else’s email address… which would let them read it if they had the matching private key.

This introduces something called trust. Let’s say my friend sends me his public key. I trust him, I know his key is correct, and I trust it’s secure. I can then sign his key and verify it’s secure. I can also assign it a level of trust that tells me how much I can rely on it.

Normally, you’re going to only mess with keys from people you know. However, an interesting feature of GPG encryption is that you can encrypt a message or file to more than one person at a time! If you specify more than one public key to encrypt it, then any one of those keys can decrypt the message. This is why it’s important to verify trust! You may know person “A” very well, but unless you know every single person you’re encrypting to, there’s potential for hacking or foul play. You can read up more on trust at GPG’s website. It’s worth a read, but it’s beyond the scope of this article.

There is also a way to verify a key without meeting the person directly: each key has what’s called a fingerprint. This is a string of letters that lets you verify the key is from who they say it is. You can contact the actual person by phone, chat, etc. and if the string they read off matches their key’s fingerprint, then you know it’s from them. You can then sign it to verify it’s trusted.

Now, about your public key. There are two ways to distribute your public key: send it to someone directly, or send it to a keyserver. 

If you want to send your key to someone directly, you can use GPG to export it, and simply email or file transfer it to them.

alice% gpg --output alice.gpg --export alice@cyb.org

The key is exported in a binary format, but this can be inconvenient when the key is to be sent though email or published on a web page. GnuPG therefore supports a command-line option --armor[2] that causes output to be generated in an ASCII-armored format similar to uuencoded documents. In general, any output from GnuPG, e.g., keys, encrypted documents, and signatures, can be ASCII-armored by adding the --armor option.

alice% gpg --armor --export alice@cyb.org —–BEGIN PGP PUBLIC KEY BLOCK—– Version: GnuPG v0.9.7 (GNU/Linux) Comment: For info see http://www.gnupg.org [...] —–END PGP PUBLIC KEY BLOCK—–

If you can’t send the key to everyone who you want to use it, then your other option is uploading it to a keyserver. There are several keyservers around the world, and your frontend software very likely has its own list. You just have to upload your key to the server, and then anyone can search for and find it using your key’s email address. You can also upload the key to a server, one at a time, using the GPG command line.

Enigmail for Thunderbird will automatically find keys from a keyserver that matches your recipient’s email address, which makes sending encrypted mails very quick… as long as you trust the key. As most security buffs will know, the weakest link in a security chain is people… they can be lied to, manipulated, and so forth. If someone is slick enough, they can trick people into sending mail encrypted with a key that they have the private key to… which defeats the whole purpose of encryption.

  • Share/Bookmark
Posted on January 31st 2010 in Linux, News, Security

Leave a Reply