# What is the Web of Trust?

📅

Original image from Jay Gooby on Flickr. Some rights reserved: cc by.

This is the second article in a series about GPG and public-key encryption. This part doesn't depend on the previous part about generating and using a keypair but you may want to read that first anyway for background.

So, what is the web of trust and how does it work? Well, it's basically a decentralized version of a certificate authority. A CA issues TLS certificates for people to use once they've proven that they are who they say they are. Along those same lines, in the web of trust people sign each other's keys to show that they are who their key says they are. Before explaining how the web of trust works, let's look at what happens when we want to get somebody's public key.

## Finding Public Keys

The first thing to do after generating a new keypair is to make sure it's out there where people can use it. The way to do this with GPG is

$gpg --keyserver <key server> --send-key <key id> SKS is a popular keyserver network so let's send the key we generated last time there: $ gpg --keyserver hkp://pool.sks-keyservers.net --send-key 13D0B439
gpg: sending key 5DF274C713D0B439 to hkp://pool.sks-keyservers.net

Now if we want to get somebody's key, we just ask the keyserver using their email address. For example, to get my public key:

$gpg --keyserver hkp://pool.sks-keyservers.net --search-keys peter@peterbeard.co gpg: data source: http://keys.fspproductions.biz:11371 (1) Peter Beard <peter@peterbeard.co> Peter Beard <peter.b.beard@gmail.com> 4096 bit RSA key B4A371011B4ED7ED, created: 2016-11-12, expires: 2021-11-11 (2) [ my old key - don't use it; I lost the private key ] Keys 1-2 of 2 for "peter@peterbeard.co". Enter number(s), N)ext, or Q)uit > 1 gpg: key B4A371011B4ED7ED: "Peter Beard <peter.b.beard@gmail.com>> not changed gpg: Total number processed: 1 gpg: unchanged: 1 Neat, but how do you know it's the right key? What if somebody else generated a key and wanted to impersonate me? How can you check to make sure you have the right one? ## Key Signatures Well, that's what the signatures are for. If we look at the signatures for our sample key, we see this: $ gpg --list-signatures 13D0B439
pub   rsa4096 2017-03-01 [SC] [expires: 2018-03-01]
543C1C8FD5B8FAFDCDC714FD5DF274C713D0B439
uid           [ultimate] Peter Beard (This is a sample key.) <samplekey@peterbeard.co>
sig 3        5DF274C713D0B439 2017-03-01  Peter Beard (This is a sample key.) <samplekey@peterbeard.co>
sub   rsa4096 2017-03-01 [E] [expires: 2018-03-01]
sig          5DF274C713D0B439 2017-03-01  Peter Beard (This is a sample key.) 

The only signature for our public key is shown under the uid: sig 3 5DF274C713D0B439 2017-03-01 Peter Beard (This is a sample key.). This means that there's only one signature but it's rated at the highest confidence level. There are three levels of verification that can be applied to a signature:

1. No verification
2. Some verification; maybe you just believe that the key belongs to who it says it does and sign it because of that
3. Significant verification: might mean that you saw a photograph of this person with their email address or talked to them on the phone to verify the key's fingerprint
4. Maximum verification: could mean that you checked that the emails in the key belong to the person as well as met in person and verified a photo ID, maybe a driver's license or something like that

There are no fixed rules as to what the different levels mean, just guidelines. In this case, we have a level 3 signature since we generated the key ourselves. Our own signature is also the only one we have, which isn't terribly trustworthy. Let's take a look at a key with a lot of signatures:

\$ gpg --list-signatures 886DDD89
pub   rsa2048 2009-09-04 [SC] [expires: 2020-08-29]
A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89
uid           [ unknown] deb.torproject.org archive signing key
sig          EE8CBC9E886DDD89 2014-08-31  deb.torproject.org archive signing key