Section 12.4 Using GPG to Encrypt Files the Easy Way

---

12.4 Using GPG to Encrypt Files the Easy Way

The Gnu Privacy Guard, or GnuPG,^[3] is a wonderful and easy-to-use tool for the implementation of the algorithms in PGP. It has been available since 1999 and is free of IDEA and RSA patents so it may be used without patent restrictions. (Most of these patents have expired now.) Throughout this book, GnuPG is referred to as GPG, for short. It should not be confused with PGP. While they interoperate with each other's files, they are separately developed software with different licensing and allowed usage.

^[3] Werner Koch has led a group of people who have worked very hard to produce this great software and who continue to improve it so that all of us can keep our writings, programs, and data private, not just from unjustified government search but also from crackers and thieves. Werner found time in his busy schedule of programming and free support of users to review this section.

Werner Koch, top developer of GPG, asked me to emphasize that GnuPG is Free Software that may be used for any commercial or noncommercial purpose without charge, under the GNU Public License (GPL). Frequently, in this book and elsewhere, the term Open Source is used to refer to free software, that is, software that is freely available to anyone and which may be used for any commercial or noncommercial purpose for free and which may be distributed for free, as well. It is this author's belief that Microsoft and others are trying to confuse the public by putting the words "Open Source" or "Open" in the license or name of some of their restrictive software. The GPL's only essential limitation is that if you distribute an improved version, then you must make it available to anyone who asks for no more than a nominal cost, and that the improved copy must carry the same license as the original.

A copy should be given to the original developers to fold back into the main source tree. This is hardly a threat to intellectual property, only to overpriced, overly buggy, commercial software unable to compete in a fair market despite huge economies of scale. Because GnuPG was developed outside of the U.S. and Canada, it also is available for export without restriction or bureaucracy (except any restrictions against encryption or import that your country may impose on you).^[4]

^[4] Cryptographic laws around the world are summarized at

http://rechten.kub.nl/koops/cryptolaw/

U.S. export laws concerning Open Source were changed in 2001 from "you cannot export" to "each exporter must notify the government as to what is being exported." For those with multiple distributors or with software being imported to many countries, this becomes complicated.

It is well designed and easy to build and use, a pleasure, in fact.

The German government provided a grant of DM 318,000 (about US$170,000) to help fund GPG development in late 1999, despite pressure from the U.S. government not to do this.

The GNU version also may be used as a filter (i.e., a program reading from standard input and writing to standard output without going through an intermediate disk file). This allows it to be inserted in data streams, including pipes to programs doing networking via TCP or even UDP. For example, it could be added to a POP or FTP client and server. Other solutions to these problems are discussed elsewhere in the book. One example is using GPG as a filter to make encrypted backup tapes to protect their contents from being viewed by the wrong people. This is explained in "Encrypted Backups and Other Filters" on page 443 and in "Protecting the System from User Mistakes" on page 51.

I will address downloading, building, installing, and using GPG. GPG consists of a single command for ease of use. Most Linux distributions now are using it to sign their packages and are, in fact, shipping it with their distributions. I have chosen it to sign my distributions.

12.4.1 Downloading

GPG may be downloaded from^[5]

^[5] Binary and source RPMs for GPG, OpenSSH, and OpenSSL may be downloaded from

ftp://ftp.cryptoarchive.net/pub/cryptoarchive/

www.gnupg.org/

You will end up with the following file (except that the version number, 1.0.7, may vary).

 gnupg-1.0.7.tar.gz 

Issue the following command to generate the MD5 hash to verify that this file was downloaded correctly and that it was not tampered with.

 md5sum gnupg-1.0.7.tar.gz 

Compare the resulting hash with the one published on the Web page. Note that if you uncompress and recompress, the hash may change.

12.4.2 Building It

Extract the tarball's contents and change to the newly created directory with the following commands.

 tar -xzof gnupg-1.0.7.tar.gz cd gnupg-1.0.7 

Configure for your platform thusly.

 ./configure 

