GNU Privacy Guard (GPG)
1832 words · 10 minutes
The History of GPG
GNU Privacy Guard, also known as GnuPG and GPG, is a free ("free" as in both speech and beer) software that fully implements the OpenPGP Message Format documented in RFC 4880.
I won't go in-depth on the full history of the software in this post, but it is important to understand that GPG is not the same as PGP (Pretty Good Privacy), which is a different implementation of RFC 4880. However, GPG was designed to interoperate with PGP.
GPG was originally developed in the late 1990s by Werner Koch and has historically been funded generously by the German government.
Now that we have all the high-level info out of the way, let's dive into the different aspects of GPG and its uses.
GPG supports a wide range of different encryption algorithms, including public-key, cipher, hash, and compression algorithms. The support for these algorithms has grown since the adoption of the Libgcrypt library in the 2.x versions of GPG.
As you will be able to see below in an example of a full key generation with the GPG command line tool, GPG recommends the following algorithms to new users:
() () ()) ()) ()) ())
I am not doing an in-depth explanation here in order to keep the focus on GPG and not encryption algorithms. If you want a deep dive into cryptography or encryption algorithms, please read my other posts:
- AES Encryption (2018)
- Cryptography Basics (2020)
As of 2022-07-14, there a few different vulnerabilities associated with GPG or the libraries it uses:
- GPG versions 1.0.2 - 1.2.3 contains a bug where "as soon as one (GPG-generated) ElGamal signature of an arbitrary message is released, one can recover the signer's private key in less than a second on a PC." (Source)
- GPG versions prior to 22.214.171.124 contain a false positive signature verification bug. (Source)
- GPG versions prior to 126.96.36.199 cannot detect injection of unsigned data. (Source)
- Libgcrypt, a library used by GPG, contained a bug which enabled full key recory for RSA-1024 and some RSA-2048 keys. This was resolved in a GPG update in 2017. (Source)
- The ROCA Vulnerability affects RSA keys generated by YubiKey 4 tokens. (Source)
- The SigSpoof Attack allow an attacker to spoof digital signatures. (Source)
- Libgcrypt 1.9.0 contains a severe flaw related to a heap buffer overflow, fixed in Libgcrypt 1.9.1. (Source)
Originally developed as a command-line program for *nix systems, GPG now has a wealth of front-end applications and libraries available for end-users. However, the most recommended programs remain the same:
Creating a Key Pair
In order to create a GPG key pair, a user would first need to install GPG on their system. If we're assuming that the user is on Fedora Linux, they would execute the following:
Once installed, a user can create a new key pair with the following command(s):
GPG will walk the user through an interactive setup that asks for an algorithm preference, expiration date, name, and email to associate with this key.
See the following example key set-up for a default key generation using the GnuPG command-line interface:
; ) () () ()) ()) ()) ()) () () () <n> = <n>w = <n>m = <n>y = ) ) ) ) ) ) ) ) ; ) ; ) <[email protected]> )
Please note that GUI apps may differ slightly from the GPG command-line interface.
As noted in RFC 4880, the general functions of OpenPGP are as follows:
- digital signatures
- Radix-64 conversion
- key management and certificate services
From this, you can probably gather that the main use of GPG is for encrypting data and/or signing the data with a key. The purpose of encrypting data with GPG is to ensure that no one except the intended recipient(s) can access the data.
Let's explore some specific GPG use-cases.
One of the more popular uses of GPG is to sign and/or encrypt emails. With the use of a GPG keypair, you can encrypt a message, its subject, and even the attachments within.
The first process, regarding the signing of a message without any encryption, is generally used to provide assurance that an email is truly coming from the sender that the messages claims. When I send an email and it's signed with my public key, the recipient(s) of the message can verify that the message was signed with my personal key.
The second process, regarding the actual encryption of the message and its contents, works by using a combination of the sender's keys and the recipients keys. This process may vary slightly by implementation, but it most commonly uses asymmetric cryptography - also known as public-key cryptography. In this version of encryption, the sender's private key to sign the message and a combination of the sender's keys and the recipient's public key to encrypt the message.
If two people each have their own private keys and exchange their public keys, they can send encrypted messages back and forth with GPG. This is also possible with symmetric cryptography, but the process differs since there are no key pairs.
Implementation of email encryption varies greatly between email clients, so you will need to reference your email client's documentation to ensure you are setting it up correctly for that specific client.
As noted in the section above regarding emails, GPG enables users to be able to send message to each other if they are both set-up with GPG keys. In this example, I am going to show how a user could send a file called
example_file.txt to another user via the recipient's email.
The sender would find the file they want to send and execute the following command:
Once received, the recipient can decrypt the file with the following command:
One important aspect of GPG, especially for developers, is the ability to sign data without encrypting it. For example, developers often sign code changes when they commit the changes back to a central repository, in order to display ownership of who made the changes. This allows other users to look at a code change and determine that the change was valid.
In order to do this using Git, the developer simply needs to alter the
git commit command to include the
-S flag. Here's an example:
As an expansion of the example above, Git users can configure their environment with a default key to use by adding their GPG signature:
If you're not sure what your signature is, you can find it titled
sig in the output of this command:
When a person generates a signature for data, they are allowing users the ability to verify the signature on that data in the future to ensure the data has not been corrupted. This is most common with software applications hosted on the internet - developers provide signatures so that users can verify a website was not hijacked and download links replace with dangerous software.
In order to verify signed data, a user needs to have:
- The signed data
- A signature file
- The public GPG key of the signer
Once the signer's public key is imported on the user's system and they have the data and signature, they can verify the data with the following commands:
# If the signature is attached to the data # If the signature is detached as a separate file from the data
Finding Public Keys
In order to use GPG with others, a user needs to know the other user(s) keys. This is easy to do if the user knows the other user(s) in person, but may be hard if the relationship is strictly digital. Luckily, there are a few options. The first option is to look on a user's web page or social pages, if they have them.
For example, I have my GPG key hosted on my web page at
Otherwise, the best option is to use a keyserver, such as: