GPG for the Working Man — Part 1 (signatures)

The goal of this article is to get you up to speed on two of the main uses of GPG: cryptographically signing and verifying signatures on data.

Note: this post is the first in a series aimed at developing a functional use of GPG for the day-to-day tasks of anyone who cares about software. Check out part 2 for the lowdown on how to encrypt and decrypt messages.

GPG stands for GNU Privacy Guard and is a small open source piece of software that allows you to manage keys for cryptographic purposes. GPG implements the OpenPGP standard maintained by the Internet Engineering Task Force. In practice, the terms GPG, OpenPGP, and PGP are often used interchangably even though they probably shouldn't be. You can think of OpenPGP as email and GPG as one implementation of the email protocol (like Hotmail or Gmail).

One important aspect of cryptographic keys is that they are simply numbers. They are often really, really big numbers, but simple integers nonetheless. Another important aspect of cryptographic keys as used in GPG is that they come in pairs: a public key and a private key. Knowledge of these numbers (the keys) allows us to perform many tasks, two of which we'll tackle here:

  1. Signing a piece of data in a way that only a person knowing a specific key could have done.
  2. Verify the validity of a signature from someone else on a specific piece of data.

GPG does much more, but this post is really about those two basic tasks and their related options.

There is much more to learn about privacy, encryption, and GPG than I cover in this series; for information on who invented this whole thing in the first place, check out Phil Zimmermann's Wikipedia page; for more on the difference between GPG and PGP, check out this article; to dig deeper into the specifics of GPG, check out their docs.


Installing the Software

First, make sure you have GPG installed on your computer. You can get it on MacOS using homebrew (brew install gpg), on Linux using any of the package managers, or on Windows by downloading the binaries directly from the GnuPG official website. You will also need a bash terminal to interact with the software.

# if this returns a version number, you're good!
$ gpg --version

Creating Keys

The first thing that we want to do is create a key set (a public and a private key pair). I recommend creating an set of test keys with a simple password to use for the rest of this tutorial, and deleting it afterwards:

$ gpg --full-generate-key  # generate a new key

The process of creating a new key pair requires that we answer some question about key type and size, as well as associate some information with the keys. If you answer the few questions required to build keys, you should soon find that you now have a key set available in your GPG keyring. To see what keys are available, enter:

$ gpg --list-keys
pub   rsa1024 2019-09-14 [SC]
uid           [ultimate] MrAnderson <>
sub   rsa1024 2019-09-14 [E]

We now have a key pair available to us for the tasks below. The --list-key command outputs some metadata (?) about the key, as well as a fingerprint—the 0E94A26389C61705D08560DFE8C2F3D9893479A7 part. The fingerprint is a hash of the public key, and can therefore be used for identification.

Exporting and Importing Keys

To verify the validity of your signature on data or encrypt messages destined for you, other users will need to have your public key information. We can export our public key to a file using the following command, and then simply share the file with anyone we wish:

gpg --export --armor MrAnderson > MrAndersonPubKey.asc

Once you have someone's public key file, you'll need to import it into your keyring before being able to use it:

gpg --import MorpheusPubKey.asc

ASCII-armor Format

You can share your keys in binary format, or, often more conveniently, in a text format called ASCII-armor. You can print your public key to the console using the name or the email associated with the key as the last argument as in gpg --export --armor MrAnderson, or generate a file with your key in it using the following commands:

# generate public key file in binary format
$ gpg --export MrAnderson > myBinaryPubKey.gpg

# generate public key file in ASCII-armor format
$ gpg --export --armor MrAnderson > MrAndersonPubKey.asc

# print content of key file in ASCII-armor format to console
$ cat MrAndersonPubKey.asc


Both the binary format and the ASCII-armor format are representations of the same data, but you'll find that the ASCII-armor is much easier to share (for example you could copy/paste it in an email or a text message).

Task 1: Sign a document (without encrypting it)

Signing a document (or any piece of data) creates proof that the document was signed by the owner of a specific public key, and that the document was not tampered with after the signature. Note that the signature is completely agnostic to the data it is signing, meaning that we can use GPG to sign sound data, text data, image data, or any other type of data we want.

The goal here is really to sign an open document. There is no encryption of the document in this procedure. As such, the document is usable by anyone whether or not they can verify its signature.

One of the common objectives of signatures is to attest that a specific version of the data is being stored or sent across a network. Once a piece of data has been signed, changing a single bit in the data will render the signature invalid. This is why, for example, the lead maintainer of the bitcoin core software will sign the downloadable releases of the software. Once downloaded, you can test for yourself whether his or her signature is valid on the download you just performed. If the signature is valid, you are in posession of the exact same piece of code that he or she signed. If the signature is invalid, the download was tampered with on its way to you. You can use this as an assurance that the software you download is trustworthy without having to trust the network you download it on. Note that it does not prevent the signator from writing bugs or malware into the software at all—it only attests to the fact that the version in your possession is the same as the version that was signed, bit for bit.

Let us suppose you have a file called message.txt in your current directory with the content hello, world, and that you wish to sign it.

gpg --sign message.txt

outputs a new file in the same directory called message.txt.gpg that contains the signature and the original message. The message is not encrypted. Anyone can retrieve the message from the file, whether they verify the signature or not.

Notice that the signed file is in .gpg format, a binary format. This can make it inconvenient to look at or share (try cat message.txt.gpg to see what I mean). Another very common way to save the file is in ASCII-armor format using the --armor command like so:

gpg --sign --armor message.txt

The output file will be message.txt.asc, and will look something like this:



You can then copy and paste this anywhere to share or store the signed message. For example you could post it publicly on a website, send it as a text, or even write it down on a piece of paper.

Task 2: Verify the signature of a document