Use the su command to become root and issue the following commands to build and install. If you do not run the make as root, you will get warnings about insecure memory when it runs some validation tests.

 make make install chmod 4755 /usr/local/bin/gpg ls -l /usr/local/bin/gpg ls -l /usr/local/share/gnupg/options.skel ls -l /usr/local/man/man1/gpg.1 

You now will have the gpg program in /usr/local/bin. It should be set-UID to root (and writable only by root) so that it can lock its critical data pages in memory (RAM). This is to prevent this memory, containing your unencrypted confidential data, from being paged to disk. It also installs a man page and a "skeleton" specifying default configuration parameters for users.

The README file in the source directory is quite helpful in explaining how to use GPG. The online manual and HOWTOs are available from

www.gnupg.org/docs.html

It is important to read the manual and HOWTOs and to understand how the various aspects of public key encryption operate. Misunderstanding this risks a breach of security.

12.4.3 What It Does

The basic idea is that a public key locks a document and the private key (secret key) unlocks it. To lock means to encrypt, or change, the document so that it cannot be read unless the correct key is used to unlock it. An additional feature is that an original document may be locked with the private key and unlocked with the public key instead. Commonly, this additional feature is used for signing a document.

To encrypt a file so that only Cindy can read it, you would encrypt it with her public key. When she receives it, she would decrypt it with her private key. Since only she has her private key, nobody else can possibly read the message. This solves the problem of privacy, that is, of ensuring that only the recipient can read it. After encrypting, not even the sender can decrypt it.

While encrypting the message with the recipient's public key assures privacy, it does not ensure authenticity. Thus, she will not know who sent the message, risking fake messages as anyone could have encrypted the message with her public key. This problem is solved by the sender signing the message. This is done prior to encryption by generating a digest, or hash, of the message, using MD5 or a similar one-way hashing algorithm. Since it depends on the entire message, any alteration would result in a different 128-bit digest value. To complete the signature process, this digest value is encrypted with the sender's private key. This hash, the sender's ID (so that his public key can be found on the recipient's keyring or keyserver), and the date then are encrypted with the recipient's public key.

The MD5 digest of a message is a 128-bit value that depends on each byte of the message, including each byte's order. It is represented by printable ASCII characters. It is similar to the hash values produced by a compiler or database system and it is similar to a checksum.

The difference is that the MD5 algorithm makes it very difficult for an interloper to create a fake message that has the same 128-bit value. A standard checksum is not immune to this because it is not designed to be. A checksum is designed to detect whether a file got garbled during transmission due to accidental means. By changing a few characters in a comment of a program source file, for example, a source file with a Trojan could have the same checksum as the original file.

There is a slight chance that MD5 can be fooled; some of the newer algorithms, such as SHA1, are preferred now as being virtually immune from such tampering.

To decrypt (or decode) and verify the signed message, the recipient first decrypts the message with her private key. Next, she decodes your signature with your public key. Then, she generates the MD5 digest on the message (excluding the signature part of it). Finally, she compares her digest value with the digest value that you supplied. If the two digest values match then the message is authenticated, that is, she knows that it is authentic because the digest depends on the entire message, and only you could have encrypted the digest with your private key. The two principal reasons for using a signature, rather than encrypting the message with the sender's private key, are (1) higher performance and (2) usefulness where authentication but not privacy is required. This typically is for distribution of public information such as bug fixes and security announcements. All of this decryption and signature verification is done automatically when gpg is given the -d flag.

12.4.4 Generating and Manipulating Your Key

The first time you issue the command, using your regular account,

 gpg --gen-key 

it will generate your $HOME/.gnupg directory and populate it with configuration files. If it gives the complaint

 gpg: Warning: using insecure memory! 

then probably you forget to make gpg set-UID to root. If this is the case then issue the following command, carefully correct the permissions, and repeat.

 rm -r $HOME/.gnupg 

Issue the command a second time to create your public and private keys with the following command. Be sure that nobody can see what you type or sniff the data anywhere from your keyboard to the program. This means that only secure communication channels should be used. Be sure to either be logged on to a local terminal of your computer or be connected remotely via SSH or other secure encrypted method; do not use telnet or rlogin.

 gpg --gen-key 

