Use GnuPG to Encrypt Files

Both SUSE and Red Hat come with gpg , which is the command name for GnuPG (GNU Privacy Guard). It is a free and complete replacement for PGP, and does not contain any patent or licensing issues. It complies with the OpenPGP standard that can be found in RFC 2440. This is a quite commonly used utility, and it is useful when communicating with others who use gpg or some other PGP-oriented application. Your introduction to the program may well originate with a request from another user to use PGP-style encryption to securely convey data that you both consider sensitive. Or it may be that you are doing work on site at a customer s location and wish to keep proprietary data available for your own use in a manner that preserves necessary confidentiality. Obviously, the applications are numerous .

gpg uses a method of securing files commonly referred to as public key encryption. One of the most common terms associated with this type of usage is PKI, which stands for public key infrastructure. Companies that rely on public key encryption to keep financial, personal, and medical data secure often find themselves in the position of having to use a more coordinated approach with application and key management than the typical one-to-many approach that an individual will use. While a robust public key infrastructure in a company is often quite a good thing, it s a large topic that can only be touched upon here. Public and private PKIs have evolved as a means of doing business with an access management infrastructure to go with the encryption that parties agree to in a normal course of action. They allow buisnesses to quickly and easily set up trusted secure relationships with a minimum of technical negotiation and act as trust brokers as well. Internaly, they allow access management and controls to be policy driven and easily administered. In combination with directory services like LDAP, the management of access can be easily combined with security functionality to seamlessly manage information access and trust. Third-party organizations now have key banks available for public key storage, and the same technology can be used to manage sets of keys as part of an internal security process. Externaly they can allow buisnesses to rapidly share data among different parties on the same projects when a third party trust broker is not called for.

Creating Keys in a Secure Manner

Before you even begin the key generation process, you should be logged on in a secure manner. This means being at a console you know you can trust, connected to your target machine either directly or via a connection that you are as certain as possible is secure. You should be using SSH or some other wholly encrypted connection if you must use a network to connect to the machine remotely. The use of Telnet, rsh , or any other unencrypted connection means is unacceptable during this step. Inevitably, someone somewhere along the line will say Yes, but to this provision about key creation. There are few circumstances that meet the Yes, but criteria. Two machines that you have set up yourself, with a switch in between that you plugged in yourself that connects those two machines with one network cable for each machine and no others, in a locked room that no one has access to but you ”in that circumstance alone, Telnet might be acceptable (until you turned it off). Multiple security breaches have resulted from people disregarding sensible precautions because the computing environment was trusted and the people they worked with were trusted.

One thing is certain: all those trust mechanisms in their myriad forms are only true until they are not. When that time comes, you do not want to be in the position of having relied on another trust method while you were creating a trust method such as encryption. Not taking the necessary steps to secure your connectivity during key creation and while using your passphrases, creates very high risks. It only takes one time to snoop your passphrase, and even a lackadaisical assailant, much less a determined attacker, can keep a sniffer running for months looking for that one mistake on your part without any effort to speak of.

It is important not to leave keying data on a potentially vulnerable file system. If an organization uses file encryption, the storage of the secret key data and any public keys that must be kept confidential should not occur on a system that might be subject to an attack. Instead, storage on some other, possibly removable media should occur.

Creating Keys for Use with GnuPG

The first step in using gpg is to generate keys to be able to send others encrypted data. There are minimum sizes on the keys that we will use in this example, and you can decide if these are appropriate key sizes for your circumstances. You should make sure that your GnuPG version is up to date ”new versions come out regularly in response to bug fixes and feature improvements. Before getting to a point where you can proceed, you ll need to run gpg either by itself or with any flag, such as the --gen-key flag that we are going to work with next . This will cause the .gnupg directory to be created in your home directory if it doesn t exist. Some versions of RedHat do this creation step inline, and do not require a separate initialization step.

Inside the .gnupg directory, the only file that exists currently is the options or gpg.conf file, which contains a set of default options that you can tweak if you wish. It is a standard # -commented file, so while some of the options may be arcane, the format is a familiar standard that makes it a bit easier to follow. After the above step, some new files will be created by what you do next in actually making the keys.

