The Low Down on PGP

Many people, when they think of PGP, think e-mail encryption. Sure, PGP can be used to encrypt the body of an e-mail, but the fact that headers go out on the wire unencrypted make it a fairly unattractive solution for secure communications.

Personally, when I think PGP I think about signing e-mails. Using my public key, people receiving signed e-mails from me can be certain that the e-mail was, in fact, written by me. Additionally, I sign files that I create as a way for people (sometimes me) to later verify that the files have not been altered and are not forgeries. You can even sign your Git tags and commits if you are worried about malicious code slipping into your repository (under your name!) without you noticing or want to provide your downstream users with some peace of mind.

It is nice, in certain situations, to use PGP for encryption of individual files where heavyweight solutions, like TrueCrypt, would be overkill. For example, I like to manage my configuration files using GitHub, but I don't want certain information, like e-mail addresses, exposed to the world. PGP provides a great solution to this problem.

Aside from encrypting things to keep them private and signing things to verify their origin and integrity, PGP also can be used as a login authentication mechanism. Afterall, the whole point of PGP is to identify communications with "entities on the Internet" as "people you know in real life" ...beyond a shadow of a doubt. So, it is not uncommon to see PGP authentication keys used out there---usually in the form of an OpenPGP Card.

How it Works

Here I am going to describe how PGP works from a practical standpoint. Future articles will approach the more technical details of how message digests, asymmetric ciphers, and symmetric ciphers all integrate into the PGP cryptosystem. For now, however, we are going to approach PGP with high level workflow in mind.

The fundamental idea behind PGP is based on key pairs. Every so-called "PGP Key" is actually two keys: a private key and a public key. They are well named. You keep the private key solely in your possession and you actively publish and share the public key with the world. This is true for every type of key you might have. For example, do you have an encryption "PGP Key" that you use to encode and decode super secret spy messages? Well, it consists of a private/public key pair. Have a signing "PGP Key" that you use to sign files and stuff to prove they are unmodified and from you? Yup, you guessed it ...that is another key pair.

Encrypting Files

So, let's talk about how to use encryption key pairs first since a good number of people find them the most interesting.

Let's say you have a file named alien_secrets.txt that you feel pretty strongly about keeping secret from everybody except your partner Scully. Due to an unfortunate matter of happenstance, you are in Kentucky and Scully is in D.C. but you must share the file with her nonetheless, and you don't have the luxury of time required to reconcile your geographic disparity.

Fortunately, you have what you know to be Scully's public key \(S_{pub}\). So, you encrypt the file \(F_{plaintext}\) using Scully's public key:

The interesting thing about this is that now the encrypted version of the file \(F_{encrypted, S}\) can only be decrypted by Scully using her private key \(S_{priv}\). In other words, even you can't decrypt the file \(F_{encrypred, S}\) despite being the person who encrypted it! The decryption performed by Scully looks like this:

This is an important property of PGP encryption: it is asymmetric. This essentially means that encryption is in one direction with an intended recipient in mind. Once a file has been encrypted, only the intended recipient can decrypt it by using their private key.

Signing Files

Signing is a much simpler process than encrypting. In keeping with our X-Files themed hypotheticals, let's say that you have sent a lunch meeting invitation to your partner Scully. The invitation asks that she meet you at Bridgewater's Pub inside of the Philadelphia train station. This information is not a secret so it does not need to be encrypted. However, Scully would like to be able to verify that it is actually you who sent her the message and that it hasn't been tampered with. Frankly, she would like to know she isn't walking into a setup.

So, being the courteous partner you are, you sign your message \(M\). You do this using just your private key:

You send the signed message \(M_{signed}\) to Scully, who then verifies the message integrity and origin (i.e. you) using just your public key:

In other words, Scully puts the signed message and your public key in, and either True or False pops out. If the message was signed by your private key and has not been altered since signed, True pops out; otherwise False pops out.

The Importance of Trust

The integrity of both the signing and encryption systems is contingent upon trusting that the public key for some user, say Bob, actually belongs to Bob. In other words, the Bob you know and love is the owner of the private key corresponding to the public key you have in your possession that you believe to be Bob's. If you have been tricked, however, and the public key you think is Bob's actually belongs to somebody pretending to be Bob... you have a problem. In such a situation, PGP will give you a false sense of security. Messages will still validate and encryption will still work... only problem is you aren't really communicating with Bob.

This brings us to the importance of the trust we put into each public key we come into contact with. Every PGP keypair has a unique 160-bit fingerprint. For example, the fingerprint of my current PGP key is:

1

7F9F D4E8 141E F12C 190E  A988 FEBE 2144 D587 0ED3

The best way to come to trust a public PGP key is to meet the owner of the key somewhere face-to-face and have them tell you what their PGP fingerprint is. Once you have associated the fingerprint to the person, you can obtain the actual key however you like. The person could give it to you on a USB key, you could download it from a public key server, or they could even give it to you printed out on a sheet of paper. Once you get home, you load the public key into your PGP software of choice. PGP users refer to such a collection of keys on their computer as a keyring. Since you trust this new key you just added to your keyring, you sign it using your private key. By signing somebody else's public key you are indicating that you trust that public key in a way that others can verify. Anybody that trusts your public key should, therefore, also trust somebody else's public key you have signed. This "trust by induction" is the basis of what is known as The Web of Trust. If you come across a public key that has been signed by tons of people that you trust, the chances of that public key belonging to the proposed owner is very high. PGP attempts to solve the problem of "does this public key actually belong to this person?" by encouraging PGP users to sign each other's keys in this fashion. Special online databases called Key Servers keep track of public keys, their owners, and signers vouching for their validity.

In Closing

By now you should have a pretty good high level understanding of what the PGP cryptosystem is all about. We have talked about some typical uses of PGP, how asymmetric encryption works, how signing works, key fingerprints, and the importance of trusting public keys. We also introduced the concept of The Web of Trust and how it aids in solving the trust problem of associating public keys with personal identities.