It will ask some questions. Hit the Enter key in response to Please select what kind of key you want: so that you get both an encryption and a signing (authentication) key. Larger key sizes make for harder-to-crack messages but encrypting and decrypting messages will take longer. Either 1024 or 2048 bits should be fine.

Then, it will generate some random numbers based on "environmental" randomness occurring on the computer. This randomness sometimes is called noise or entropy. If progress does not seem to be occurring during key generation, help it along by pressing randomly on the shift and control keys and moving the mouse around randomly.

You now have a public and a private (or secret) key pair and a human name, e-mail address, and comment associated with the key pair. If anyone verifies the signature on a file or e-mail that you have signed, your key ID, human name, and e-mail address will be shown along with an indication as to whether or not he (or someone in their ring of trust) has signed your key to confirm its validity. Like coat hangers, e-mail addresses seem to multiply when you are not watching; almost everyone has at least two. If the person checking yours sees a different e-mail address than the one that he knows you as, he may not trust the signature. This is a pity as there is no correlation. You could have listed [e-mail] as your e-mail address when creating your key pair.

Still, GPG allows you to associate a number of human names and e-mail addresses with a key. Note that the e-mail address listed is really just another name; it has no real connection to e-mail other than being a convenient form of recognition. Each of these human-email-comment triplets associated with the key is called a UID, for user ID, not to be confused with a Linux UID number in /etc/passwd. To generate more, invoke GPG's interactive key editing mode with

 gpg --edit-key your_email_addr 

Now issue the commands

 adduid save 

GPG will prompt you for a real name, which you should supply. In turn, it will prompt you for an e-mail address and comment. Finally, it will ask you if this is ok and prompt you for your passphrase. But wait. If you now do a

 gpg --fingerprint your_email_addr 

or if someone verifies a file you signed, your new name and e-mail address will show as the primary one and list your original as an additional one. This is because it assumes that the most recently added name and address is your new one and the previous one should be considered depreciated. If this was not your intent, you can specify the original one, or any other one, as the primary key. The documentation is not clear on how to do this. Edit the key interactively again with

 gpg --edit-key your_email_addr 

Now issue the command

 list 

Each human-email-comment triplet will be listed on a separate numbered line. The primary one will have a period (.) after the right parenthesis. To change this, specify the correct line number to the "uid" command, such as

 uid 1 

The respective UID will be your working UID for this session. To make it your primary UID for any subsequent signing until changed, issue the commands

 primary save 

Next, create a revocation key. This will allow you to revoke, or cancel, your key if it falls into the wrong hands or you forget your passphrase. The usual ways that it might fall into the wrong hands is by someone sniffing your passphrase while you were operating over telnet, by looking over your shoulder, by using root access, through weak X security, or by some other security breach.

 gpg --gen-revoke your_email_addr 

or

 gpg --gen-revoke "Your Name" 

This will output an "ASCII armored" version of your revocation certificate. This means that the binary revocation certificate is converted to ASCII. This is similar to a "hex dump." You should print it in a way that it does not get written to disk for maximum protection against a DoS attack. The DoS attack is that if someone gets your revocation certificate, he or she can forward it to keyservers and others and invalidate your certificate. If you can write directly to the printer, then issue the following command

 cat > /dev/lp 

and highlight the program's output, paste it into the cat window, and then enter a control-D. Such a printout must be guarded carefully. This procedure prevents this certificate from getting imported to a keyring, such as yours, accidentally. The message to stderr that gpg prints is:

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 [main] media becomes unreadable. But have some caution: The print system of your machine might store the data and make it available to others!

12.4.5 Exchanging Keys

To send a confidential and authenticated message, you need to sign it using your private key and encrypt it with the recipient's public key. The recipient then decodes it using her private key, then uses your public key to authenticate the message. This requires you to have the recipient's public key and requires him to have yours. These keys must be sent in a trusted manner; that can be complicated, depending on the level of trust you require. A common way is to mail your public key to the recipient and for you both then to compare its fingerprint.