Now that everything is set up, the creation of new keys is pretty straightforward. To do so, invoke gpg with the --gen-key command. This will bring up an interactive menu that will prompt you for required information. What follows is an example of the interactive menu with brief explanations of what is occurring throughout:

 # gpg --gen-key gpg (GnuPG) 1.0.7; Copyright (C) 2002 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. gpg: Warning: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information gpg: keyring '/home/budcobackup/.gnupg/secring.gpg' created gpg: keyring '/home/budcobackup/.gnupg/pubring.gpg' created Please select what kind of key you want:    (1) DSA and ElGamal (default)    (2) DSA (sign only)    (4) ElGamal (sign and encrypt)    (5) RSA (sign only) Your selection? 

As you can see, there are four choices, with 1 being the default. At this point, you want to pick the default so that you can perform whatever encryption operations you need to. Picking option 1 will allow you to create encrypted and, if you wish, signed messages that are compatible with the OpenPGP standard.

Upon selecting option 1, a new set of choices will come up. At this point you will be selecting a key size . The menu looks like this:

 Your selection? 1 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) 

In this example, we ve selected option 1, which brought up the next menu. Notice the default in this case is 1024. The minimum is listed as 768 bits. You need to pick numbers that are multiples of 8 since the size is in bits. Numbers like 1024, 2048, 4096, or 8192 fit within these parameters. We are not advocating any of these numbers ; they are there to merely illustrate the program s sizing requirements. Larger key sizes can increase security by lengthening the time it takes to potentially break encryption, but the downside to large keys is that they increase the amount of time it takes to encrypt and decrypt a file. Depending on your hardware, something that might be easy for you to encrypt could take a lot more time to decrypt on a recipient s machine if their hardware is less powerful than yours. The other major factor that comes into play when you are choosing a key size is the size of the files you intend to encrypt or decrypt. With small files such as those created for e-mail purposes, often this means encrypting a page or two of text, which doesn t take much time. A typical file containing a full two pages of text may only be 4 or 5K in size, but just about every other type of file you might work with will be a great deal larger. For moderate- sized text-based files, such as spreadsheets, you still will probably be dealing with a relatively small file size, and your key size selection will not have much of an impact. However, if you are planning to use gpg to encrypt files that are too big to fit on a floppy disk, you should know that the amount of time it will take to encrypt a file can increase dramatically as you increase your key size.

A good rule of thumb is that if the file is not something you would consider too big for sending in e-mail, then you probably will not mind the time it takes to process it. However, if you are planning on encrypting larger files, things that fill substantial amounts of space on a CD or larger, it is a good idea to run some timing tests to see if the amount of time needed to encrypt or decrypt your intended file is acceptable. Since key exchange is the usual next step after creating keys, you want to avoid a situation where you discover after you ve exchanged keys and are all ready to go that you have created an issue with the time it takes to process your files.

In our example, we re going to pick the smallest size possible. The number that s right for you will vary on your application, the size of the files you plan on encrypting, and importantly, who you are communicating with and where they are located.

After picking a key size, you will be prompted to potentially have your key expire after a date you set. If you have a need to expire your key at some point, it would be advisable to spend more time with the GnuPG documentation to examine the ramifications of doing so. For our example, we will create a key that does not expire:

 What keysize do you want? (1024) 768 Requested keysize is 768 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) 0 Key does not expire at all Is this correct (y/n)? 

Notice that the default is zero, and that the key will not expire. No matter what you type, the program will prompt you for an answer. We will answer y for yes. Next you will be prompted to enter your real name, e-mail address, and a comment to go with the key. An example is given as part of the menu as well in case you aren t sure about the format you want:

 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) <[e-mail]>" Real name: Budco R&D Enterprise Backups Email address: [e-mail] Comment: Budco R&D group enterprise backup key for 2004 - 2005 You selected this USER-ID:     "Budco R&D Enterprise Backups (Budco R&D group enterprise backup key for 2004 - 2005) <[e-mail]>" Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? 

