The simplest way to encrypt a file with GnuPG is to encrypt it with a passphrase.^[*] This method is called symmetric encryption. The actual cryptography underlying this is beyond the scope of this book. Suffice it to say that the passphrase is used as the encryption key to the file. Everyone knowing the passphrase will be able to decrypt and read the file.^[*]

To encrypt the file music.ogg, you simply type gpg --symmetric music.ogg. GnuPG will prompt you for a passphrase, and then again to confirm the passphrase in order to avoid typos. The encrypted file is written to music.ogg.gpg. If you prefer another output file name, use --output outfile, like this:

    gpg --output music.gpg -c music.ogg

Here, we used the -c and -o shortcuts for --symmetric and --output, respectively.

To decrypt the file, simply call gpg file. For instance, to continue the previous example:

    gpg music.ogg.gpg

As with encryption, you can request the output to be written to a file other than the default one by using -o outfile.

Although symmetric encryption works well for short-term and casual use, you will run into problems managing the plethora of passphrases accumulated when you encrypt lots of files. The obvious solution of using the same passphrase over and over again poses much the same problems as using the same lock for all your doors. Among others, losing one key locks you out of everything, and if one key is stolen, everything is open to the thief. This can be described as the problem of “Everyone who knows the passphrase can read the contents.”

Another problem is that of “Everybody who needs to read the contents also needs to know the passphrase.” If you encrypt files not for archiving but for sharing with friends, collegues, or business partners, you run into this problem. You cannot reuse passphrases because it’s insecure, as already mentioned, and because each new file might target another set of recipients. For instance, if you reuse a passphrase that was used to encrypt a message to Alice and Bob to now encrypt another message, this time to Alice and Charlie, then Alice, Bob, and Charlie can all read both messages, even though only Alice was intended to be able to read both messages.

You cannot create a new passphrase for each new message, because your recipients will not know the passphrase. And if you have a secret channel to tell them the new passphrase, why would you need to use encryption in the first place?

The only solution using simple encryption, then, is to negotiate a passphrase with each recipient separately, and encrypt the message to each of the recipients separately. But this, too, becomes prohibitively complex, because there must be a passphrase (or another shared secret) for each pair of people wishing to exchange messages; the problem is said to be of O(n²) complexity.

These problems haunted cryptography until the mid-1970s, when Whitfield Diffie and Martin Hellman invented a new method of key exchange that no longer required a shared secret. They used asymmetrical encryption, where the encryption key is public, but the decryption key is secret. In this scheme, everyone can encrypt a message to, say, Alice, but only Alice can decrypt it with her secret key.

This makes it easy to address the situation described earlier: encrypt the message to each recipient using that recipient’s public keys. Only the intended recipients can read the message. In addition, there is only one key for each person, instead of one per pair of persons; the problem is said to be reduced to O(n) complexity. Glossing over the new problem of ensuring that a public key marked as belonging to Alice actually does belong to her, encrypting a message to another person is as easy as downloading her public key from a keyserver, and then encrypting the message to that key. (We discuss the problem we glossed over here in "The Web of Trust" later in this chapter.)

To be able to send and receive messages using public-key encryption, you have to own a secret and a public key—that is, a key pair. They can be created using the command gpg --gen-key. In this mode, GnuPG will prompt you with a series of questions, at the end of which it has generated a new key pair. The following shows a screen capture of the procedure for GnuPG 1.4.0. GnuPG asks for a passphrase that is used to protect (lock away) your secret key. It is not used to encrypt any messages later on.

    $ gpg --gen-key
    gpg (GnuPG) 1.4.0; Copyright (C) 2004 Free Software Foundation, Inc.
    This program comes with ABSOLUTELY NO WARRANTY.
    This is free software, and you are welcome to redistribute it
    under certain conditions. See the file COPYING for details.

    Please select what kind of key you want:
     (1) DSA and Elgamal (default)
     (2) DSA (sign only)
     (5) RSA (sign only)
    Your selection? 1
    DSA keypair will have 1024 bits.
    ELG-E keys may be between 1024 and 4096 bits long.
    What keysize do you want? (2048) 2048
    Requested keysize is 2048 bits
    Please specify how long the key should be valid.
    0 = key does not expire
   <n> = key expires in n days
   <n>w = key expires in n weeks
   <n>m = key expires in n months
   <n>y = key expires in n years
    Key is valid for? (0) 5y
    Key expires at Tue Mar 2 10:33:35 2010 CET
    Is this correct? (y/N) y

    You need a user ID to identify your key; the software constructs the user ID
    from the Real Name, Comment and Email Address in this form:
      "Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>;"

    Real name: John Doe
    Email address: john@doe.example.net
    Comment: work
    You selected this USER-ID:
      "John Doe (work) <john@doe.example.net>;"

    Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
    You need a Passphrase to protect your secret key.
    Enter passphrase:
    Re-enter passphrase:
    We need to generate a lot of random bytes. It is a good idea to perform
    some other action (type on the keyboard, move the mouse, utilize the
    disks) during the prime generation; this gives the random number
    generator a better chance to gain enough entropy.
    +++++.+++++++++++++++++++++++++++++++++++.++++++++++.++++++++++.++++++++++++
    ++++++++...+++++.++++++++++++++++++++..+++++...++++++++++++++++++++>+++++.++
    +++..+++++
    ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++.++++++++++.++++
    +.+++++..+++++++++++++++.+++++.+++++.++++++++++++++++++++..+++++++++++++++..
    .+++++>++++++++++.....>+++++................................>+++++..........
    .........<+++++...........+++++^^^^
    gpg: key 461BA2AB marked as ultimately trusted
    public and secret key created and signed.

    gpg: please do a --check-trustdb
    pub  1024D/461BA2AB 2005-03-03 [expires: 2010-03-02]
       Key fingerprint = E880 E195 62A8 9EFD ED83 3CD7 0B38 4F5D 461B A2AB
    uid         John Doe (work) <john@doe.example.net>;
    sub  2048g/6D18BF84 2005-03-03 [expires: 2010-03-02]

