About PGP

PGP, or "Pretty Good Privacy", is an encryption program developed by Phil Zimmerman in the early 1990's. It was one of the first programs to make public-key cryptography "easy" to use. The program was "freeware", meaning you could use it without paying a license fee, and the source code was available so that people could inspect it, and so that you could compile it on your own machines. However, it wasn't quite what we would now call "open source".

At the time, any cryptographic software which used keys longer than 40 bits was classified as a "munition" by the US State Department, and could not legally be sent out of the country using electronic means (i.e. downloading, email, IRC, etc.) PGP was capable of using keys up to 2047 bits long at the time, so the US Justice Department opened an investigation into the author. The investigation was eventually dropped after Daniel J. Bernstein (the author of qmail and djbdns) sued the United States over crypto export laws, and won, however Zimmerman's life was pretty rough for a while there.

Zimmerman ended up forming a company, PGP Incorporated, and tried to make a living by selling licenses. The company ended up being sold and re-sold a few times, and the original PGP product is now owned by Broadcomm, who does not appear to have any kind of product offering around it.

OpenPGP

OpenPGP is the message format originally used by the PGP software. It has been standardized as RFC 4880, and many people have written software which implements this standard.

GnuPG

GnuPG is the name of a program which implements the OpenPGP standard.

GnuPG is pretty much "the standard" PGP software used on almost all Linux distributions, and is available for macOS, windows, and several other operating systems. You can also download the source code and compile it for just about any other OS as well.

And unlike the original PGP software, GnuPG is "open source" software, available under the GNU GPLv3 license.

pgp and gpg

pgp is the name of the primary executable from the original PGP software.

gpg is the name of the primary executable from the GnuPG software. It was originally written to try and maintain compatibility with the command line options from the original pgp program, however it supports a LOT of features that pgp did not, so there are a lot of additional options.

You may also see references to a gpgv command. This is a stripped-down version of gpg which only verifies signatures.

Other Sites

I don't claim to be a great expert with PGP/GnuPG, only that I've been using it for a long time. A lot of the things I mention in this book came from other web sites. Some of these other sites are ...

• OpenPGP Best Practices
• GPG Cheat Sheet
• Creating the Perfect GPG Keypair

Public-key Cryptography

Shared-key cryptography refers to a system where the key used to encrypt a message, is also used to decrypt the message. This is also referred to as "symmetrical" encryption, since the same key is used for both encryption and decryption.

Shared-key systems are useful for encrypting "data at rest", such as files on a backup disk. They can also be useful when sending messages, if both parties already know the key.

However, if you don't already have a shared key with the people you're communicating with, you need to generate one, and then you need to figure out a way to give them the key, without also sharing it with the entire world.

Public-key cryptography uses a different type of algorithm, where each user has a pair of keys. The algorithms have an interesting mathematical property where, if a message is encrypted using one of the keys in a given pair, the resulting encrypted message can only be decrypted using the other key from the same pair. The key which encrypted the message, cannot decrypt it.

This is also referred to as "asymmetrical" encryption, since different keys are used for encryption and decryption.

As an example, if Alice encrypts a message using Bob's public key, she can send the resulting encrypted message using any mechanism she likes, including chat, email, posting it on social media, or even having it printed on a billboard next to the highway. However the message gets transferred, only Bob's secret key can decrypt it.

ℹ️ Who are Alice and Bob anyway?

The names Alice, Bob, Charlie, and so forth, are commonly used in examples which talk about encrypted messaging. The names are used because they start with A, B, C, and so forth. These are normally "the good guys", who are just trying to exchange secret messages with each other.

You may also see the name Mallory, who is traditionally "the bad guy". Mallory may be trying to read the encrypted messages, send fake messages that look like they came from one of the good guys, or otherwise interfere with how the system is designed. (I think I remember reading somewhere they wanted a name starting with "M" for "malicious"?)

Digital Signatures

A digital signature provides a way for people to verify ...

• that a message hasn't been changed since it was "signed".

• that a message really did come from the person who the signature claims that it came from.

They work like encrypted messages, but with the keys "swapped".

If Alice wants to send a "signed" message, she would ...

• Create a message.

• Calculate the hash of the original message. (Some signature schemes may include more information than this.)

• Encrypt the hash using her own secret key, and add her public key to that.

