Encrypting and Signing using GPG

April 9, 2003 / Kurt Nelson / 0 Comments

Table of Contents

1. Why encrypt?

As more and more communication moves into the digital realm, privacy tends to erode in favor of convenience, even though the expectation of privacy often remains. Just as one does not expect a physical letter to be read by every postal worker through whose hands it passes, an email isn’t expected to be read before it reaches its destination. Unfortunately, this often is not the case. In the United States efforts are continually being made to remove privacy from electronic mail in the name of crime prevention through devices such as Carnivore and laws like the Patriot Act. Even for those with nothing in particular to hide, privacy in conventional email is quickly dwindling. Encryption, even if privacy and security are not entirely necessary, helps privacy to seem normal again.

A form of encryption, known as signatures, can be useful even for times when the information itself is not private by confirming the sender of a message. Signatures are also often used in software distribution to verify the integrity of an archive.

2. A little history

PGP (Pretty Good Privacy) was written by Phil Zimmermann, with the original intent of aiding political activists and human rights organizations in keeping their communications away from the eyes of government organizations. In 1991, before PGP was yet released, Senate Bill 266 was drafted and included a measure that would require all telecommunication companies to provide the government access to any communication in unencrypted form, which would have effectively made software like PGP illegal. In order to subvert this measure before it became law, PGP was rushed out the door, and quickly posted to several USENET groups and BBSs across the country, and from there it became the most widely used encryption tool all over the world.

Since PGP used encryption that the government classified as ‘military strength’, and since it was obviously in use outside of the United States, Phil Zimmermann was charged with violating restrictions on the export of cryptography software. In order to protect the continued availability of PGP, the source was published in book form in 1995 (ISBN 0-262-24039-4). The case was dropped in 1996.

In 1997 the Free Software Foundation, liking things to be more free than the average free thing, released the GNU Privacy Guard (GnuPG), which was intended to be a completely free (GPL) implementation of the OpenPGP standard (RFC 2440) and use no patented algorithms.

3. Overview

GnuPG uses public key cryptography in the encryption of its messages. In public key cryptography, every key is actually a key-pair, the ‘public’ key, which is distributed to the world, and ‘private’ key, which is kept private. Messages are encrypted using the recipient’s public key, and can then only be decrypted using the private key. Since the public key does not need to be kept secure, the need for a secure channel to exchange keys is eliminated, but the need for some means to verify keys remains.

So, let’s say that Jim wants to send an email to his friend John, who lives down the hall, but he wants to encrypt it, so that his roommate, Bill, won’t be able to read it. After typing his email, he encrypts it using John’s public key, and then sends it on its merry way. John, upon receiving this email, decrypts it using his private key, and then reads whatever dumb thing Jim had to say.

In this example, Bill would be unable to read the email without walking down the hall and looking over John’s shoulder, but there is no way to verify that Jim was the one who sent the email. Since everyone should be able to get a copy of John’s public key, Bill could have written an email pretending to be Jim, encrypted it, and sent it to John. A solution to this problem is signatures. After Jim types his email, instead of encrypting it right away, he creates a one-way digest of the email, encrypts this digest with his private key, appends the encrypted block to the end of the email, encrypts the whole thing with John’s public key, and then hands it off to the carrier pigeons. The signature block can by decrypted with Jim’s public key, and then the digests can be compared to ensure that the signature matches the message. Since only Jim has a copy of his private key, only Jim can create this signature, so it ensures the identity of the sender.

In this example, key verification is simple, Jim and John both know each other and can meet in person to exchange keys. But suppose there’s another person at the far end of the hall, Bob, and neither Jim nor Bob wants to walk all the way down the hall to the other. However, they both know John, and have exchanged keys with John. Instead of leaving their computers and moving, they can use John to verify keys. After exchanging keys with both Jim and Bob, John signed them using his key. So now Bob can simply email a copy of his public key with John’s signature to Jim, and Jim can verify the key using the signature and John’s public key. If Bill were to intercept the email and send a fake key to Jim instead, then the signature would be missing.

So now Jim has a copy of Bob’s public key that he knows to be valid, even though he has never met Bob in person. Jim can now add his signature to Bob’s key, effectively telling all people who trust Jim that this is a valid copy of Bob’s public key. If Jim trusts Bob to have the sense to securely verify other keys, than Jim can also use Bob’s key to verify more public keys that Bob claims are valid. Using this method, a web of trust can be built so that a large number of people can exchange keys securely without going through the trouble of actually meeting each other.

4. How to get started

