Encryption is the name given to the process of hiding the meaning of a piece of information by scrambling its content in some way to prevent unauthorized access to that information. Legitimate users of the encrypted information know how to unscramble it and recover its original form. Encryption is extremely useful for sending sensitive information across an insecure link (for example, Internet e-mail), and if you have used any secure Web sites (for example, online shops , Internet banking, and so on), you have already been using encryption that has been managed by your Web browser.
Verification is related to encryption. This is the process by which the recipient of some information can verify that the source of the information really is who they claim to be, and that the information has not been tampered with. (The information itself may or may not be encrypted). This is useful, too, where the recipient needs to be able to detect forged information (such as when downloading critical code updates from a Web site).
As is so often the case with security matters, a few words of caution are necessary. Encryption technology can be used for protecting a whole spectrum of information, from Granny s secret apple pie recipe to information that has a serious impact on national security. Different governments have different views on the relative importance of allowing individuals to use encryption to protect information and allowing law enforcement agencies access to the same information in detecting and preventing crime. It is up to you to find out whether your intended use of encryption is permitted, and whether there are any restrictions (for example, key length or key escrow requirements) that you must observe.
We will look at using GNU Privacy Guard (GPG) to provide encryption and verification (or signing ) tools. You can find more comprehensive information about GPG at www.gnupg.org .
You will need to install the gnupg RPM; this is part of the Fedora Core 2 installation, so you should find the RPM on your install media if you need to install it.
GPG is based on public-key cryptography. Central to this technology is the creation of pairs of very large numbers , called keys. One key is kept secret; this is the private key. The other key is distributed to anyone who wants to send you information securely, or wants to verify that the information you are sending them is indeed from you and has not been tampered with. This second key is the public key.
When you want to send sensitive information to someone, you can encrypt it with their public key and send the encrypted version. Only someone who has the corresponding private key to the public key used to encrypt the information will be able to decrypt the encrypted information and recover the original contents. Similarly, if someone wants to send you some sensitive information, he or she can encrypt it with your public key and send it across an insecure channel, knowing that only someone with access to your private key could decrypt the encrypted information.
If the information is not sensitive, but you want to allow other people to verify that the information came from you and has not been tampered with, you can sign the information using your private key. Users of that information can verify the message using your public key and confirm that a) the information has not been tampered with, and b) it must have come from someone with access to your private key.
The very clever mathematics behind public key cryptography ensures that it is virtually impossible to break the encryption or signing schemes, but there are still weak points. There is the security of the private keys; if someone is able to get hold of your private key, then he will be able to decrypt information intended for your eyes only, and he will be able send out information that appears to come from you. The second weak spot is with the handling of public keys. If someone is able to convince you that her public key is really from someone else, then she will be able to read sensitive information that you have encrypted using the bogus public key and expect only the intended recipient to be able to access.
The designers of GPG have implemented safeguards to protect against both of these possibilities; your private key is protected by a passphrase (more than a password), and short signatures can be generated from public keys that can be compared (by telephone, for example) with the signatures the real owner of the key generates. Of course, GPG does not force you to use strong passphrases to protect your private key, nor does it force you to confirm public key signatures, but you need to do both if you are serious about the security of your information.
Use your Fedora Core 2 installation media to install the gnupg RPM.
After the gnupg RPM is installed, you need to generate your private and public key pair. You do this with the following command:
The first time you run this, GPG creates a directory called .gnupg in your home directory, and populates it with a few files, and then prompts you for the information it needs to create the initial key pair. Note that if the gpg program is not run with root privileges, it is unable to pin memory pages containing potentially sensitive information and prevent them from being swapped out to disk (where the sensitive information could remain for some time). GPG detects this potential security problem and warns you about it when it starts. If you want to make this warning go away, turn on the set user ID bit on the gpg program by running the command chmod +s /usr/bin/gpg (as root), but you may feel that this introduces other security problems.
Here s an annotated log of a GPG key generation session:
[user1@kimber user1]$ gpg --gen-key gpg (GnuPG) 1.2.3; Copyright (C) 2003 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.
That s the disclaimer and copyright information. Now you get the warning about insecure memory because gpg is not setuid (so that the user ID it runs under is that of the user who invokes the program, rather than root).
gpg: using insecure memory!
gpg: please see http://www.gnupg.org/faq.html for more information
Next , the .gnupg directory is created and some initial configuration files are created:
gpg: /home/user1/.gnupg: directory created gpg: new configuration file `/home/user1/.gnupg/gpg.conf' created gpg: options in `/home/user1/.gnupg/gpg.conf' are not yet active during this run gpg: keyring `/home/user1/.gnupg/secring.gpg' created gpg: keyring `/home/user1/.gnupg/pubring.gpg' created
Now on to the key generation proper. The first question is about the kind of key you want. Because you ll want to encrypt and sign information, choose option 1 (the other two allow you to sign information, but not encrypt it).
Please select what kind of key you want: (1) DSA and ElGamal (default) (2) DSA (sign only) (5) RSA (sign only)Your selection? 1
Now you re asked for the length of the key. Longer keys are stronger and take more effort to break, but also take more CPU time to use. The default key length of 1,024 bits is fine for most requirements:
DSA keypair will have 1024 bits. About to generate a new ELG-E keypair. minimum keysize is 768 bits default keysize is 1024 bits highest suggested keysize is 2048 bits What keysize do you want? (1024) Requested keysize is 1024 bits
You can set an expiry date for your key if you wish. Short key lifetimes limit the amount of damage someone can do if they manage to steal your private key, but increase the amount of effort required to regenerate and redistribute a new key every time the old one expires . Here, accept the default of not setting an expiry date.
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) Key does not expire at all Is this correct (y/n)? y
When you distribute your public key, others need to be able to identify the key as yours. Here you are asked for identification information that will be encoded with the key. This cannot be changed without regenerating the key, so make sure it is correct:
You need a User-ID to identify your key; the software constructs the user id from Real Name, Comment and Email Address in this form: "Heinrich Heine (Der Dichter) <email@example.com>" Real name: Father Christmas Email address: firstname.lastname@example.org Comment: Santa Claus You selected this USER-ID: "Father Christmas (Santa Claus) <email@example.com>" Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
The key that is generated is not stored on disk, existing in memory only while gpg is running. (This is why gpg warns that the memory is insecure and may be swapped out to disk, which would result in a copy of the private key being on disk). Instead, the private key is encrypted with a passphrase and the encrypted version is stored on disk. That way, even if someone gets access to the disk, he cannot use your private key unless he knows (or can guess) your passphrase. Your choice of passphrase, therefore, has a direct impact on the security of the information you protect with GPG; a weak passphrase (one that is short or uses natural language) increases the chances of your private key being compromised, which defeats all the encryption and signing mechanisms.
You need a Passphrase to protect your secret key. Enter passphrase: Repeat passphrase:
GPG now has all the information it needs to generate the key ”apart from some random data. The busier your system is, the quicker the truly random data can be generated. You may have to help the system along by wiggling the mouse, typing on the keyboard, and generating some disk I/O (for example, by tar ing some files to /dev/null with tar “cf /dev/null /usr ).
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. ++++++++++.+++++++++++++++++++++++++++++++++++.+++++++++++++++++++++++++.++++++++++.+++++++++++++++++++++++++++++++++++..++++++++++.+++++>.+++++.+++++>+++++....+++++ Not enough random bytes available. Please do some other work to give the OS a chance to collect more entropy! (Need 215 more bytes) 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. +++++++++++++++++++++++++++++++++++++++++++++.+++++.+++++++++++++++..++++++++++++++++++++++++++++++..++++++++++..+++++++++++++++++++++++++...>+++++..................................+++++^^^^^
After a few minutes, GPG is finally happy that it has enough entropy (randomness) and your key pair is created. Because you ve just generated the key yourself, GPG marks the key as trusted (meaning you are confident that the key has come from the person it claims to have come from). The fingerprint of your public key is also displayed. Other people may ask you for this if they receive your public key and want to check that it is genuine (as they should) before trusting it.
gpg: /home/user1/.gnupg/trustdb.gpg: trustdb created public and secret key created and signed. key marked as ultimately trusted. pub 1024D/4B366142 2004-03-23 Father Christmas (Santa Claus) <firstname.lastname@example.org> Key fingerprint = 300C 0CED 818F D302 BA11 DA7B 26FE 1D0B 4B36 6142 sub 1024g/8DBED907 2004-03-23
As soon as you ve created your key, it is a good idea to create a revocation certificate that allows you to revoke your public key should you lose your private key, or suspect that it has become compromised. You can publish this revocation certificate in the same way that you publish your private key to let others know that they should no longer use your revoked public key, either because you won t be able to decrypt the encrypted information (you ve lost the key), or the encrypted information won t be secure (your private key is compromised). You will still be able to use your private key to decrypt information encrypted with the public key, but others will not be able to use your revoked public key to encrypt new information destined for you.
The revocation certificate is created with the following command:
gpg --output revoke.asc --gen-revoke santa
This generates an output file called revoke.asc that contains the certificate created by the revocation function ( --gen-revoke ) for the key whose user identifier matches santa . Here s the output from a typical session, starting as before with a warning about insecure memory:
gpg: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information
Now GPG shows you the key it has found that matches the partial identifier you gave it on the command line ( santa ) and asks if you want to create a revocation certificate for this key. Answer y (yes).
sec 1024D/4B366142 2004-03-23 Father Christmas (Santa Claus) <email@example.com> Create a revocation certificate for this key? y
You can specify a reason code for the revocation, and add a plain text explanation if you wish:
Please select the reason for the revocation: 0 = No reason specified 1 = Key has been compromised 2 = Key is superseded 3 = Key is no longer used Q = Cancel (Probably you want to select 1 here) Your decision? 1 Enter an optional description; end it with an empty line: > Rudolph knows my private key passphrase. > Reason for revocation: Key has been compromised Rudolph knows my private key passphrase. Is this okay? y
GPG now needs to get your private key. As previously mentioned, GPG does not store your private key as it is on disk, but, instead, encrypts it using the passphrase you provided when the key was created. To use the key, you need to provide the same passphrase again:
You need a passphrase to unlock the secret key foruser: "Father Christmas (Santa Claus) <firstname.lastname@example.org>" 1024-bit DSA key, ID ABCD0123, created 2004-03-23 Enter passphrase: ASCII armored output forced. Revocation certificate created.
You now have your revocation key. GPG is not quite finished; it provides a few helpful words of advice:
Please move it to a medium which you can hide away; if Mallory gets access to this certificate he can use it to make your key unusable. It is smart to print this certificate and store it away, just in case your media become unreadable. But have some caution: The print system of your machine might store the data and make it available to others!
While you re copying important files to a removable medium (for example, floppy disk or CD-ROM), you should copy your (encrypted) secret key. If you lose this, you will not be able to decrypt any information encrypted with that private key s corresponding public key. You must take great care to ensure the security of this copy of your secret key because it is extremely valuable to anyone who wants to intercept encrypted messages intended for you, or who wishes to masquerade as you by sending messages that have been signed with your private key.
So, you have created a key pair (comprising one secret key that you must keep absolutely secret and a public key). What now? You must give your public key to other people so that they can use it to encrypt information in a way that only you can decode, and you need to get hold of other people s public keys so that you can encrypt information you want to send to them. The place where you keep all these keys is called a keyring . You will have two keyrings: one for public keys (yours and other people s), which is stored in ~/.gnupg/pubring.gpg , and the other for secret keys (yours only ”you should never get other people s secret keys), which is stored in ~/.gnupg/secring.gpg .
You can use several methods to publish your public key:
Put it on a Web site
E-mail it directly to people who you want to communicate securely with
Upload it to a public key server
The first two require that you translate your public key into a format that is compatible with communication methods (cut and paste from a Web browser and e-mail) that cannot reliably transfer binary data. You can use GPG to do this with a command like this:
gpg --armor --output mypublickey.asc --export santa
The --armor option tells GPG that you want an ASCII armored format output, which encodes the output so that it contains only 7-bit ASCII characters , and is therefore much less likely to be corrupted by being sent through various e-mail systems. The other options tell GPG where you want the output saved ( mypublickey.asc ), that you want a public key to be exported ( --export ), and the partial key name ( santa ) that GPG can search your public keyring for.
The file GPG creates will look like this:
-----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.2.3 (GNU/Linux) mQGiBEBjWm0RBACuIwiEu/FWae/Ibe61kt3al6EOv0pASN1MNFPpXsLpEQAYAK8u LiLLkZldPXv9mcFeQhXtTVlLPiHXfogiYDCgRFn0xhS688PkrMtzr3JKDLa8mR+B ... PFreOnho9tDXhACfSnCz6ZaCHmQTVXmnjrDD5e63DM0AningrYxnw1iSqYcQTvwE e7Mbo7Cf =YbQy -----END PGP PUBLIC KEY BLOCK-----
If you make this file available to other people ( putting it on a Web server, e-mailing it, and so on), they will be able to import your public key into their public keyrings and use it to either send you encrypted information, or verify information that you have signed.
The other way of distributing your public key is to upload it to a key server . There is a network of public key servers that people can upload their public keys to and can search for and download other people s public keys from. If you add your key to this network (by sending it to just one of the servers, which will replicate it to the others in due course), anyone will be able to search for your key and download it to their own public keyrings to use in the ways previously described.
You can specify the host name of the keyserver you wish to use, and the protocol required to talk to it, on the GPG command line with the --keyserver option. However, the default GPG configuration file ~/.gnupg/gpg.conf already contains a keyserver entry:
So, if you do not specify a keyserver on the command line, GPG will use this one. The keyserver URL specifies the HTTP Keyserver Protocol, hkp://, rather than the more familiar HTTP protocol http://, and for this to work, you need to be able to make outgoing connections on TCP and UDP port number 11371. Make sure whatever port filtering or firewalling you have in place allows outgoing connections on port 11371 (UDP and TCP) before trying to use GPG to talk to keyservers using the HKP.
To send your public key up to the network of keyservers, you simply run the following command:
gpg --send-key santa
Doing so should result in the following message:
gpg: success sending to `subkeys.pgp.net' (status=200)
You have just seen how you can make your public key available to other people, and they can use exactly the same methods to publish their keys for you to use. If you receive someone s public key in an armored ASCII format (for example, a block of unintelligible text starting -----BEGIN PGP PUBLIC KEY BLOCK----- ), you can import the key into your public keyring with a command like this:
gpg --import somefile.asc
where somefile.asc is the name of the file containing the armored ASCII text. Output will look something like this:
gpg: key 01234567: public key "Owner Name <email@example.com>" imported gpg: Total number processed: 1 gpg: imported: 1
Now use the following command:
You should see the newly imported public key on your public keyring. (You can use the --list-secret-keys command to show the keys that are on your secret keyring.)
If you want to search the keyserver for a public key, use the --search option. For example, to find the public key for John Doe, use the following command:
gpg --search "John Doe"
This will search the keyserver listed in the gpg.conf file for public keys that match the name John Doe. Any keys that are found are displayed, ten at a time, on the screen. You can type n and press enter to display the next group of ten keys, or q to quit. If you find the key you are looking for in the list, you can type its index number (displayed next to the key), and GPG imports the key into your public keyring.
One of the problems with public key cryptography, where public keys are exchanged by parties that wish to communicate securely, is how the parties ensure that the public keys they use really are the public keys of the intended recipient of the encrypted information, and not the public key of an imposter who wants to gain unauthorized access to that information. To be really sure, a user of a public key should check the key fingerprint with the key s owner to confirm that the key is the right one. This is the best method to use within small groups, but for larger groups of users who want to communicate with each other, having every user check the key fingerprint of every other user becomes impractical .
In these situations, you can make use of the principle of trusted keys. If someone has verified the fingerprint of another person s public key and is confident that the key is genuine, they can sign the key with his or her own key, and in doing so, certify that the key is genuine. If you now receive a copy of the key (by downloading from a keyserver), you will be able to see that someone else has signed the key as well as the originator, and if you trust that other person to have verified the key properly, you can decide that the key is genuine without having to verify the fingerprint yourself.
To see what signatures have been attached to a public key, use the --list-sigs command:
gpg --list-sigs santa
The output will contain lines starting with sig that indicate signatures that have been added to the key. (For an explanation of the fields following the sig tag, see the gpg man page.)
If you want to sign someone else s public key to say that you think it is genuine, you must first check the fingerprint with the owner of the key and make absolutely sure that they are who they are claiming to be and that the fingerprints match (use gpg --fingerprint < keyid > to see a key s fingerprint). Once you have done that, and you are satisfied that the key is genuine, you can edit the key to add your signature:
gpg --edit-key Rudolph
Then use the sign command. Here s an example:
gpg --edit-key Rudolph gpg (GnuPG) 1.2.3; Copyright (C) 2003 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. pub 1024D/01234567 created: 1998-12-25 expires: 2004-12-25 trust: -/- (1). Rudolph Reindeer (Red Nose) <Rudolph@northpole.org>
GPG has told you which key(s) it has found that match your search string ( Rudolph ). Now you can issue the sign command:
Command> sign pub 1024D/01234567 created: 1998-12-25 expires: 2004-12-25 trust: -/- Primary key fingerprint: 0000 1111 2222 3333 4444 5555 6666 7777 8888 9999 Rudolph Reindeer (Red Nose) <Rudolph@northpole.org>
Because the public key has an expiry date, GPG asks you if you want your signature to expire at the same time. It is sensible to answer yes to this.
This key is due to expire on 2004-12-25. Do you want your signature to expire at the same time? (Y/n) y
GPG now asks you how carefully you have checked the key you are about to sign. It is important to answer this question truthfully; misleading answers undermine the entire trust model behind Public Key exchange in this way:
How carefully have you verified the key you are about to sign actually belongs to the person named above? If you don't know what to answer, enter "0". (0) I will not answer. (default) (1) I have not checked at all. (2) I have done casual checking. (3) I have done very careful checking. Your selection? (enter '?' for more information): 2 Are you really sure that you want to sign this key with your key: "Father Christmas (Santa Claus) <firstname.lastname@example.org" (ABCD0123) I have checked this key casually.
GPG asks you to confirm that the information you have entered is correct, and that you really do want to sign the public key. If you answer y , you are prompted for the passphrase for your secret key and, if this is correct, the public key you are editing is signed.
Really sign? y You need a passphrase to unlock the secret key for user: "Father Christmas (Santa Claus) <email@example.com" (ABCD0123) 1024-bit DSA key, ID ABCD0123, created 2004-03-25 Enter passphrase:
If you want to confirm that your signature has been added to the key, you can use the check command at GPG s command > prompt:
Command> check uid Rudolph Reindeer (Red Nose) <Rudolph@northpole.org> sig!3 01234567 2002-12-25 [self-signature] sig!2 ABCD0123 2004-03-26 Father Christmas (Santa Claus) <firstname.lastname@example.org>
Everything seems okay, so you can quit from the GPG program, which will ask you whether to save the changes you have made or not before exiting.
Command> quit Save changes? y
You can use the --send-keys command to send this updated key back up to the keyservers so that others can see that you have verified the identity of the key and signed it.
Having all these keys on your public keyrings is of no use unless you can use them to encrypt information in such a way that only the intended recipient can decrypt the information. The --encrypt GPG command is used to encrypt a file (or stdin , if no filename is specified). When encrypting information, you need to specify one or more public keys with the --recipient < keyname > option (repeating once for each different recipient); only the holders of the private keys corresponding to these public keys will be able to decrypt the encrypted data. It is useful also to specify where to put the encrypted data with the --output < filename > option, and note that this will be a binary file (unsuitable for sending via e-mail), unless you also specify the --armor option.
If, for example, you want to e-mail a sensitive document called proposal.doc to email@example.com and firstname.lastname@example.org , and you have the public keys for the recipients in your public keyring, you can use the following command:
gpg --output proposal.gpg --armor --encrypt --recipient email@example.com --recipient firstname.lastname@example.org proposal.doc
This creates an armored ASCII file called proposal.gpg that can be safely e-mailed to the two recipients, safe in the knowledge that it won t get corrupted in transit and cannot be read by anyone other than the intended recipients. As an added bonus, GPG also compresses the data, so the size of the e-mail is reduced. (Compressing the data before encrypting it also makes it harder to use cryptanalysis to decrypt the contents of the encrypted document.)
Your recipients can use the --decrypt GPG command to decrypt the encrypted document you sent them and recover the original form. They would use a command like this:
gpg --output proposal.doc --decrypt proposal.gpg
And they would be prompted for the passphrase associated with their private key, which would have to be supplied correctly before the document is decrypted.
If you are going to be working with e-mail and encrypted documents a lot, you will find it tedious to have to use the GPG command line to encrypt and decrypt documents you send and receive. Fortunately, a number of tools and plug-ins are available that make GPG functions available from within popular e-mail packages. Go to www.gnupg.org/(en)/related_software/frontends.html#mua for descriptions of the various tools and plug-ins, and links to the Web sites where you can obtain them.