The result, comprised of the encrypted hash and a public key, is known as a Digital Signature, or just a signature. When she sends the original message, she sends the digital signature along with it.

When somebody receives the message and wants to verify signature, they would ...

• Decrypt the signature, using the public key it came with.

• Calculate their own hash of the original message.

• Compare the hash they calculated against the hash from within the signature. If they match, they can be sure that the message was not changed since that signature was created.

• If they already know Alice's public key, they can compare the public key from the signature against the public key that they already know belongs to Alice. If they match, they can be sure that Alice is the person who created the signature.

In practice it's a little more complicated than this, but if you undersood this example, you understand the basic concept of how digital signatures work.

Anatomy of a PGP key

As mentioned above, PGP uses pairs of keys - one public and one secret. However, a "PGP key" is actually a set of key pairs, with almost all PGP keys having two or more individual key pairs.

In the examples below, we'll look at my own PGP key.

$ gpg --list-keys --with-subkey-fingerprints 49B9FD3BB4422EBB
pub   rsa4096 2019-03-21 [SC] [expires: 2024-01-01]
      E3F7F5F76640299C5507FBAA49B9FD3BB4422EBB
uid           [ultimate] John Simpson <jms1@jms1.net>
uid           [ultimate] John Simpson <kg4zow@mac.com>
uid           [ultimate] John Simpson <kg4zow@kg4zow.us>
sub   rsa4096 2019-03-21 [E] [expires: 2024-01-01]
      3C8EC9C7B067A4C542F9727D795C2CF824364755
sub   rsa4096 2019-03-21 [S] [expires: 2024-01-01]
      77DEBB0C8C7FBAFF1E0E70DCE9E44ED30E2F2445
sub   rsa4096 2019-03-21 [A] [expires: 2024-01-01]
      7A6B95B6BF897A6497165AE436823233F8D09EB7

Yes, this is the actual PGP key I use on a regular basis.

If you like, you can download the key from here. You can also download and import it to your local keyring using a single command like so:

curl -s https://jms1.pub/jms1.pub.asc | gpg --import

If you're reading this on/after 2024-01-01, I will probably have updated the expiration dates, and may have forgotten to update this web page as well. If you're feeling generous, let me know via Keybase chat - my Keybase username is jms1.

Identities

PGP keys may contain one or more "identities". Each identity usually consists of a name and and email address, however they can be any arbitrary Unicode string.

In addition, an identity may also be a JPEG image. This is logically similar to how a drivers license or passport would contain your picture on it. I did this once in the past - it was fun to play with but ended up being more trouble than it was worth, so I don't bother anymore. (Besides ... let's be honest, nobody wants to look at my face.)

In the example above, each uid line is an identity. As you can see, each one is my name and an email address.

Keys and Sub-keys

Every PGP key has a "primary key" pair, and may have one or more sub-key pairs. These are normally referred to as just "keys" rather than "key pairs".

In the example above, the pub line is the primary key, and each sub lines is a sub-key.

Each key or sub-key has one or more "capability flags", which tell what the intended use of that key is. These flags are listed in square brackets, after the date the key was issued.

These flags are:

• Certification [C] - This key is meant to be used for digitally signing other PGP keys or sub-keys. (The same key may also have the [S] capability as well.)

  The [C] flag is always attached to a PGP key's "primary" key, and is never attached to any sub-key.

• Signing [S] - This key or sub-key is meant to be used for digitally signing messages.

• Encryption [E] - This sub-key is meant to be used for encrypting messages.

• Authentication [A] - This sub-key is meant to be used for authentication, including SSH.

In a "normal" PGP key, the primary key will have the [CS] flags (meaning both [C] and [S]), and there will be a single sub-key with the [E] flag. As you can see, my own key has a few extra sub-keys on it.

Key IDs

In the example above, the lines just below pub and sub contain long hex numbers. Those are "fingerprints", which are hashes of that key pair's public key.

The fingerprint of the primary key pair is called the Key ID. In this case, the Key ID is E3F7F5F76640299C5507FBAA49B9FD3BB4422EBB.

Most gpg commands will require a Key ID. This long value can always be used, however some shorter values which can be used as well, so long as they are unique within the keyring.

As you can see, the shorter values are the "low bits" from the full Key ID.

