Using the GNU Privacy Guard, or GnuPG for short, you can encrypt individual files and emails, and digitally sign them. The main command-line tool of GnuPG is gpg, thus called because it started out as a replacement for PGP, which was the first encryption tool available to everyone that had strong cryptography built into it. PGP, which stands for Pretty Good Privacy, was written by Phil Zimmermann in the early 1990s. OpenPGP is the standard that describes the file format of PGP version 5.0 and later. GnuPG and PGP both implement this standard, and hence are able to read each other’s files.
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(n2) 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) <[email protected]>;" Real name:John Doe
Email address:[email protected]
Comment:work
You selected this USER-ID: "John Doe (work) <[email protected]>;" 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) <[email protected]>; 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 --recipientrecip_1
--recipientrecip_2
...file
A shortcut notation for this is:
gpg -e -rrecip_1
-rrecip_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 -rrecip_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 -rrecip_1
-rrecip_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:
The validity of a given key is not an absolute. It is always relative to another key and to that key’s owner’s trust in other people, as expressed by the assigned ownertrust values . If Alice did not trust Carol to certify other keys, she could not ascertain Bob’s key’s validity.
The Web of Trust model works incredibly well in your own socioecological vicinity. However, it is hard or downright impossible to make it work across more than one or two hops (i.e., intermediate keys).
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.