As you can see, any of the fields can be edited to change them. You can also just bail out of the whole process if you are not happy with what you ve picked thus far. Since GnuPG is often used in conjunction with the electronic identities of others, many people find it convenient to use the comment field for organization and affiliation information.

Next, you will be prompted to create a passphrase. You do not want to pick something that you will easily forget. This phrase is part of what forms your secret key, and you will not be giving this key phrase out to anyone else, unless you intend for others in your office to be able to use the keys you create to decrypt files collectively. Notice there is a difference in what is being asked for from the typical create a new password type of prompt that you may be familiar with from creating a Linux user account password. The program is asking for a passphrase, not a password. The difference is in the length of the string. Passphrases are much like passwords, in that they need to be unique, need to be something that you can easily remember, and need to be something that is secure. The security requirements are not quite as stringent as those associated with creating a password, however, due to the length. You may (but are not required to) use character substitution (such as using zero for the letter o, or a 1 for an I), or use special characters like ;%&* in your passphrase. It is good practice to do some of these things in the creation of a passphrase, but far more important is creating a phrase of adequate length, and one that you can remember.

Don t use common phrases like the quick brown fox jumped. Combinations of personal data, like the model and year of your car, along with a random street you pass every day on the way to work, followed by the color of your pet s fur or feathers, and a portion of the title of your favorite book, all strung together with some randomized characters, would form a good passphrase. You can also use spaces between the words if you want. For some people, typing a sentence without using any spaces is much more difficult than doing it with spaces, and it may be easier to remember. An adequate passphrase might look like 99Bu1ckLightAtSm1thStreetBlu3DogL1ghtOfAsia. Being able to remember it is more important than length, as you will need to regurgitate it upon demand whenever someone sends you an encrypted file.

If it is a key you are planning on using with a group of people at work, it may end up being something that you have to refer to from a sheet of paper or from some other removable media. If you are planning on using a key under those circumstances, you should not store the unencrypted passphrases in a file on the same machines that you are using to encrypt the files, or especially , transmitting them from. To do so is to invite disaster in the event of a security breach. Even if you ve been diligent about cleaning up the unencrypted versions of your files prior to transmission, anyone who gets hold of your keyring files and your passphrases can decrypt all of your encrypted files. It s particularly advisable to take basic steps to prevent this sort of disaster from occurring by separating the storage means for your passphrases. Having an air gap, where there is no conceivable route over a network to the storage of a passphrase repository, is not just best practice, it s just plain common sense.

The prompt to create a passphrase looks like this:

 Enter passphrase: 

This text will be replaced with a prompt to

 Repeat passphrase: 

If you make a mistake it will warn you and prompt you to enter it again. It s a good idea to practice typing your passphrase a few times in an editor or via some other means that will not save it, to ensure you can correctly type it and recall it. Be sure to backspace over what you ve typed to delete it or close without saving the file you were using to practice with.

Once you reenter your passphrase successfully, the program will continue, and you will see output that looks like the following:

 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 265 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. ..++++++++++.++++++++++++++++++++++++++++++++++++++++++++++++++++++++..+++++++++ +.++++++++++++++++++++..+++++++++++++++.+++++++++++++++++++..................... .+++++^^^^^^^^^ gpg: /home/budcobackup/.gnupg/trustdb.gpg: trustdb created public and secret key created and signed. key marked as ultimately trusted. pub  1024D/D6FFA7FD 2004-06-04 Budco R&D Enterprise Backups (Budco R&D group  enterprise backup key for 2004 - 2005) <[e-mail]>      Key fingerprint = 1106 874F 4ADF FC00 8B64  0463 D17D DD8E D6FF A7FD sub   768g/50608F06 2004-06-04 

Notice in the above example that the program prompted us to be active on the system in some manner, and when enough activity was not taking place, it stopped and asked us to create enough random activity on the system for the process to continue. In this case we logged in another shell and ran the sync command to create a mix of CPU and disk activity sufficient to satisfy the program. More random bytes are better than less, so loading the system down a little bit during the process before this step begins is a good idea.

In short, the steps to take to create a key pair are

1. Enter the following on the command line:

    gpg -key-gen 

2. Enter a key type selection; here we picked 1 .