After creating the key pair, GnuPG stores it in the local key ring, usually in ~/.gnupg. You can check that the key has been properly added using the commands gpg --list-keys, which lists all keys in your public keyring, and gpg --list-secret-keys, which lists all keys in your secret keyring.

To make this key available for others to encrypt messages to you using it, you have to upload it to a keyserver using

    gpg --keyserver wwwkeys.pgp.net --send key-id

where key-id is the ID of the key (461BA2AB in the case of the key created above). The keyserver can be hardcoded into ~/.gnupg/gpg.conf so you do not need to give it on the command line every time you upload or download keys. You do not need to upload a key to more than one server, because the pgp.net servers synchronize new and changed keys among each other.

It is important at this point to take precautions for the case of a lost passphrase: If the key gets compromised, or you simply forget the passphrase, you want other people to know that this key should no longer be used. This is the purpose of a revocation certificate. A revoked key can no longer be used as an encryption target. To create a revocation certificate, however, you need to know the passphrase to unlock your secret key. So in order to have a revocation certificate ready for publishing in the case of emergency, you have to create one while you still remember the passphrase, and then store it somewhere safe.

To create such a revocation certificate, you can use the command gpg --armour --output rev-cert.gpg --gen-revoke key-id. This will create a revocation certificate and save it in rev-cert.gpg. The --armour option tells GnuPG to create a printable version instead of a binary file. This way, you can print the certificate and store it on paper as backup in case of hard disk failures.

To apply the revocation certificate, simply import it by using gpg < rev-cert.gpg, and then upload the changed key using gpg --send key-id, as shown earlier.