The fingerprint is a fancy name for a hash, sometimes called a checksum. The concept is the same as an MD5 sum. To mail all of our public keys to [e-mail], the following command would be used. This is called exporting a key.

 gpg --export --armor your_email_address \    | Mail -s 'My public key' [e-mail] 

It is important to specify your email address here to supply only your public key rather than the public keys of those you communicate with. Exporting your entire public keyring may reveal too much information about who you communicate with or too much information about them, such as their e-mail addresses or other information they do not wish to become known to everyone.

The recipient then would receive the message and save it in a temporary file, bobkey.pub, for example. She then would issue the following command to import your key.

 gpg --import bobkey.pub 

Now, she needs to confirm that she received your public key intact and that nobody altered it en route. A nice feature of GPG (and PGP as well) is that the beginning of the public key is marked with the line

 -----BEGIN PGP PUBLIC KEY BLOCK----- 

This frees the recipient of the key from having to edit the message to remove mail headers; GPG will skip past them until it finds this line. It is possible for a Man-in-the-middle attack, where someone replaces your key with his. This attack is discussed in detail in "Man-in-the-Middle Attack" on page 257. A common way to do this confirmation is for each of you to issue the command

 gpg --fingerprint your_email_addr 

or

 gpg --fingerprint "Your Name" 

You then would compare this hash through some reliable means, perhaps with a phone call if she can recognize your voice or trusts that the phone number is correct and that an untrustworthy person cannot answer the call. Finally, she must inform GPG that this is your correct public key by issuing the command

 gpg --edit-key your_email_addr 

It will enter an interactive mode. She then would enter the number, shown in parentheses, of your key, 1. She then would issue the command

 sign 

to sign, or accept, the key as your genuine public key. She will need to respond y to the prompt. Now, as of version 1.0.7, GPG will ask her how carefully she checked to see that the key was genuine. Asking this question is not as paranoid as it seems at first. Most vendors sign their software patches with a PGP/GPG key. Crackers have been known to send fake patches containing Trojans as well.

You really want to have confidence before signing a key with which you will be trusting the security of your software and your job, such as a security patch from your Linux vendor or even Microsoft. I certainly have and most of you probably have also received e-mail from crackers showing the sender's address as being from [e-mail] and purporting to be a Windows security patch but which, in fact, contained a Windows virus. GPG builds up a web of trust. If you export your public key chain and a friend or colleague imports it and signs it then trust will follow. This means that if you accidentally indicate a cracker's key as genuine and your friend or colleague receives a signed Trojan, his GPG will show it as trusted and he risks infection.

The acceptable responses to the question of trust are 0 for "I'll get back to you on that," 1 for "I have not checked at all," 2 for "I have done casual checking," and 3 for "I have done very thorough checking." I think that the advice given in the man page is a bit extreme for most use unless you are guarding a really valuable site. If I get a key from an organization's site, usually I will indicate a level 2 of trust. I reserve 3 for, as the manual suggests, when I have seen a person's government photo ID, such as a driver's license or passport, or if I know the person well who has supplied it. This value is not used by the software for calculations; it exists only for manually checking the web of trust. Some people use only 0.

Next, it will ask her if she really wants to save the freshly signed key. Pause a moment and consider if someone could have intercepted and altered the key. Is this really the organization's Web site or is it a cybersquatter? Could the site have been hacked? What about a Man-in-the-middle attack? If you will be loading onto your system any software signed with this key, first confirm the key's validity. This might involve checking printed literature or CD-ROMs that came with the software, phoning customer support, or checking back on the site a week later to make sure that there has been no advisory about a security breach. As I recall, at least one of the Linux vendors has suffered a security breach. Microsoft has, several times, included a Trojan on a CD-ROM that it shipped out; most recently this happened on the Korean version of Visual Studio .Net in the spring of 2002.^[6]

^[6] See ".Net Shipped with Nimda" on page 387 for details on the 2002 Microsoft distribution of Nimda.

Finally, it will ask her for her passphrase to confirm that it really is her and not someone else who sat down at her terminal while she was away at lunch. She will need to enter it, and then issue the command

 save 