3. Enter in a key size of your choice, being careful to use a bit-friendly number.

4. Enter an expiration date; here we picked .

5. Enter in your user ID information.

6. Enter a passphrase.

7. Make sure there is some good random activity going on.

That s all there is to the actual typing mechanics in key pair creation. Once you have completed these steps, two sets of keys will have been created. The first is your secret key, which you never reveal to anyone else. It is secured by the passphrase that only you know. The second key is the one you will give out to others so they can create encrypted files that you can then decrypt using your secret key. This is known as your public key. In the previous example, the public key is listed as pub 1024D/D6FFA7FD 2004-06-04 Budco R&D Enterprise Backups. The parts of that key that other users will use to specify your identity are D6FFA7FD and the name portion, Budco R&D Enterprise Backups. It is usually easiest to use the numeric portion to specify which key you want to use to encrypt files for a recipient. Once you start using GnuPG you can rapidly accumulate many keys for many different people, and commonly even more than one key for the same person. In a following section, you will see how to use these keys to prepare files for transmission.

Before you encrypt a file with someone else s public key, or have another person encrypt a file for your use with your public key, you have to be able to extract your public key to send to them, and be able to load in your keyring key files that they send you.

To extract a public key to send to other people, use the following command sequence:

 # gpg --armor --export D6FFA7FD > budcobackups.key 

This gives you a public key in a file that you have named budcobackups.key. The > shell command writes the key to a file rather than standard out, so without the > shell operator, the key would have just been written to the screen. Writing it to the screen is often ideal for a simple copy and paste operation into mail. The --armor switch tells gpg to output your command in ASCII format so that it will be compatible with e-mail transfer, and using this switch ensures there will not be strange conversion errors along the way when the mail is sent. It s suitable for just pasting into a mail program, so most mail clients will work, and you do not need the ability to send attachments to send the keys.

Output from the command should look something like this shortened example:

 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.0.7 (GNU/Linux) mQGiBECsQUwRBACVb2PQq/JdhoUadEgImxqicxhwpXhG3IUcxEH6E7zhZj7wgqdy Eot3Fykdu3XGNohGBBgRAgAGBQJArEFOAAoJEHRFmISdWXYRKA4An1BKO3hncdPU j1eSwLFVOs8f7kdEAKCBVfqTgJHlDdutsNvWCgQ/NB+thg== =kZyF -----END PGP PUBLIC KEY BLOCK----- 

When you create a key for your own use, it is very likely that the key will be bigger, even if you chose the default, which is not much larger than the minimum permitted size that was used in the example.

The next thing to know is how to load up a key that you have been given by someone else. Once you have another person s key, you can encrypt files with it for their use. These are the keyring files that are used to encrypt or decrypt your files, and they are the key data that you need to be concerned about when creating secure backups. Only someone with their key files and passphrase can decrypt files meant for them. Possibly you have been given a public key block file with many keys in it. This is a file that contains multiple keys, and they could be individual or group-oriented keys. To give you a more ground-up view of these key files, here is an example of files that have appeared in the .gnupg directory since it was first created earlier. Earlier in the chapter we showed where the options file had been created inside the directory. Now there are more files. The list includes

 -rw-r--r--    1 budcobackup      users        8129 2004-05-22 16:29 options -rw-r--r--    1 budcobackup      users         858 2004-05-22 16:29 pubring.gpg -rw-r--r--    1 budcobackup      users           0 2004-05-22 16:29 pubring.gpg~ -rw-------    1 budcobackup      users         600 2004-05-22 16:29 random_seed -rw-------    1 budcobackup      users        1265 2004-05-22 16:29 secring.gpg -rw-r--r--    1 budcobackup      users        1240 2004-05-22 16:29 trustdb.gpg 

The pubring.gpg file is comparatively small at this point because it s only got one key in it. When we add new keys, it will grow. The first thing to do with keys that someone has given you is create a place to store them. It is not a good idea to leave key files randomly lying around, not only because of preservation reasons, but because keeping them organized helps facilitate their removal. In this case, we are going to use a directory named Keys, though you may wish to use something more discreet. Inside that directory we have a couple of keys from colleagues:

 -rw-r--r--    1 budcobackup      users        1690 2004-05-22 16:38 bob.key -rw-r--r--    1 budcobackup      users        1694 2004-05-22 16:47 john.key 