Let us assume someone has sent us a signed document (message_from_Morpheus.txt.asc) and we wish to verify its signature. We can use the --verify option to do so:

$ gpg --verify message_from_Morpheus.txt.asc
gpg: Signature made Sat 14 Sep 18:55:38 2019 EDT
gpg:                using RSA key 5F35BF8A88567B756A5F06898DFB48E3D8717A99
gpg:                issuer ""
gpg: Can't check signature: No public key

Note that if you simply have the file but not the public key of the signator in your keyring, the --verify command will state that the signature could not be verified as valid.

To validate the signature, we'll first have to import the public key of the signator on our GPG keyring. In this case let's assume your friend Morpheus just sent you his public key in ASCII-armor format (he knows how to export his key because he read Task 1 of this post), and the file is saved under MorpheusPubKey.asc. You can import his key in your keyring using:

$ gpg --import morpheusPubKey.asc
gpg: key 06898DFB48E3D899: public key "Morpheus <>" imported
gpg: Total number processed: 1
gpg:               imported: 1

Now if you list your keys, you'll find you have 2 keys in your keyring:

$ gpg --list-keys
pub   rsa1024 2019-09-14 [SC]
uid           [ultimate] MrAnderson <>
sub   rsa1024 2019-09-14 [E]

pub   rsa1024 2019-09-14 [SC]
uid           [ unknown] Morpheus <>
sub   rsa1024 2019-09-14 [E]

When first importing a key, it won't be certified by default (GPG does not assume you really know that the key is the key from the person who it says it belongs to). The key could have been tampered with on its way to you, and anyone can create keys with anyone else's name. GPG does not, in any way, verify that you are the person who's name you are using to create a key.

It is recommended that you check that the key in your keyring belongs to the person you think it does using multiple sources, or that you take the time to call or text the person to verify. Once that is done, you can sign that key yourself with your own private key, adding a layer of protection to the validity of your friend's public key in your key ring.

gpg --sign-key Morpheus

This will identify the key as [full] instead of [unknown] in our keyring. Notice that we do not need to sign a public key to use it in signature verification; it simply is an added layer of certainty when verifying signatures.

Once we have the public key of the signator of the piece of data we wish to verify in our keyring, we can verify the signature on any file in one line of code. GPG will print the result of the signature verification on the console. In the case of a valid signature, it would look like this:

gpg --verify message_from_Morpheus.txt.asc
gpg: Signature made Sat 14 Sep 18:55:38 2019 EDT
gpg:                using RSA key 5F357AF0687B756A571BF8A885698DFB48E3D899
gpg:                issuer ""
gpg: Good signature from "Morpheus <>" [full]

To see the content of the message, you'll want to either print it to the console or create a new file with the original message in it.

$ gpg --decrypt message.txt.asc
what's up dog?
gpg: Signature made Sat 14 Sep 18:55:38 2019 EDT
gpg:                using RSA key 5F357AF0687B756A571BF8A885698DFB48E3D899
gpg:                issuer ""
gpg: Good signature from "Morpheus <>" [full]

which will print it to the console, as well as print the result of the signature verifcation. You could have used --decrypt on a message without the public key in your keyring and GPG would still have printed the message, but it would have told you that it could not verify the signature the same way as it did above with the --verify command.

Anyone in posession of the file can also output the original data to a file using

$ gpg --decrypt message_from_Morpheus.txt.asc > Morpheus_message_only.txt
gpg: Signature made Sat 14 Sep 18:55:38 2019 EDT
gpg:                using RSA key 5F357AF0687B756A571BF8A885698DFB48E3D899
gpg:                issuer ""
gpg: Good signature from "Morpheus <>" [full]

# the cat command prints to console the contents of a file
$ cat Morpheus_message_only.txt
what's up dog?

This will print the verification of the signature to the console as the file is created, but the signature verification will not be included in the newly created file; the new file is now an exact replica of the original file.



Note that the signature file build in ASCII-armor format in Task 1 does not contain a human readable version of the original data (in this case the string hello, world). The file is not encrypted, but you'll need gpg installed and a command to show its content.

# create a signature file named message.txt.asc
$ gpg --sign --armor message.txt
$ cat message.txt.asc



Using the --clearsign command on ASCII-armor format to sign a document (rather than the --sign command) will include the original data in the signed file. The resulting file keeps the signed message at the top, making it easy to parse, whether we verify the signature or not.

$ gpg --clearsign --armor message.txt
$ cat message.txt.asc

Hash: SHA256

hello, world


Detached Signatures

A popular way to sign software is through the use of detached signatures. A detached signature is a small file that sits external to the actual softare or piece of data being signed.

Detached signatures have one great advantage over normal signatures: because they are separate, they are not mandatory in order to use the data. The signatures for popular software (say, Python, for example), are downloaded separately, and therefore do not interfere with one's ability to simply download and start using the software. On the other hand, verifying the validity of such signatures is just as easy as it is with regular signatures.

We create a detached signature using the following command, which will produce a small file called mySoftware.dmg.sig:

$ gpg --detach-sign mySoftware.dmg
$ ls

Now let us assume we have downloaded a piece of software and its associated signature (python.dmg and python.dmg.sig). Provided the files are in the same directory and have the same name, we can verify the signature like so:

$ ls

$ gpg --verify software.dmg.sig
gpg: assuming signed data in 'python.dmg'
gpg: Signature made Sat 14 Sep 19:28:09 2019 EDT
gpg:                using RSA key 0E49C5D08660D9A2638FE8C2F31705D9893479A7
gpg:                issuer ""
gpg: Good signature from "MrAnderson <>" [ultimate]

That's it! Check out part 2 for how to encrypt and decrypt data using GPG.

01 Jan, 2020