to save this updated information and exit. Now do an about-face and follow this procedure in the opposite direction, starting with Cindy, who should now e-mail her public key to you.

You can ask GPG to download someone's public key from a keyserver by doing

 gpg --keyserver wwwkeys.pgp.net --recv-keys key 

The key must be the numeric key, such as E3A1C540; it may not be an e-mail address. Note that this service is offered on TCP port 11371, so be sure that your firewall allows it.

Not all keyservers support this. In particular, pgp.ai.mit.edu does not support it.

12.4.6 Disseminating Your Public Key

In order for two parties to exchange encrypted email, they must have each other's public keys. The way that we did this in the previous example is quite effective and reliable but cumbersome. It is common for someone to put his public key up on his Web site. It also is common to put it in the .plan file so that if someone "fingers" him, they see it. However, we disabled fingerd for security reasons so that crackers will not know when we are on the system and so they cannot try buffer overflow attacks against our daemon. What happens if you put your public key on your Web site and a cracker breaks into your site and replaces your key with a different one he created with his own private key? He would be able to masquerade as you and nobody but your intended recipients could decode your authentic messages.

This small danger is why some people include their fingerprint in all e-mail. This way, anyone can compare the computed fingerprint of the public key with the fingerprint in the e-mail message. Another solution is to put your public key in several places. There are a number of public key servers. The following are popular ones that you can use. Note that the first one is a front end for the second one so that uploading to either of these will upload to both.

wwwkeys.pgp.net/

pgp.ai.mit.edu/

www.keyserver.net/

Keyservers sometimes will garble a key. Werner Koch suggests adding mail headers that specify the key and a reliable way to get it, such as

 X-PGP-KeyID:   621CC013 X-Request-PGP: finger://[e-mail] 

or

 X-PGP-KeyID:   E3A1C540 X-Request-PGP: http://www.realworldlinuxsecurity.com/key.txt 

Sometimes sending a FAX with the public key or fingerprint to your high-security recipients is a good solution. Sometimes sending a disk with the public key via registered mail or courier is appropriate.

You can cause GPG to look up a sender's public key on a keyserver automatically (if it is not already on your keyring). This is done by including

 --keyserver name 

where name would be the name of the keyserver, typically wwwkeys.pgp.net. This would be included when you are decrypting an e-mail from someone whose public key is not already on your keyring.

You can upload your keys to this server with the following command.

 gpg --send-keys your_email_address --keyserver wwwkeys.pgp.net 

12.4.7 Signature Files

Everyone reading this has signed contracts. A signature simply is a mark that is unique to someone, which is hard for someone else to spoof (imitate). Also, it is hard for the sender to repudiate the signature, that is, claim that it was not his signature. This issue is so important to electronic commerce that the U.S. Congress, as early as 2000, debated laws providing for this. GPG offers this capability electronically. This book came with a CD-ROM of software, some of it created by me and some of it created by others as Open Source tools.

There also is a Web site for this book where newer versions of software may be found, including, no doubt, bug fixes. But how do you know that I placed the software you see on the Web site? There is the possibility that a cracker broke into the site and replaced it with evil software that will destroy your system. This is guarded against by my signing each downloadable file. Just as a store might compare your signature on a check to the signature on your driver's license, you can check to see that these files' signatures are correct.

If they are not correct, either I goofed or someone cracked the site. In either case, do not use the file. The signature is based on your trust in the public key that you have. The public key is on the CD-ROM in the file pubkey.txt. Since the CD-ROM was in a sealed pouch glued into the book, you can be reasonably confident that it has not been tampered with.

Still, you can do an additional level of verification. The fingerprint (or hash) of this file is printed in Appendix I. Assuming that the CD-ROM is mounted as /mnt/cdrom, you should issue the following commands to add the author's public key to your keyring.

 gpg --import /mnt/cdrom/pubkey.txt gpg --edit-key [e-mail] 

You then would issue the sign and save commands. Next, you should issue the following command to generate the fingerprint of this public key that you just imported into your keyring (or database) and signed (indicating that you believe it to be genuine):

 gpg --fingerprint [e-mail] 