To add them, we just run the command

 # gpg --import john.key 

which produces command output that looks like this:

 gpg: Warning: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information gpg: key E4F39AD7: public key imported gpg: Total number processed: 1 gpg:               imported: 1 

Following that, the file john.key was loaded with a similar command:

 gpg --import john.key 

There is now a larger keyring to work with than just the main backups key. We will be able to see these keys if everything has worked right, and thereafter use them to encrypt files meant for John or Bob.

To first see their keys, run the GnuPG command -kv (for key view). Running it on our newly grown keyring results in this output:

 # gpg -kv gpg: Warning: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information /home/budcobackup/.gnupg/pubring.gpg ---------------------------- pub  1024D/D6FFA7FD 2004-06-04 Budco R&D Enterprise Backups (Budco R&D group enterprise backup key for 2004 - 2005) <[e-mail]> sub   768g/50608F06 2004-06-04 pub  1024D/E4F39AD7 2004-05-22 John Conner (John at Work) <[e-mail]> sub  2048g/6DF7E821 2004-05-22 pub  1024D/7DA701A0 2004-05-20 Bob Dobbs (Bob at Work) <[e-mail]> sub  2048g/EFB1A2C9 2004-05-20 

Notice that both Bob and John have keys associated with their common names . John s key is E4F39AD7, and Bob s key is 7DA701A0. Now that we have keys for them added to our keyring, we can see how the files have changed from the earlier output. Inside the .gnupg directory we can see

 -rw-r--r--    1 budcobackup      users        8129 2004-05-22 16:29 options -rw-r--r--    1 budcobackup      users        3204 2004-05-22 16:50 pubring.gpg -rw-r--r--    1 budcobackup      users        2033 2004-05-22 16:50 pubring.gpg~ -rw-------    1 budcobackup      users         600 2004-05-22 16:29 random_seed -rw-------    1 budcobackup      users        1265 2004-05-22 16:29 secring.gpg -rw-r--r--    1 budcobackup      users        1240 2004-05-22 16:29 trustdb.gpg 

The pubring file has grown in size at this point, and even the backup file that was automatically created is larger. That is because we added in Bob s and John s keys as separate files. The key data is contained in these files. The creation of a directory to store them in while processing does not mean they have to be kept at all, as they are stored in the pubring.pgp file and referenced from there as well.

We can now encrypt a file for archival purposes using the backups key we have created or use an individual or group key. During the key creation process, one of the commands was --armor , and this command comes into play when encrypting files. Because mail servers and clients can be somewhat incompatible when handling included files, the --armor switch is used quite often in those applications. It should not be used for files destined for archival storage, or during any backup process that involved the files being transferred via the Web, scp , or FTP, and should not be used in order to save disk or tape space. Any transfer mechanism you use that will do a binary transfer of the files you want to send will eliminate the need to --armor your files in ASCII mode. You will find that compression of the binary files will not gain you much, because one of the main goals of ciphering text is to have it be as random seeming as possible, and that makes for bad compression.

To encrypt files with gpg for inclusion in mail with John s key, use these commands:

 # gpg -ea -r E4F39AD7 test.zip gpg: Warning: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information gpg: checking the trustdb gpg: checking at depth 0 signed=0 ot(-/q/n/m/f/u)=0/0/0/0/0/1 gpg: 6DF7E821: There is no indication that this key really belongs to the owner 2048g/6DF7E821 2004-05-22 "John Conner (John at Work) <[e-mail]>"              Fingerprint: 529F ACEA 2B05 6770 AA30  6BE1 B7DF 66EF 6DF7 E821 It is NOT certain that the key belongs to its owner. If you *really* know what you are doing, you may answer the next question with yes Use this key anyway? yes 

In the above example, we specified John s key with the -r (recipient) flag. For each

