Welcome back to the GPG series, where we are exploring how to make use of GPG with other applications to secure and protect your data. In the first installment, we covered the functions of GPG. You learned about integrity, non-repudiation and authenticity. In the second installment, key creation and publication were covered, as well as revocation certificate creation. The third article in the series covered using your key to sign and encrypt files or communications.

This final installment will cover managing GPG keys in greater depth, including the Web of Trust and key signing parties. It will also discuss exporting, adding, and removing keys, using sub-keys and retrieving public keys.

Web of Trust

The true power of GPG keys is when they are used to communicate with others. In order for that to work, you need to trust the public keys you download and others must also trust your key. When you first start, your network might be small and composed only of people you know. Eventually, your network may include people that have several degrees of separation. You will be able to trust keys of people you don’t know because people you do know have signed their key. This is the basis of the Web of Trust. It is a network of keys that can be trusted based on interconnected signatures and trust.

Scenarios

No separation

"I trust my brother. I trust his key."

1 Degree of Separation

"I trust my brother to only sign keys of people he trusts, so I will sign keys of people he signs that I do not know."

2 Degrees of Separation

"I trust the keys my brother has signed, but I do not trust those people to sign keys properly."

When trusting a key separated by several degrees, you need a chain of signatures. To increase your ability to find a chain, you will want to get your key signed by others outside of people you know personally.

A good way to do that is to attend a key signing party. When you are attending a conference, look ahead of time for a key signing party or offer to organize one yourself.

What is a key signing party?

A key signing party is a get-together of people who use the GPG encryption system. The purpose of the gathering is to allow those people to sign each others keys. Key signing parties serve to extend the Web of Trust to a great degree. This article will not cover key signing parties in depth because there are already several excellent resources on the web.

Adding and removing GPG keys

There are two ways of adding keys to your keyring. The one most often thought of is retrieving a key from a public key server. The other is to use a digital file and import it to your keyring. The most typical case for using digital files is when you are moving your own key from one machine to another. In this case, you will import both the private and public keys from files you exported.

Seahorse

From the main Seahorse window, select Remote > Find Remote Keys… This will bring up a search dialog that allows you to search key servers using email addresses or fingerprints.

After entering the email or fingerprint you are searching for, you can select or de-select servers to be searched. Once you hit search, a list of keys matching the criteria will be returned.

As you can see in the example above, there can be multiple keys returned in a search (usually this happens if someone has migrated from an old key to a new key). Click on the correct key and the click the Import button. There is no feedback that the key was imported successfully, but it will now be listed in the list of GPG keys as long as the view Show Any is selected under the View menu. If you want to delete a key from your keyring, just right click on the key in the list and select Delete from the options.

You will then be prompted to confirm the deletion. Once that is done, the key will no longer be available to use.

Command Line

To retrieve keys from a key server using the command line, use the following command.

$ gpg2 --recv-keys D172C836 gpg: requesting key D172C836 from hkp server keys.gnupg.net gpg: key D172C836: "Justin W. Flory <me@justinwflory.com>" 26 new signatures gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 2 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 2u gpg: next trustdb check due at 2016-11-09 gpg: Total number processed: 1 gpg: new signatures: 26

The command line option gives better feedback on the fact that the key was imported and what its status is in your Web of Trust.

To delete a key using command line, use the following command.

$ gpg2 --delete-keys D172C836 pub 4096R/D172C836 2014-09-24 Justin W. Flory <me@justinwflory.com> Delete this key from the keyring? (y/N) y

You can confirm that the key is no longer available by using the

gpg2 --list-keys

command. This will list all of your saved keys. If you have a long list of keys, you may want to use

gpg2 --list-keys | grep D172C836

to filter the results down to the key you are looking for.

Editing GPG keys

Keys on your keyring can be designated with varying levels of trust. Because these keys will form a chain of trust, the levels have to take in to account two factors:

Can you verify that the person asking for the key to be signed is who who they claim to be?

Can you trust the person asking to have their key signed to follow good key signing practices? Or, in other words, can you trust the keys they sign?

There are different levels of trust you can assign to a key. The levels are:

Unknown: Nothing is known about the owner’s judgment in key signing. Keys on your public keyring that you do not initially own have this trust level.

Nothing is known about the owner’s judgment in key signing. Keys on your public keyring that you do not initially own have this trust level. None : The owner is known to improperly sign other keys. In other words, you don’t trust them.

: The owner is known to improperly sign other keys. In other words, you don’t trust them. Marginal : The owner understands the implications of key signing and properly validates keys before signing them.

