What is the Web of Trust?
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 firstname.lastname@example.org gpg: data source: http://keys.fspproductions.biz:11371 (1) Peter Beard <email@example.com> Peter Beard <firstname.lastname@example.org> 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 "email@example.com". Enter number(s), N)ext, or Q)uit > 1 gpg: key B4A371011B4ED7ED: "Peter Beard <firstname.lastname@example.org>> 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?
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.) <email@example.com> sig 3 5DF274C713D0B439 2017-03-01 Peter Beard (This is a sample key.) <firstname.lastname@example.org> 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:
- No verification
- Some verification; maybe you just believe that the key belongs to who it says it does and sign it because of that
- 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
- 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 EB5A896A28988BF5 2009-09-11 [User ID not found] sig 3B9D093F31B0974B 2009-09-13 [User ID not found] sig 6215964F5B172AB2 2010-02-18 [User ID not found] sig 4E530019A1A1BC05 2010-02-19 [User ID not found] sig 85F7263127A1C89A 2010-10-17 [User ID not found] sig 8443317B0655F780 2014-02-22 [User ID not found] sig 3 290C1249BDD8700B 2013-10-07 [User ID not found] sig 3 X DE7AAF6E94C09C7F 2009-09-04 [User ID not found] sig 6B37812C5B54D68C 2010-10-22 [User ID not found] sig 83A2390BFDA28A1A 2011-06-30 [User ID not found] sig 4EA514E5B41AE6A8 2014-08-03 [User ID not found] sig 7D7D11BF629D5A67 2015-05-24 [User ID not found] sig 8758327A109F2591 2013-03-29 [User ID not found] rev 4EA514E5B41AE6A8 2014-08-03 [User ID not found] sig E3B15E8A6F10FC42 2010-11-05 [User ID not found] sig 63909BE27B5D666B 2010-09-16 [User ID not found] sig FD84FCB8F5B43047 2011-09-28 [User ID not found] sig 7FA91EDA1A999D84 2012-09-08 [User ID not found] sig 2C9AC597AF4FF87F 2012-09-21 [User ID not found] sig 77167744C9E8E428 2013-02-27 [User ID not found] sig 48EB8B2D66BEBCE3 2014-01-17 [User ID not found] sig D82FE03CC55BCFE3 2014-02-20 [User ID not found] sig 1 8FA9604645CB7EF7 2014-07-10 [User ID not found] sig 3 4EC6072329606E77 2010-11-15 [User ID not found] et cetera sig FBEA3110A8537894 2016-03-15 [User ID not found] sub rsa2048 2009-09-04 [S] [expires: 2018-08-30] sig EE8CBC9E886DDD89 2014-08-31 deb.torproject.org archive signing key
That's the .deb signing key for the Tor project. You can see it has quite a few signatures, meaning that it's probably pretty trustworthy. To decide for sure, you have to trust some of the other keys in the chain first.