Philip Sugg

Foundational GPG Concepts

Portfolio-Home

A consumer-driven program like GPG Suite makes it possible for ordinary users to encrypt, sign and decrypt emails with a few clicks. Once everything is set up, working with encrypted documents and email appears to “just work.” GPG Suite conceals with underlying calls to the API that would otherwise have to be performed manually at the command line.

While the everday process of using the PGP¹ system is automated beneath GPG Suite’s graphical interface, long-term successful use of GPG also requires some background knowledge. Users must still be able to manage a public and private keys, a task which includes understanding when and how to create new keys, how to interpret important key metadata, and how to exchange keys with other users of the GPG system.

This guide provides a practical introduction to the most important concepts in the GPG system.

Technical Requirements

1. Apple MacOS Catalina, version 10.15.7 or higher
2. GPG Suite, version 2022.1 or higher

Audience

Any user of GPG tools. No prior knowledge of cryptography is assumed.

Prerequisites

This guide will deepen the user’s practical understanding of the GPG protocol. It is intended for users who have already navigated basic GPG operations like signing email and encrypting a file. Before using this guide, complete both Learning the GPG System with GPG Suite and Apple Mail and Using GPG to Sign and Encrypt Ordinary Files.

Goals

The purpose of this conceptual guide is to give users an overview of important concepts within the PGP system. These include

1. Identity
2. The Web of Trust
3. Keys and Subkeys
4. Levels of Trust
5. Key Fingerprints

At the conclusion users should be empowered to use these concepts to become fully knowledgeable participants in the PGP system.

I. PGP’s Concept of Identity

One of the most important things to understand about the PGP system is that it is tied to the idea of a trusted identity. The connection between your public and private key may be guaranteed by its encryption scheme, but the communication is only secure if the person at the end of the message is who they claim to be. The weakest link in any form of electronic security is the user. Therefore you, the user, must be willing to take an active role in your own security by safeguarding and building trust in the identity attached to other keys. 4 It is easy to think about the importance of protecting your private key from discovery, or your public key from being used by an unauthorized actor. But it is equally important to protect your identity. This means you think of your public and private keys not as a tool for signing, but as an identity card, a proof of who you are. PGP is not actually a system with just one public and private key per user, but a network of keys linked together. Each key is linked to others through what is known as the “web of trust.”

II. The Web of Trust

PGP builds a set encryption technologies around human practices of trust. Encryption is a technology, but a qualitative model of trust underlies it. Without it users will fail in their use of PGP encryption.

Trust is built into most basic function of GPG: signing keys. You have encountered the idea of signing emails. A signed email is one which, the key attests, belongs to the person (the identity) that owns the key. But a private key can be used to sign almost anything electronic: a document, a photo, an electronic directory–even another key. In fact, signing other keys is one of the main ways that trust in identity is established within the PGP system.

To understand what it means to sign another key, first we must introduce the concept of subkeys.

For more on the web of trust model, see Wikipedia

III. Keys and Subkeys

Subkeys are just another key attached to your main key. They are easily created within the GPG tool suite.

Open up your GPG keychain app, and you should see three tabs: “Keys,” “User IDs,” and “Subkeys.” Go to “subkeys,” and you should see at least one subkey listed already.

Click the “+” button to create another key.

A small menu will appear, showing the email identity to which your subkey will be attached:

You will also see a dropdown “key type menu,” in which you can create subkeys subkeys with a designated encryption scheme, and limit them to signing-related functions:

Go ahead and create a key as a test–it doesn’t matter what type at this stage. What you have seen so far is that a subkey, unlike your private key, is always created for either signing or encryption, but not both. You can create as many as you want to. You can have one subkey only for signing emails to a single recipient, and another for encrypting emails to everyone else with whom you communicate.