-r flag, one recipient can be specified, and you can encrypt one file for multiple recipients with subsequent -r flags. The argument to the -r flag is a person s key, and if you have more than one key for a person, often the best way to identify the key you want to use is to use the number. Arguments like the person s full name, Budco R&D Enterprise Backups or John Conner in the above examples, can be used as well, and you may find this smoother to work with. The -e switch stands for encrypt, and the addition of the -a switch for -ea armors the output for mail. Since the trust attributes have not been updated, gpg prompts to ask if you wish to use the key despite this, and as long as you know you are using the right key, you can answer yes . Further examination of GnuPG commands will instruct you in updating the trust of keys in your keyring, at which point the program will no longer ask for this information.

GnuPG outputs a file with an extension of .asc. The above example resulted in two files in the directory, the first being the initial cleartext file, the second being the encrypted and armored file:

 -rw-r--r--    1 budcobackup      users       72K 2004-05-22 17:18 test.zip -rw-r--r--    1 budcobackup      users      99K 2004-05-22 17:33 test.zip.asc 

As you can see, the armored file is larger. If we do not use the -a switch, and run a command like the following,

 # gpg -e -r E4F39AD7 test.zip 

the output yields a file with a different extension, in this case .gpg, that does not have ASCII character encoding and is subsequently smaller. A new directory listing looks like this:

 -rw-r--r--    1 budcobackup      users         72K 2004-05-22 17:18 test.zip -rw-r--r--    1 budcobackup      users         99K 2004-05-22 17:33 test.zip.asc -rw-r--r--    1 budcobackup      users         73K 2004-05-22 17:37 test.zip.gpg 

Notice the .gpg non-ASCII file is not a great deal larger in size than the original zip file is before encryption. On small files this doesn t make much difference, but on larger files, substantial disk or tape space can be taken up by files unnecessarily put in an ASCII format. It also increases the length of transfer time.

In the previous example, the original unencrypted file test.zip has been used as a source, but has not been removed. The next step should be to remove this source file in a secure manner, using shred if necessary.

The beginning of the output from the ASCII encoded command looks something like this:

 -----BEGIN PGP MESSAGE----- Version: GnuPG v1.0.7 (GNU/Linux) hQIOA7ffZu9t9+ghEAgAtVZXRYu/CfXFRsRzwKaGjqRgSeRdJho9GerrNe3Vjv51 TtEeH1CKgDdp+r9S99BqSOEoJ6HHoLXWR1aBxPAcxy49wm5eJO8uYT7+kAlP09u4 

That pattern of a big formatted list of ASCII only characters comprises the type of content found in the file until its end. Without armor, the .gpg file that is created is a data file filled with seemingly random binary content.

Either the .gpg file or the .asc file can now be sent to John for his decryption using whatever means you want.

If a file is needed for decryption later, the private key part of the public key pair used in the file s creation must be used to decrypt it. Other steps in encrypting a file for decryption look much the same as shown previously.

To decrypt files, we ll use a very simple process:

 -rw-r--r--    1 budcobackup      users        769K 2004-05-22 19:44 budcoplan.zip.gpg 

The command to use is

 # gpg -o budcoplan.zip -d budcoplan.zip.gpg 

In that statement, -o is short for the -output switch, and the -d switch is the abbreviation for the -decrypt switch. We could also do something like this:

 # gpg  -d budcoplan.zip.gpg >budcoplan.zip 

or use any other shell operators. When executed to decrypt something, gpg prompts for your passphrase, and it looks something like this:

 # gpg -d budcoplan.zip.gpg > budcoplan.zip gpg: Warning: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information You need a passphrase to unlock the secret key for user: " Budco R&D Enterprise Backups (Budco R&D group enterprise backup key for 2004 - 2005) <[e-mail]>" 768-bit ELG-E key, ID 50608F06, created 2004-05-23 (main key ID D6FFA7FD) Enter passphrase: 

Upon being prompted for your passphrase, or the passphrase used to encrypt the files, you should enter it. Once you do, the files will be decrypted, and you can process them further with archival software or the appropriate applications.

GnuPG has many different options. The -help command and online documentation are extremely useful in dealing with a variety of circumstances from mail to automated batch processing. For further help, consult the man page or the online documentation at the URL found in the various examples above.