: The owner understands the implications of key signing and properly validates keys before signing them. Full : The owner has an excellent understanding of key signing, and his signature on a key would be as good as your own.

: The owner has an excellent understanding of key signing, and his signature on a key would be as good as your own. Ultimate: This should only ever be used for your own keys. You are the only person you can trust ultimately!

As was the case in GPG key management, part 1, either Seahorse or the command line can be used to perform these key management tasks.

Another function of editing keys is to change the expiration date of the key. This is useful when your key is nearing expiration and you still want to use the key. As you may recall from GPG key management, part 1, key expiration is one of the safeguards in key management.

Seahorse

With Seahorse you can sign keys and designate a level of trust. To sign a public key in Seahorse, right-click on the key and select Edit. Then, in the dialog box that comes up, select the Trust tab. Yes, being labeled Trust is a bit odd, but it is the tab you use to sign the key.

To sign the key, just click the Sign this Key button. If you want to change the level of trust, you need to go to the Details tab.

To change the level of trust, open the drop down menu. In the current example, the drop down menu is the default level of Unknown. Seahorse allows for the following levels: Unknown, Never, Marginal and Full. Ultimate is reserved for your own key and not available for public keys.

Command Line

To sign a key using the command line, use the following command:

$ gpg2 --sign-key 014131E4 pub 4096R/014131E4 created: 2016-01-24 expires: 2020-01-23 usage: SC trust: unknown validity: unknown sub 4096R/50862BD9 created: 2016-01-24 expires: 2020-01-23 usage: E sub 4096R/F6ABF0B6 created: 2016-01-24 expires: 2020-01-23 usage: S [ unknown] (1). Justin W. Flory <me@justinwflory.com> [ unknown] (2) Justin W. Flory <jflory@me.com> [ unknown] (3) Justin W. Flory <jflory7@gmail.com> [ unknown] (4) Justin W. Flory <jflory7.v2@gmail.com> [ unknown] (5) Justin W. Flory (SpigotMC) <jflory7@spigotmc.org> [ unknown] (6) Justin W. Flory (CrystalCraftMC) <admin@crystalcraftmc.com> [ unknown] (7) Justin W. Flory (Fedora Project) <jflory7@fedoraproject.org> [ unknown] (8) Justin W. Flory (CrystalCraftMC) <crystalcraftstaff@gmail.com> [ unknown] (9) Justin W. Flory (Rochester Institute of Technology) <jwf9260@rit.edu> [ unknown] (10) Justin W. Flory (Server Logging Address) <automatedserverlogger@gmail.com> Really sign all user IDs? (y/N)

To edit a key, you use the following command:

$ gpg2 --edit-key 014131E4 pub 4096R/014131E4 created: 2016-01-24 expires: 2020-01-23 usage: SC trust: unknown validity: unknown sub 4096R/50862BD9 created: 2016-01-24 expires: 2020-01-23 usage: E sub 4096R/F6ABF0B6 created: 2016-01-24 expires: 2020-01-23 usage: S [ unknown] (1). Justin W. Flory <me@justinwflory.com> [ unknown] (2) Justin W. Flory <jflory@me.com> [ unknown] (3) Justin W. Flory <jflory7@gmail.com> [ unknown] (4) Justin W. Flory <jflory7.v2@gmail.com> [ unknown] (5) Justin W. Flory (SpigotMC) <jflory7@spigotmc.org> [ unknown] (6) Justin W. Flory (CrystalCraftMC) <admin@crystalcraftmc.com> [ unknown] (7) Justin W. Flory (Fedora Project) <jflory7@fedoraproject.org> [ unknown] (8) Justin W. Flory (CrystalCraftMC) <crystalcraftstaff@gmail.com> [ unknown] (9) Justin W. Flory (Rochester Institute of Technology) <jwf9260@rit.edu> [ unknown] (10) Justin W. Flory (Server Logging Address) <automatedserverlogger@gmail.com> gpg>

Once you are in edit mode, you can enter

help

or type

?

to get a list of options.