Note that gpg should be installed setuid root. Gpg uses the root capabilities to mlock pages that contain unencrypted private keys, to prevent private keys from being stored unencrypted on your hard drive.

So you’ve installed a copy of GnuPG and you’re ready to get started. First you’ll need a key. In order to be difficult to guess, gpg needs a big pile of random data to use in the key generation. In linux, this data comes from /dev/random, which may empty during key generation. This may be a good time for a kernel compile and a game of pysol.

To generate a keypair, run

gpg --gen-key

gpg will then ask you several questions about what sort of key you want. The default type and keysize are most likely what you want. Larger keys may be more secure, since they should be more difficult to guess, but are more often simply a waste, since after 2048 bits or so, the digest and encryption algorithms become the weaker links.

Once you’ve configured your name and email address to use in the key id, gpg will ask you for a passphrase. A passphrase is sort of like a password, but longer. Your private key will be encrypted using this passphrase, so you want it to be secure, but not so long that typing it would become a nuisance.

So now you have a keypair. An easy way to make it quickly available to the world is through the magic of keyservers. There are a wide variety of keyservers to select from, most of which mirror each other. I use pgp.mit.edu. To upload your key to a keyserver, run

gpg --keyserver pgp.mit.edu --send-keys "your name"

If you prefer to send your key by hand, you can use gpg --armor --export instead to have your key dumped to stdout. The –armor, for ASCII armored output, is important. ‘Armor’ is a bit misleading, since it isn’t really any more secure, it’s just uuencoded. Without it you’ll end up with a big wad of binary data dumped to your terminal.

Keyservers are a convenient way to send and receive and keys, but still no substitute for verification. Keyservers do not authenticate or verify keys, leaving this task up to the users. They do save the trouble of carrying a whole key around in your wallet to trade with people, since now other people have something that they think is your key, and that can be verified using the fingerprint. The fingerprint is a 160bit secure one-way digest of the key, and a bit more manageable than a 1024bit random number.

5. Encrypting and signing your email

Many email clients, such as mutt, include support to encrypt, decode, sign, and verify messages using gpg. Mutt is not configured to use gpg by default, but comes with a gpg.rc example file which contains the needed options.

If properly configured, your email client be able to encrypt and sign emails before sending (‘P’ in mutt) and decrypt and verify incoming email, asking for a a passphrase as needed. Basically the only thing to consider are how long, or if at all, the client should cache a passphrase if it is capable of doing so, and, if a copy of outgoing email is kept, whether it should be saved in encrypted form. With mutt, the fcc_clear option will save the email unencrypted and unsigned. Encrypted emails can be saved, but you will need to add yourself to the recipient list if you ever plan to read it again. This can be done either by adding –encrypt-to name> to the gpg encrypt command, or by placing the same, without dashes, in ~/.gnupg/options. Other long options can also be automatically used in this way.

6. Encrypting and signing other random bits of your hard drive

Encryption can be done using

gpg --encrypt --recipient name file

Multiple recipients can be given. gpg will then spit out file.gpg, or file.asc if you requested ASCII output.

Signatures can be created either as a separate file, or as part of the data itself. Detached signatures are usually more useful, since the original data is available without using gpg, and can be created with

gpg --detach-sign

Inline signatures can be created with --sign (the data and signature is saved to file.gpg or file.asc), and may be combined with --encrypt.

Decrypting and verifying usually requires no options, since gpg can figure out what to do from the file.

7. Key management

Most key management can be done from the interactive key edit menu, accessible through

gpg --edit name

Since it’s important to know how useful a key is in verifying other keys, gpg keeps a trust database that contains information on how much you trust other users to correctly sign keys (the "ownertrust" value), and from this calculates a key’s validity. You should only sign a key yourself if you are absolutely certain of the validity of the owner, so many of the keys that you consider valid for your own security needs may not be signed by you.

gpg uses four degrees of ownertrust, not at all, marginally, fully, and ultimately. Multiple marginally trusted are usually needed to consider a key valid (default is 3, tunable with --marginals-needed), and by default only one completely trusted signature is required (tunable with --completes-needed). Ultimately trusted keys are always considered valid signatures, and usually used only for your own key.

If a key becomes compromised, you need to revoke it, using a revocation certificate. The certificate can be generated using

gpg --gen-revoke name

which creates a certificate signed with the private key. This certificate can then be applied to the public key and redistributed, telling everyone that the key is no longer valid.

You may want to generate this certificate after creating the key and keep it in a safe place, in case you lose your private key or forget your passphrase. Care should be taken in the security of the revocation certificate, since anyone who gets a copy of it can invalidate your public key.

8. Resources