PGP/GPG Basics

A note on names

In practice most of the email encryption software used today is based on the software package "Gnu Privacy Guard", or "GPG".  This package, however, implements an encryption standard defined under a series of internet RFCs (1991, 2440, and 4880) and named the "OpenPGP Message Format" or "OpenPGP".  OpenPGP itself is based on a software package originally written by Phil Zimmerman named "Pretty Good Privacy" or "PGP".  Throughout this document I am generally referring to any system that implements an OpenPGP based encryption scheme, including PGP and GPG, and I have tried to consistently use the term "OpenPGP". 

 

Cryptography Basics

When you visit this website you can check for the https at the start and if it's there that tells you five things (with some level of assurance we'll get to later):

  1. This content really came from a website named "security.gatech.edu"
  2. No one could see the content of this web page between the server and your browser.
  3. No one has modified the content of this web page between the server and your browser
  4. If you sent data back, no one could see the data before it got to the server.
  5. If you sent data back, no one could modify the data before it got to the server.

You may care about all of these, but it's likely you don't.  On this website, for instance, there's no way for you to send anything back so items 4 and 5 aren't really that useful.  On a storefront you might care about your credit card being sent privately and your shipping address not being modified (4 and 5) but not at all that no one could see your receipt.  

In mail each of these things is handled somewhat separately.  OpenPGP (and, indeed, most of internet encryption) is based on the concept of "public key cryptography".  In particular, it is based on the fact that one can create two related numbers called the "public key" and the "secret key" such that the "public key" is published to everybody and cannot be used to figure out the "secret key" but the two can be used to do interesting things together.

Message Secrecy

The first thing you probably think of when you think of secure email is making it so that only the intended recipient can read the message.  This is "message encryption" and happens by applying a mathematical operation called "encryption" on the message using the public key.  Encryption works such that once the message is encrypted using the public-key, no one (even the person who did it) can get the original message back without the secret key.  

Message Integrity

If Alice and Bob are each encrypting messages to each other with their public keys they have satisfied items number 2 and 4 above, but since anybody could have their public key, Bob has no assurance that the email claiming to come from Alice really came from her.  This is solved by Alice creating something called a "message signature" by processing the message with her secret key.  This signature can be validated by anyone who has Alice's public key, but it can only be produced by Alice's secret key.

This does not, by itself, provide any secrecy.  A message signed by Alice can be read by anyone unless it is also encrypted.  The reverse is also true, a message encrypted to Alice could have been produced by anyone unless it is signed, but only Alice can read it.

Web of Trust

Alice and Bob can now communicate satisfying items 2-5 above by each encrypting with the other's public key and signing with their secret key, but we still haven't really satisfied number 1.  That is, Alice can send something that can only be read by whomever holds the secret key that she believes is Bob's, but how does she know that person is Bob?

OpenPGP was originally built around the concept of a "web of trust", and that concept is fundamental to understanding how identity assurance works in the OpenPGP system.  Unlike https, where your browser trust certain companies to verify that a key belongs to the person it claims to belong to, in OpenPGP you have to manually specify who you trust to verify key ownership.

There are two parts to this: validity and trust.  Validity asserts that a given key really belongs to the owner and email address listed in the key, while trust asserts that you trust the owner of the key when they say another key is valid.  

To illustrate the difference lets say that you know two people, Alice and Bob.  Alice personally handed you a hard copy of her entire key and the fingerprint and you imported that into GPG (her key has very high validity), but Alice actually sent money to a someone claiming to be a Nigerian Prince last year and she signed your key before you met with her (she has very low trustworthiness).  You tried to go over Bob's key fingerprint on the phone with him, but he refused to exchange fingerprints because somebody might be forcing you to disclose an invalid one.  Bob has high trustworthiness, but his key has no validity.  Now suppose you wanted to carry on a secure conversation with Charlie, who knows Alice and Bob, but whom you have never met.  Right now you have no way to grant any validity to Charlie's key, but if you met with Bob and exchanged keys then you could trust him that Charlie's key is valid.

Signing Keys

The normal way to manually mark a key as valid in OpenPGP is to "sign" it by attaching a signature created with your secret key.  Ordinarily you would do this after verifying the fingerprint in some reliable method (such as in person or over the phone) and verifying that the person really is who they claim (such as through checking identification).  This not only notes to your OpenPGP instance that the key really goes with that user, it also can be used by others to note that you have verified the key.  Because of this OpenPGP specifies four levels of trust you can place on others:

  1. ​You make no assertions about this person's trustworthiness.  This indicates you probably don't know them well enough to make a decision.  These keys are not trusted to validate other users
  2. You do not trust this user.  These keys are not trusted to validate other users.
  3. You place "full trust" in this user.  These keys are trusted to validate other users.  By default the signature of one valid key with "full trust" is enough to validate an unknown key.
  4. You place "marginal trust" on this user.  These keys can be used to validate other users, but more of them is required.  By default the signatures of thee valid keys with "marginal trust" is enough to validate an unknown key.

The situation may come up where you have enough assurance of a key to believe it to be valid, but not enough that you want to assert it's valid to others (such as possibly the fingerprints of the members of CyberSecurity's keys on our SSL website).  You can do this by "locally signing" the key, usually with the "lsign" command.  This places a signature on the key, but marks it such that it shouldn't be used by others who trust you to tell them it's valid.

Software

  • For Mac we recommend GPGTools
  • For Linux we recommend gpg (available in most distributions)
  • For Windows we recommend Gpg4win