In the current digital world, the ability to protect communications, to ensure that what you are reading comes from who sent it and not someone else, to verify that no one is listening to a conversation you’re having with someone else, etc, is crucial. Luckily, we have a reliable, proven technology: GPG. In this post, we are going to look at how GPG was born, how it is made, some of its capabilities, where it is used, and how to use it.
“There are only two hard things in Computer Science: cache invalidation and naming things.”
– Phil Karlton
When one starts looking at GPG, one of the first questions that arise is: is it GPG or PGP? Are they two different things? And if you start looking at it and its history, you find out that there are more similar names in the mix: PGP, GPG, OpenPGP, GnuPG, RFC 4880, GPG4Win,… Are these all different names for the same thing? Are they different? Are some the same and some different?
To figure this out, we need to look back at GPG’s history (with some anecdotes).
This is Phil Zimmerman. He was a pacifist and anti-nuclear activist in the USA. And in 1991 he wrote PGP: Pretty Good Privacy. In order to share it, he uploaded the first version to an ISP called Peacenet, and then a friend uploaded it to a Usenet group. It had the ‘US only’ tag, but in Usenet, this is not enforced (it is just informational) and it ended up being distributed worldwide pretty fast. At that time, cryptography with 40 bits keys was considered munition in the US and was subject to exportation restrictions. PGP used 128-bit keys, so there was a federal investigation to decide whether Zimmermann was illegally exporting munition. To work around this, he decided to publish the source code in a book. Anyone could buy the book and scan its content and compile the code. Book exportation is protected by the first amendment in the USA, and so it was legal.
Zimmermann created the company ‘PGP Incorporated’ to develop and commercialize PGP. This company was later acquired by NAI, which stopped publishing the code in 2001 (in 2010, NAI was acquired by Symantec for $300 million). Back to the nineties, PGP Inc ex-workers created ‘PGP Corporation’ which has continued working on the software. Zimmermann and the rest of the workers wanted a PGP version without payment license. They suggested the creation of a working group to the IETF called OpenPGP whose goal would be to create a standard (RFC 4880) that could be used by everybody. From this standard, GnuPG (GNU Private Guard) was born in the GNU project. PGP, OpenPGP and GNUPG are all compatible in current versions.
So the naming part is a bit clearer now:
- PGP: first version and still going on in ‘PGP Corporation’
- GPG: same as GnuPG
- OpenPGP: an alternative friendly name for RFC 4880
- GnuPG: open implementation of the RFC under the GNU project
- RFC 4880: proposed standard
- GPG4Win: GPG distribution for Windows
So what is GPG?
So, more to the point, what is GPG? According to Wikipedia, we have the following:
- Pretty Good Privacy (PGP) is an encryption program that provides cryptographic privacy and authentication for data communication.
- GNU Privacy Guard (GnuPG or GPG), a free-software replacement for Symantec’s PGP cryptographic software suite, complies with RFC 4880, the IETF standards-track specification of OpenPGP.
Its key characteristics are:
- Ensures confidentiality, authentication and integrity.
- Uses hybrid encryption: a mix of symmetric key and public key cryptography
- Provides digital signatures
- It’s based on a web of trust (vs Hierarchy)
Let’s see these characteristics with a bit more detail.
Confidentiality, authentication, integrity
By using GPG you can make sure that confidentiality, authentication and integrity are kept in your communications.
By confidentiality, we understand that only the person meant to view the ciphered information sees it. With GPG this is ensured with encryption and decryption since only the legitimate recipient of the information can decipher it with their private key. Authentication, on the other hand, ensures that the sender of the message is who she says she is and has not been replaced by an attacker. With GPG this is ensured with digital signatures, as the receiver can check the sender’s signature. Digital signatures also assure integrity, as the sender can sign the message’s hash and so the receiver can verify that it has not been tampered with.
Moving now to more technical terms, we’ll discuss how GPG takes advantage of both symmetric and asymmetric (a.k.a. public key) cryptographies, which is why it’s said to use hybrid encryption.
In symmetric key cryptography, the message is encrypted with a shared secret. The ciphered data is then transferred through non-secure channels and the shared secret is transferred through a secure way. One of the most popular methods to transmit it is Diffie-Hellman.
In asymmetric or public key cryptography the agents generate a key pair, one public and one private. The receiver announces her public key, which the sender uses to cypher the message. Only the receiver will be able to decipher it with her private key, thus ensuring confidentiality.
With hybrid encryption, we use public key cryptography to cypher the shared secret that encrypts our data to send it securely. The problem with symmetric key cryptography is the passing of the shared secret between the two sides. The problem with public key cryptography is the computational cost required to cypher the data. By mixing them in hybrid cryptography we fix both problems by combining them: we secure the shared secret and we reduce the computational cost by encrypting only the key and not the whole data.
Another widely spread usage of GPG is to digitally sign information. When we sign a piece of data with our private key, whoever reads that data can confirm with our public key that it was signed by us. This can, therefore, be used to ensure authentication, but also the integrity of the message. Take, for example, a message Bob writes for Alice. The message doesn’t need to be encrypted, but it’s important that it arrives to Alice without being modified by someone else. Bob can create a hash of the message and add that hash to a file. He can then sign the file and send the message and the hash file to Alice, who will ensure that the hash file was signed by Bob and then match the hash with the one she can calculate herself.
Web of trust
The web of trust is an alternative way of generating confidence in a key. Another widely used way is a hierarchy, most noticeable when we use certificates validated by CAs.
The web of trust is based on key signing, which means that someone (as many people as possible) verifies the association between a username and a key. The more signatures a key has, the more confidence we can have in it being legit. The more signatures from people who have a lot of signatures, the more confidence in that key. This is referred to as reputation.
How does key signing work? Let’s say Alice has generated a key and associated her email address to it. She prints out the key’s fingerprint and goes to Bob, showing him the fingerprint along with the email address, and her ID. Bob confirms that the ID belongs to Alice and takes the fingerprint and the email address. He then downloads the public key by looking for it in the key servers (more on that later) with the fingerprint and signs it with his key. He can then send her signed key back to her email address, so she can add it to her key ring for later use. Since her key now has been signed by Bob, other people will have more confidence in it, as Bob is, by signing it, assuring that the key really belongs to her.
There are meetings dedicated solely to this called signing parties. A key signing party is an occasion when several people get together, armed with their key’s fingerprint and personal ID, and gather other people’s key fingerprints to sign them, after validating with the personal ID that the key really belongs to them. Remember: this is to ensure that a particular key belongs to a particular person. You don’t need to be friends, you just need the fingerprint and an ID.
There are some problems with this approach, as more signatures don’t always mean more confidence. To gather signatures is relatively easy and some people don’t put too much attention in checking the other person’s identity. This way, the confidence in the web is shaken. If we understand this, we will probably pay more attention before signing a key, ensuring it is legitimate, as we are vouching for that person in a way.
To make all this work, we have key servers which store public keys and allow people to search and download them. Most of them belong to a pool called SKS. These servers are synchronized so that if you upload a key to a server it will rapidly become available to all other servers. However, it is known that key servers are quite often temporarily unavailable (due to load, attacks, etc).
Fingerprints and IDs
We’ve talked about fingerprints in the previous section. Let’s look at them a bit more closely.
In public key cryptography, a fingerprint is a shorter version of the public key, written in hexadecimal and in groups for readability. For example: 43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8. The key ID, in turn, is a part of the fingerprint. A short key id is composed of the lower 64 bits of the key (in the previous example 0F6673A8) and the long key id is composed of the last 128 bits (in the previous example 0A3AA9B10F6673A8).
Fingerprints and key IDs are handy to avoid writing (and passing or referencing) the whole key, but they are the product of a hash, which means that they are vulnerable to collisions attacks.
A collision attack would be like this:
- Mallory gets Alice’s key
- Mallory generates a new key with the same key ID as Alice’s and sets her contact information
- Mallory publishes the new key
- Bob, who wants to send Alice an encrypted file, downloads the new key looking at the short ID
- Mallory gets access to Alice’s email (through some other attack)
- Mallory can now read Bob’s encrypted message to Alice
This is a real-life attack, and in fact, it happened to several hundred people back in 2016.
In this case, Linus Torvalds and several other Linux kernel developers had their keys faked. The impact of a full successful attack on the project would have been devastating on many levels. So, as mentioned in the kernel list message, don’t trust anything short of a fingerprint.
A crafty and useful feature in GnuPG is the ability to use subkeys. Subkeys are like normal keys in every way, except for the fact that they are bound to a master key. GnuPG uses a signing-only key as the master key and creates an encryption subkey automatically. The motivation behind subkeys is to use them to make key management easier and safer. The idea is to protect the master key by not using it and keeping it away (off-line) and to create a revoke subkeys as necessary.
In this image, we can see two subkeys (the ones with ‘sub’ at the beginning of the line) coming from a master key (the one with ‘pub’ at the beginning of the line). One subkey can be used for encryption ([E]), created when the master key is created) and another for signing ([S]).