Be careful using short values, as the chances of two keys' fingerprints having the same low 32 bits (i.e. 1 in 2³²) are a LOT higher than the chances of two keys having the same 160-bit fingerprint (i.e. 1 in 2¹⁶⁰).

In addition, you can also use an identity, or part of an identity, as a Key ID, so long as only one key in your keyring matches what you entered. This means if you only have a single key containing "jms1" in it, you could use "jms1" as an identity.

If you're not sure, you can run something like "gpg --list-keys jms1" and make sure it only lists the one key. If it lists more than one, you should find some difference between them and use something more specific. (Or just, you know, use the full 160-bit Key ID.)

Keyrings

Every PGP program has a "keyring". This is a set of files containing public and secret keys. A keyring will usually keep the public and secret keys in different files, however the files will be in the same directory.

On systems which support multiple users, each user has their own keyring directory. For GnuPG, this is a directory called ".gnupg" under the user's home directory.

If you need to use a different directory, you can create a GNUPGHOME environment variable whose value points to the directory you want to use. (This is actually something I do when I'm working on documentation like this and need to create "dummy" keys without touching the real keyring on my computer.)

Certifications

Almost every PGP key has one or more identities. And anybody in the world can create a PGP key which contains any identity they like. If you find a PGP key online with the name "Tim Cook <tim.cook@apple.com>", how do you know if that's really his key or not? (Or more likely, if you find several hundred keys online with that identity, how do you tell which ones, if any, are real?)

PGP keys can be certified, or "signed", by other PGP keys.

A certification is a digital signature, made by another PGP key. The idea is, if you're able to verify that signature, and you already "trust" the key which created the signature, you can feel more confident in "trusting" the key which was signed.

For example ...

• You find a PGP key online which has the name and email address of a co-worker.

• You didn't get the key directly from them, so you're not sure if it's really their key or not. (Remember, anybody can create a PGP key with any name and email address.)

• The key you found online was signed by my key.

• You already know and "trust" my key.

  Maybe I gave you my Key ID in person, maybe you imported it directly from my Keybase account, maybe the Key ID matches the Key ID printed on a business card that I handed to you (I used to do this), maybe you physically met me in person at a "key signing party" and verified a photo ID or something ... whatever the reason, the point is:

  • You trust that it's really my key.

  • You trust that I understand how key-signing works, well enough to NOT sign other peoples' keys without first verifying that the key I'm signing, really belongs to them.

Because you "trust" my key (in this example), as long as you're able to verify the signature on the key you found, you can be fairly confident that the key you found really does belong to that co-worker.

Technically, identities are being certified.

Each signature certifies that the PGP key really belongs to the person named by that identity. If a key starts with one identity, gets a few signatures, and then has additional identities added to it, the existing signatures on the first identity do not automatically apply to the new identities.

Smartcards

A "smartcard" is a physical card, containing a "smart chip". These chips are actually miniature computers. The chip has a processor, a small amount of storage (usually measured in kilobytes), and a set of I/O lines used to talk to a card reader, which is usually attached to a computer. These are similar to the SIM cards used by many mobile phones, and the security chips used by most credit cards.

An "OpenPGP Card" is a smartcard (or other device, like a YubiKey) whose chip has two things:

• Storage on the chip itself, which can store PGP keys or sub-keys.

• Software on the chip to perform the encryption and decryption operations needed by PGP.

The card performs the PGP operations which need secret keys (decryption and signing) using the keys stored within the chip. This means that the secret keys never need to be sent to the computer.

The OpenPGP Specification describes the API (protocol, language, etc.) used when talking to OpenPGP Cards. Several dozen companies around the world make cards or other devices which implement this API. GnuPG is capable of interacting with any of them.

YubiKey 5 Series

This "book" talks about the YubiKey 5 series, which implements the "OpenPGP Card" standard.

Almost everything in this book which mentions a YubiKey, could also apply to any other device which implements the OpenPGP Card standard.

Older YubiKey devices

The older YubiKey 4 and YubiKey Neo devices also implemented the OpenPGP specification, however they did not support ED25519 keys, and they are limited to 2048-bit RSA keys.

In addition, some YubiKey Neo devices may have older software with a security issue. At the time they were replacing the affected YubiKey Neo devices for free (and in fact they replaced mine), however this replacement program was ended in 2019. (If you're still using an old YubiKey Neo, it's really time to upgrade.)