Standard GPG practice encourages you to use as many subkeys as you think you need, but to reserve your main key only for for functions tied to securing and validating your identity. Your main key carries a lot more weight than just validating any particular signature or email–it validates you, proving that you are who you say you are. It can also be used to sign other people and validate them (see the next section, “Trust Levels,” for more on this) Only use your primary key for functions connected to identity validation. This includes:

1. Signing other people’s keys
2. Signing your own keys (subkeys)
3. Changing metadata (expiration data, etc.) on your own keys.

IV. Key Signing

You have already signed another key when you created your first subkey. Your main key attaches its subkeys to itself by signing them.

You can get a taste of signing other keys on the “User IDs” tab of the detailed key view. The bottom panel lists the other keys you have signed.

If you don’t have a friend handy with another key to sign, you’ll have to pick a second practice key. Click on the plus sign to select the second key you want to sign. A screen similar to this will appear:

V. Levels of Trust

Choosing a trust level is a required part of the key signing process

Trust must be set explicitly for each key that you interact with. This includes your keys, and other people’s keys. The trust section is at the bottom of the detailed key menu:

What a GPG beginner needs to understand is that there are essentially three core levels of trust:

1. Ultimate trust: only for keys and subkeys that you create and control
2. Full trust: you trust another key enough to let it vouch for other, unknown keys. For example, if I mark “full” trust Alice’s key, and Alice does the same for Bob’s key, then I fully trust Bob’s key, too.
3. No trust, which can cover either a key that you actively do not trust for some reason, or one which is so far unknown to you.

VI. Key Fingerprints

If you click on an individual key in your keychain, you will see a detailed view that looks like this:

Take a look at the field labeled “Fingerprint” in the example:

4B4F 3FE1 07E3 AA2A C6ED EDFD D102 7962 3F53 E57F

The fingerprint is a unique, shortened representation of your actual public key. It is not the public key itself. The above fingerprint is only 50 characters, including spaces. The actual public key equivalent is over 3000 characters. The purpose of the fingerprint is to create a memorable shorthand of your actual key, for you and any other human beings who need to read and keep track of it.

While your fingerprint may not look particularly memorable, a good fingerprint has three virtues:

1. It is systematically tied to your public key–and only your public key–in a way that is reproducible. This is usually by means of what is called a “hash” function.
2. It is human-readable: just short enough to be recognizable, which means you can easily compare it to a record of a known public key at a glance.
3. It is long enough to be secure against a brute force attack by today’s computing power

Your fingerprint is computed based on your public key. Anyone to whom you send your public key would be able to read this fingerprint, too. A fingerprint identifies a complete set of keys–both the public and private components.

There is no separate fingerprint for your private key. This is because your public key can actually be derived from your private key (the reverse is not true). This is what happens, for example, when someone sends you a message that has been encrypted using your public key.

Since the method for deriving fingerprints from your any key, public or private, is part of the GPG system, there should never be a reason to share your fingerprint directly with another party. Sharing your public key should be sufficient to identify yourself to other users.

This leads us to a more general rule about using PGP encryption in a safe manner: know what information other parties need to know about your keychain to accomplish specific tasks, and provide only that information on a ‘need to know’ basis.

If your use GPG on a regular basis, you will probably come to recognize at least the last few digits of your public key fingerprint by sight. If you examine the output of some cryptographic APIs, you may see them presenting a truncated version of your full fingerprint. Perhaps just the last 24 or 16 digits, as in these lines outputted by one mail program:

ENC_TO 48DA69916F85DE0F 1 0

Another caveat: beware of any program or entity that presents a very short representation of a hash as “proof” of a full fingerprint. Fingerprints will sometimes be shortened to make them easier to quickly compute during a cryptographic operation–but this can only be pushed so far. The shorter a hash is, the easier it is to “spoof” using a second, fake set of keys whose fingerprint appears to match another identity. If you see a hash shorter than 12 or 16 digits, don’t be afraid to ask for more proof of identity, or dig in further to the output of your cryptographic program to figure out what is happening behind the scenes.

Permalink