As mentioned earlier, when doing public-key encryption, you need to have the recipient’s public keys. For GnuPG, this means they need to be downloaded from a keyserver, and that there should be a trust path (see "The Web of Trust,” later in this chapter) from your key to the recipient’s key.

For now, we can make do with a speciality of GnuPG: encrypting to untrusted keys.

First you need to find the key on the keysever. You can use the GnuPG search interface for this: gpg --search name-or-email. GnuPG will list all matching keys (which can be hundreds) in a list, from which you can choose one to import.

If you already know the key ID of the recipient’s key, then you can download it directly using gpg --recv key-id.

Next, you can encrypt a file using one or more keys. Be aware that GnuPG does not necessarily encrypt using your key, too (this is an option in the config file), so you might not be able to decrypt the message any more. The command to use is:

    gpg --encrypt --recipient recip_1 --recipient recip_2 ... file

A shortcut notation for this is:

    gpg -e -r recip_1 -r recip_2 ... file

Both versions create the encrypted message in a file called file.gpg, unless the --output (-o) option is used to redirect the output to a non-standard file. No matter to how many recipients you encrypt, there will always be only one output file — it will just be generated such that all the recipients are able to decrypt it.

To decrypt a file, simply run GnuPG on it: gpg file.gpg. GnuPG asks for your passphrase and then saves the decrypted file into file (i.e., the name of the input file stripped of the .gpg extension).

If you want to encrypt a lot of files in one go, consider using --multifile, like this:

    gpg --multifile -e -r recip_1 ... file1 file2 ...

Public-key cryptography is valuable not only for encryption, but for authentication. Digital signatures are a way to ascertain that a given file has not been modified since it was signed. Very simply put, the system encrypts a checksum of the data with your secret key. This works because, on the other end, the public key can decrypt data encrypted with the secret key.

So to verify the signature, the recipient calculates the same checksum of the data, and then compares the value with the value stored in the signature. If they match, two things have been proved: first, that the data has not been changed since it was signed, and second, that the message was signed using your secret key. If the data was changed, the checksum would not come out the same. Likewise, if the original checksum was encrypted with some other key than yours, the decryption result when using your public key would be gibberish, and the checksums would also fail to compare.

OpenPGP allows two different types of signatures: clearsigned and detached. In clearsigning, the original message is modified to include the data and the signature of the data in one file. Detached signatures, on the other hand, do not modify the original file, but write the signature to a second file, usually with .gpg or .asc appended. You should use only detached signatures, becuase they work for all types of files, while clearsigning works only with (plain) text files.

To sign a file, you need only your secret key. Use the following command to create a detached signature of a file named music.ogg:

    gpg --sign music.ogg

The signature file will be named music.ogg.gpg. As usual, you can redirect the data to another file by using the --output (-o) option. The shortcut for --sign is -s.

It will not come as a surprise to you to learn that verifying a signature works by just running GnuPG on the signature file: gpg music.ogg.gpg.

Signing and encrypting can be combined into a single operation. Indeed, this is the usual mode of operation:

    gpg -es -r recip_1 -r recip_2 ... file

Note that in this case of combined operation, the signature is encrypted together with the signed data, so that there is no third file containing the signature. It is all nicely packaged into the .gpg file.

Note that as of this writing, signing does not yet work with --multifile. You have to revert to using a shell for loop:

    for i in *.ogg; do gpg --sign $i ; done

We have noted earlier that for public-key cryptography to work, one needs to be certain that the public key obtained from the keyserver is actually authentic and has not been changed or created by an impersonator.

To this end, OpenPGP uses the concept of a Web of Trust, in which keys known to belong to the person described by a user ID can in turn certify that another key is authentic. This is done using signatures on the key material, that is, the public key and the associated user ID.

As an example, consider the scenario where Alice wants to send an encrypted message to Bob, the ex of her friend Carol. She does not know Bob personally, and so she cannot be certain that the public key she finds when searching for Bob on the keyservers indeed belongs to Bob.

However, she knows Carol personally, and they have in the past cross-certified their keys. This means that Carol’s key now contains a signature by Alice stating more or less, “I, Alice, confirm that this key does belong to the owner listed in the user ID—that is, Carol.”

Carol, in turn, knows Bob, of course.^[*] From their time together, they still have their keys cross-signed, although it has been a long while since they were used to send secret love letters.

If Alice trusts Carol to not be careless about certifying other people’s keys, she can use Carol’s key to create a trust path from herself to Bob: her own signature on Carol’s key makes that key valid. She trusts the owner of the key to certify other keys, and has indicated this to GnuPG by specifying a corresponding ownertrust value for Carol’s key. Because Bob’s key carries Carol’s signature of certification, Bob’s key is also valid from Alice’s point of view.

This example illustrates two fundamental points:

In recent years, however, the global Web of Trust has exploded, so the latter point becomes less and less of a problem. Thanks to the analysis tools implemented and run fortnightly by Drew M. Streib and Jason Harris, we now know that the global Web of Trust contains one large strongly connected set, a set of keys with the property that each key from the set has a trust path to any other key from the set. This big set currently encompasses 28,418 keys, and its diameter is on the order of 15 hops. Another 60,000 keys can be reached from any key in this set with up to 30 hops. Usually, around 10,000 keys are reachable with no more than three hops. The mean square distance to the best-connected key from any key in the cluster is currently about 3.6 hops. In contrast to the big set, the next biggest sets have only 147, 117, and 79 keys in turn.

In order to enter the strongly connected set, all you need is to cross-sign your keys with at least one of its members. If you live in North America or Europe, this is usually not much of a problem. Visiting a conference or fair with Debian or KDE developers lets you take part in one of the numerous key signing parties that are often held during these events. In other parts of the world, however, it can be very hard.

The commands to sign other keys and change the ownertrust are all available using gpg --edit key-id. This enters a GnuPG shell where commands such as sign and trust are available to perform key maintainance.

After using GnuPG for a while, you will notice that you need to type in your passphrase quite often. But do not let this fool you into choosing a short passphrase! Instead, consider using the gpg-agent tool.

Much like ssh-agent, gpg-agent can be configured to maintain a cache of recently entered passphrases and reuse them instead of prompting the user. gpg-agent is part of the GnuPG 2, the next-generation GnuPG. You can download GnuPG 2 from ftp://ftp.gnupg.org/gcrypt/alpha/gnupg; its packages are called gnupg-1.9.n. Even though gpg-agent is packaged alongside GnuPG 2, it works just fine with GnuPG Version 1.2.6 or higher. Note that gpg-agent uses the pinentry package to prompt the user for a passphrase. Versions of pinentry are currently available for Qt (KDE), GTK (GNOME), and ncurses (text terminal).

To make GnuPG use the agent, you first have to start it: eval `gpg-agent --daemon`. The eval feeds back the output of the command in the backticks into the current shell; that is important because the gpg-agent command outputs environment variable assignments that are necessary for GnuPG to use the agent; in this case, the environment variable GPG_AGENT_INFO will be set. If you start GnuPG from this shell (or any other shell spawned from it), and pass it the --use-agent option (either on the command line or in ~/.gnupg/gpg.conf), then GnuPG will contact gpg-agent to obtain the passphrase instead of prompting the user directly.

To make gpg-agent cache the passphrase instead of asking each time anew, create ~/.gnupg/gpg-agent.conf with the following contents:

    default-cache-ttl
            3600

This instructs gpg-agent to cache the passphrase for 3,600 seconds — that is, one hour.