gpg> ? quit quit this menu save save and quit help show this help fpr show key fingerprint list list key and user IDs uid select user ID N key select subkey N check check signatures sign sign selected user IDs [* see below for related commands] lsign sign selected user IDs locally tsign sign selected user IDs with a trust signature nrsign sign selected user IDs with a non-revocable signature deluid delete selected user IDs delkey delete selected subkeys delsig delete signatures from the selected user IDs pref list preferences (expert) showpref list preferences (verbose) trust change the ownertrust revsig revoke signatures on the selected user IDs enable enable key disable disable key showphoto show selected photo IDs clean compact unusable user IDs and remove unusable signatures from key minimize compact unusable user IDs and remove all signatures from key * The `sign' command may be prefixed with an `l' for local signatures (lsign), a `t' for trust signatures (tsign), an `nr' for non-revocable signatures (nrsign), or any combination thereof (ltsign, tnrsign, etc.).

To change the trust level of a key, you would use the

trust

option at the

gpg>

prompt.

gpg> trust pub 4096R/014131E4 created: 2016-01-24 expires: 2020-01-23 usage: SC trust: unknown validity: unknown sub 4096R/50862BD9 created: 2016-01-24 expires: 2020-01-23 usage: E sub 4096R/F6ABF0B6 created: 2016-01-24 expires: 2020-01-23 usage: S [ unknown] (1). Justin W. Flory <me@justinwflory.com> [ unknown] (2) Justin W. Flory <jflory@me.com> [ unknown] (3) Justin W. Flory <jflory7@gmail.com> [ unknown] (4) Justin W. Flory <jflory7.v2@gmail.com> [ unknown] (5) Justin W. Flory (SpigotMC) <jflory7@spigotmc.org> [ unknown] (6) Justin W. Flory (CrystalCraftMC) <admin@crystalcraftmc.com> [ unknown] (7) Justin W. Flory (Fedora Project) <jflory7@fedoraproject.org> [ unknown] (8) Justin W. Flory (CrystalCraftMC) <crystalcraftstaff@gmail.com> [ unknown] (9) Justin W. Flory (Rochester Institute of Technology) <jwf9260@rit.edu> [ unknown] (10) Justin W. Flory (Server Logging Address) <automatedserverlogger@gmail.com> Please decide how far you trust this user to correctly verify other users' keys (by looking at passports, checking fingerprints from different sources, etc.) 1 = I don't know or won't say 2 = I do NOT trust 3 = I trust marginally 4 = I trust fully 5 = I trust ultimately m = back to the main menu Your decision?

Sub-Keys

The compromise of a GPG key is a serious issue and one that can be minimized by using sub-keys. Sub-keys are a feature of OpenPGP which allows keys which are subordinate to the main OpenPGP key. Most of the time, these keys are associated with the fingerprint of the main key, but it is possible for them to have their own fingerprints. The primary reason to use sub-keys is to minimize the impact of a lost or stolen device that has your keys on it. People who employ this strategy normally employ a main key and two sub keys. One sub key used for signing and the other for encryption. This article will not cover sub keys in depth because there are already excellent resources available discussing the details.

Seahorse can add sub-keys on the Details tab of the key properties.

If you are using the command line to edit your master key, you have an an additional option to add sub-keys.

gpg> addkey Please select what kind of key you want: (3) DSA (sign only) (4) RSA (sign only) (5) Elgamal (encrypt only) (6) RSA (encrypt only) Your selection?

From this point, the process is the same as generating a key as was discussed in GPG key management, part 1.

Using A Revocation Certificate

In GPG key management, part 1, we covered the automatic creation of a revocation certificate as well as why it would be used. While it is possible to revoke a key in Seahorse, I would recommend storing your revocation certificate in a separate location from your key. This will allow you to revoke the key even if you lose the key.

To revoke a certificate using Seahorse, you go to the Details tab of your key properties and click the Expire button.

As mentioned above, if you lost control of your key, you can use the command line to revoke the certificate. The steps are:

Retrieve your public key from a keyserver or import an armored copy of it.

Import your revocation certificate.

The following commands will import the public key and the revocation certificate from a saved file.

$ gpg2 --import cprofitt-key.asc gpg: key 2B9A96EA: public key "charles profitt <cprofitt@fakemail.com>" imported gpg: Total number processed: 1 gpg: imported: 1

$ gpg2 --import 538713F7D7395D0F24706B0106E078D72B9A96EA.rev gpg: key 2B9A96EA: "charles profitt <cprofitt@fakemail.com>" revocation certificate imported gpg: Total number processed: 1 gpg: new key revocations: 1 gpg: no ultimately trusted keys found

After importing your revocation certificate, your key will be revoked. The only step left is to send it to the key servers. Once you send your revoked key to the key server, there is no going back. Your key will be revoked and invalidated whenever it is used going forward.

This officially concludes the GPG series on the Fedora Magazine. With this new knowledge, we hope you are more informed about the basics of digital security, how to manage GPG keys, and how to use them in your own life.