It should exactly match what is printed in Appendix I.

Suppose that the Web site claims that there is a newer version of the blockip.tables.csh script that is used for Adaptive TCP Wrappers. You simply download blockip.tables.csh and its binary signature file, blockip.tables.csh.sig. Issue the following command to check the signature.

 gpg --verify blockip.tables.csh.sig blockip.tables.csh 

The output will look similar to the following.

 gpg: Signature made Wed Jun 21 23:37:47 2000 EDT using DSA key ID E3A1C540 gpg: Good signature from "Bob Toxen <[e-mail]>" 

You are looking for the words Good signature. This verifies that the signature is valid for Bob Toxen <[e-mail]>. The other details may vary. If you see Bad signature or the name is other than what you expect, then something is wrong and you should not trust the file; let the author know, too.

When all of this is seen for the first time it looks like magic. Let us advance to the science. GPG created the signature by first generating a hash of the file. Recall that a hash is similar to a checksum. Two different files are very unlikely to have the same hash, and it is very hard to coerce one file to have the same hash as another file.

Next, GPG encrypts this hash with the creator's private key and adds the key ID; in this case, GPG uses my private key and ID. The result is what is stored in the signature file whose name is that of the original file with .sig appended. When you asked GPG to verify the signature, it could tell from the data in the file whose public key ([e-mail]) should be used to decrypt it, and then it proceeds with decryption. Next, it generates the hash for the data file, blockip.tables.csh. Finally, it compares the two.

If they match then there is a Good signature. Because my public key (now stored on your keyring) was used to decrypt the hash, it only could have been created with the private key, which only I have and which is guarded very carefully. To create the signature file, all it took was

 gpg -b blockip.tables.csh 

The following commands will check the signatures and authenticity of all of the files on the CD-ROM:

 csh cd /mnt/cdrom foreach i ( `find . -type f ! -name '*.sig' -print` ) echo $i gpg --verify $i.sig $i >>&! $HOME/foo_verify end exit 

12.4.8 Encrypted and Signed Mail

Once keys have been exchanged, you are ready to send encrypted e-mail. We will be sending the file new_server.c to [e-mail]. This is done with the following command.

 cat new_server.c | gpg -sea -r [e-mail] \    | Mail [e-mail] 

The s flag causes GPG to sign the file, the e flag causes the file to be encrypted, and the a flag causes it then to be enclosed in "ASCII armor" so that the message contains only ASCII characters. The -r flag specifies the recipient. This is not the e-mail recipient but, rather, it is a name associated with a public key on the keyring to enable the recipient's public key to be found. While it can be a name unrelated to a recipient's e-mail address, making it the same reduces confusion and does not diminish security. Since the s flag (for signing the file) requires your private key, GPG will prompt you for your passkey so that it may decrypt your private key.

When Cindy receives the e-mail, she might save the file in the file mail.gpg. She then could issue either of the following commands to decode the message; GPG will write the message to standard output by default.

 gpg -d mail.gpg gpg -d < mail.gpg 

The following command will save the message to the file mail.txt.

 gpg -d -o mail.txt mail.gpg 

When she invokes gpg, after it decrypts the message with her private key, it will see your signature and will verify it automatically and indicate this with the words

 gpg: Signature made Wed Jun 21 23:37:47 2000 EDT using DSA key ID E3A1C540 gpg: Good signature from "Bob Toxen <[e-mail]>" 

It is critical to see both Good signature and key ID E3A1C540 to ensure that the file has been signed by the expected sender and not someone else who simply signed the file with his own different key.

12.4.9 Encrypted Backups and Other Filters

One of GPG's innovations is that it may be used as a filter in a pipeline. This eliminates the inconvenience, disk space, and most of the security risk of temporarily storing data on disk. (Some versions of UNIX may occasionally write pipe buffers to disk temporarily, making them available for reading by root, and this disk data could persist after the processes have terminated. Linux will not do this so long as writes do not exceed 4096 bytes.) You just saw how this filter allows a one-step mail encryption command that easily could be a shell alias. The possibilities are unlimited and include protecting custom applications, database data, and communications channels.

An important and novel use is to create encrypted backup tapes (or CD-ROMs or floppies). This eliminates the problem of someone stealing your backup tapes and then having access to all of your confidential data. This can be done with the following invocation. It does not require a passphrase because we are using only the recipient's public key.

 | gpg -e -r [e-mail] 

This makes a fine addition to the rmtbackup1 script discussed in "Protecting the System from User Mistakes" on page 51. It is important to copy the GPG private key of the recipient to a tape, without using GPG to encrypt this tape, in order to recover GPG-encrypted tapes if the disk is destroyed. This clear-text tape containing the key must be stored in a physically secure location. Two different tapes containing the key, stored in separate locations, is a good idea.

12.4.10 Very High GPG Security

Most of this book is concerned with maintaining security on a computer that is networked, usually to the Internet. While good procedures can increase security, they never will produce 100 percent security. For those that want to send and receive encrypted and signed messages with very high confidence levels, it is suggested that the messages be encrypted and decrypted on an isolated (nonnetworked) machine with good physical security (i.e., in a securely locked room). Messages could be transferred to and from this machine via magnetic or optical media and using a standard method, such as tar. A script to invoke tar that only reads or writes specific file names is suggested to avoid Trojans being planted. This will make it very hard for anyone to break into this system. Other techniques for very high security are discussed in "Hardening for Very High Security" on page 306. For those of you who do not need quite this level of security but still worry about your systems being broken into and your passphrases getting cracked by brute force, there is a compromise. Move your secret key to removable media that normally is not in the system. A floppy works well, as does a recordable CD-ROM. The latter can be had in a size that fits in a wallet. Have $HOME/.gnupg/secring.gpg be a symbolic link to the real file on the media.

Then, when you need to sign something, mount the media, sign, unmount it, and remove it from the system. I normally leave my "signing" floppy partially inserted since my office is physically secure and the guards will shoot to kill. To set this up initially, insert a blank floppy in the drive and do the following as root.

 mkdir $HOME/gpgmnt mkfs /dev/fd0 mount /dev/fd0 $HOME/gpgmnt mkdir $HOME/gpgmnt/.gnupg chmod go-rwx $HOME/gpgmnt $HOME/gpgmnt/.gnupg chmod go-rwx $HOME/gpgmnt/lost+found mv $HOME/.gnupg/secring.gpg $HOME/gpgmnt/.gnupg/. chown you $HOME/gpgmnt chown you $HOME/gpgmnt/.gnupg chown you $HOME/gpgmnt/.gnupg/secring.gpg ln -s $HOME/gpgmnt/.gnupg/secring.gpg $HOME/.gnupg/. umount /dev/fd0 Remove the floppy Write-protect the floppy Label the floppy with contents and date 

To use the signing floppy, do the following as root.

 Insert the floppy mount -r /dev/fd0 $HOME/gpgmnt Do the signing from a different window as you umount /dev/fd0 Remove the floppy 

Keep in mind that your secret key no longer will be on your system backups. Therefore, it is critical to make a separate backup and keep it in a very safe place, such as a bank safe deposit box. To back it up, do the following as root.

 Verify that the signing floppy is R/O Insert the signing floppy umask 077 dd if=/dev/fd0 of=bounce Remove the floppy Insert a blank floppy dd if=bounce of=/dev/fd0 Remove the floppy Write-protect the floppy Label the floppy with contents and date overwrite -r bounce 

The overwrite program comes on the companion CD-ROM and was discussed in "Truly Erasing Files" on page 162.

A similar technique may be followed for using a CD-ROM to store the secret key. After creating and mounting the floppy, the following commands will burn a CD-ROM:

 mkisofs -t -R -o bounce.iso $HOME/gpgmnt cdrecord dev=/dev/cd_dev bounce.iso umount /dev/fd0: overwrite -r bounce.iso Remove the floppy Remove the CD-ROM Label the CD-ROM with contents and date 

The CD-ROM now can be used to access one's secret keys with the command:

 mount -r -t iso9660 /dev/cd_dev $HOME/gpgmnt 

---

Top