GnuPG Commands - ExamplesEncryption / Decryption
Encryption (gpg [--options] --encrypt file) You encrypt files by using the --encrypt command and specifying the file or data to be encrypted..
If you don't specify a recipient with your command, GPG prompts you to specify a recipient (whose public key must be on your keyring). Once you specify a recipient, GPG encrypts your file (my-file.txt) to a similarly named file with the extension .GPG (my-file.gpg). You can avoid bring prompted for a recipient by specifying a --recipient as an option.
Notice that the -- recipient option comes before the --encrypt command. In both of the examples we've looked at, GPG encrypts the file (my-file.txt) and produces a similarly named file (my-file.gpg) as output. This new output file is an encrypted (ciphertext) version of the original plaintext file, but is is a binary file. The contents of this encrypted binary file will look like gobbledygook when opened with a simple text editor like Notepad. Binary files are perfectly fine to send intact to a recipient "as is," however, they can present problems if you want to send the encrypted contents (the ciphertext) in the body of an email message. If you want to work with the encrypted contents (ciphertext) of your file in text format, there is a solution. GPG allows you to encrypt your file to a special format known as ASCII Armor. You can send the ASCII Armored contents in the body of an email message. To encrypt your file and produce an ASCII Armored file as the output, use the --armor option. Remember that options precede commands.
When encrypting to ASCII Armor, GPG produces an encrypted file with the extension .ASC (instead of .GPG). .GPG files are binary files; .ASC files are ASCII Armored files. In these examples, both are encrypted with the same strong level of encryption. If you open up an ASCII Armored file, you'll see that most (but not all) of its contents are gobbledygook. This gobbledygook, however, can be used "as is" in an email because it is simple text -- it is not binary data. The strange looking block of characters in the middle contains the encrypted contents (ciphertext) of your original file in ASCII Armor format. You can send that ASCII Armor text block in the body of an email message.
As you've seen, when GPG encrypts files it produces similarly named files with the extension .GPG or .ASC as output. You can specify the name of the output file yourself, however, with the --output option.
In this example GPG encrypts my-file.txt and produces an ASCII Armored file named your-file.asc. When using the --encrypt command, you may receive a warning from GPG about the "trust" in a key's owner:
This message tells you that you have not yet signed the recipient's public key in order to establish a level of trust for that key. Although you ought to consider signing the key in order to set the trust level for the key, you can simply answer "yes" when GPG's confirms that you want to use the key and GPG will encrypt the file or message using that public key. (You can suppress this warning by adding the --always-trust option to your Options file.) For more information on signing keys and establishing trust levels for keys, see the Understanding Signatures & Trust and Signing Keys sections below. (For more information on encrypting messages and files, see the GNU Privacy Handbook.) Symmetric Encryption (gpg [--options] --symmetric file) You can encrypt files using symmtric encryption (as opposed to public key encryption) with the --symmetric command. You will be prompted for a passphrase to protect the key used to encrypt the file.
With symmetric encryption, you encrypt and decrypt files with the same key (which GPG generates and protects with the passphrase you supply). By contrast, the --encrypt command uses asymmetric encryption: you encrypt files with other people's public keys, and they decrypt with their secret (or private) keys. (For more information on symmetric vs. asymmetric encryption, see the GNU Privacy Handbook.) Symmetric encryption is useful if you don't plan to deliver or distribute the files to other people. For example, you may simply want to protect sensitive files on your own hard drive (not distribute them to other people). You can combine the --symmetric command with the --output or --armor options, just like the --encrypt command. (For more information on using symmetric encryption, see the GNU Privacy Handbook.) Decryption (gpg [--options] --decrypt file) To decrypt an encrypted file, use the --decrypt command. The --decrypt command should be used no matter whether you have received that file from someone else (who encrypted with the --encrypt command it using your public key), or whether you encrypted the file yourself with symmetric encryption by using the --symmetric command. If the file was encrypted to your public key with the --encrypt command, GPG asks you for the passphrase for your secret key (often called a private key).
If you encrypted the file yourself with symmetric encryption (--symmetric), GPG asks for the passphrase that you assigned to the file.
If you don't specify an output file for the decrypted (plaintext) contents, GPG merely displays the decrypted contents inline. You can specify an output file for the decrypted contents with the --output option.
Once GPG has decrypted the file to my-file.txt, you can open my-file.txt and view the decrypted (plaintext) contents. (For more information on decrypting messages and files, see the GNU Privacy Handbook.) When you encrypt a file or message with the --encrypt command, you are encrypting with someone else's public key. Strangely enough, even though you encrypted the file or message yourself, you won't be able to decrypt that encrypted file and access the plaintext. The only person who can decrypt the file is the owner of the secret key that is the partner of the public key used to encrypt the file. That's the nature of asymmetric, public key encryption: you encrypt with the public key and decrypt with the secret key (private key). If you don't keep a copy of the plaintext original file yourself (and you probably shouldn't for security reasons), then you face being locked out of the very files and messages that you have encrypted and sent to other people. Happily, there is a solution: the --encrypt-to option. You can include the --encrypt-to option in your Options file and specify your own public key. This option is often called the "encrypt-to-self" option, because it tells GPG to encrypt the message with your own public key as well as your recipient's public key. With an --encrypt-to key designated in the Options file, GPG automatically encrypts messages and files to the public keys of the recipients you specify with the --recipient option as well as your own public key. The result: both you and your recipients will be able to decrypt the files or messages. To use the --encrypt-to option in your Options file, drop the leading dashes ( -- ) and specify your own key's Key ID. (You can get your own Key ID with the --list-keys command.) For example, Bob (whose Key ID is 0x3FAD9F1E) could include the following line in his Options file:
(Note that even though Bob's key includes an encryption subkey with a separate Key ID, he simply uses the Key ID for his master key.) Now Bob can encrypt a file to his friend Phil, just as he normally would...
...and still turn around and decrypt the file himself.
Notice GPG reports that the file (my-file.gpg) was encrypted with both Phil's key and Bob's key. GPG automatically recognizes that Bob has the secret key for one of the public keys used to encrypt the file and uses that secret key to decrypt. It would probably be a good idea to use the "encrypt-to-self" option (--encrypt-to) in your Options file, as it can save you a lot of frustration down the line. Signing / Verifying
Signing (gpg [--options] --sign file) You can sign files with the --sign command. GPG will prompt you for the passphrase for your secret key (private key).
Note: if you have multiple secret keys that you can use to sign, then you'll have to indicate which of those secret keys you want to use to produce a signature. To designate the secret key, you can either use the --local-user option with the --sign command, or you can use the default-key option in your Options file. In the example above, we used the --armor option to produce ASCII Armored output (though we could have dropped the --armor option and produced a binary .GPG file). When we open the encrypted, ASCII Armored file, the ciphertext contents look just like a file that we encrypted.
In fact, we have encrypted the original file, but we encrypted it with our own secret key (as opposed to someone else's public key). In fact, signing is sometimes known as "encrypting to the private key." The recipient will decrypt the with our public key and verify the signature. The problem here, of course, is that we may want to sign the file, but leave the contents in plaintext form so that the contents are still readable. To do this, we'll clearsign the file with the --clearsign command instead of signing it with the --sign command. (For more information on signing messages and files, see the GNU Privacy Handbook.) Clearsigning (gpg [ --options] --clearsign file) To sign a message or file but leave the actual text or contents unencrypted (in plaintext), you can clearsign the file or message with the --clearsign command.
When you open the clearsigned output file, you'll see that GPG has left the original contents in plaintext and appended a signature for the contents at the bottom.
When clearsigning files, it is not necessary to use the --armor option. GPG automatically uses ASCII Armor for the clear signature it appends to the bottom of the encrypted contents (ciphertext). Of course, it only makes sense to clearsign simple text files. If you clearsign binary files, GPG will produce an ASCII Armored signature, but the original contents will still be binary gobbledygook. (For more information on clearsigning messages and files, see the GNU Privacy Handbook.) Detached Signatures (gpg [ --options] --detach-sign file) You can also produce a signature as a detached signature file. When creating detached signatures, GPG leaves the original file "as is" and creates a separate file that contains only the digital signature. To sign a file and produce a detached signature, use the --detach-sign command..
Once you enter your passphrase, GPG creates a detached signature file (my-file.sig) that is named similar to the file being signed (my-file.txt). .SIG files are binary files like .GPG files. If you prefer GPG to produce detached signature files in ASCII Armor format, use the --armor option.
As you might expect, you can open the ASCII Armored detached signature file (which has the .ASC extension) and view the contents.
Once you have produced a detached signature, you should send both the original file that you signed as well as the detached signature file to your recipients. It does your recipients no good to send just the detached signature file; the detached signature file contains only the signature, not the actual contents of the file that you signed. (For more information on creating detached signatures, see the GNU Privacy Handbook.) Verifying Signed & Clearsigned Files (gpg [ --options] --decrypt file) To verify the signatures on files that you have received from others, use the --decrypt command.
GPG shows you the contents of the file and verifies the signature. The --decrypt command should be used with files signed with the --sign command as well as with files clearsigned with the --clearsign command. We can specify an output file with the --output option.
The decrypted file (your-file.txt) contains only the plaintext contents. GPG still reports the results of its signature verification inline. Keep in mind that to verify signature from someone, you must have that person's public key on your keyring. If you don't have that person's public key, you won't be able to verify the signature. (For more information on verifying signatures, see the GNU Privacy Handbook.) Verifying Detached Signatures (gpg [ --options] --verify sigfile signed_files) To verify files with detached signatures, use the --verify command and specify the detached signature file as well as the files that were signed..
GPG doesn't show you the contents of the original file that was signed. The original file remains in plaintext form, so you can view it as you normally would without any special command. We can use the --verify command to verify files signed with the --sign or --clearsign commands...
...but GPG doesn't show us the plaintext contents of the signed files. It only verifies the signature on the file. That's why we use the --decrypt command to verify files that have been signed with the --sign or --clearsign commands: we want to view the contents as well as verify the signature. Keep in mind that to verify signature from someone, you must have that person's public key on your keyring. If you don't have that person's public key, you won't be able to verify the signature. (For more information on verifying detached signatures, see the GNU Privacy Handbook.) Understanding Signatures & Trust In all of the signature verification examples that we looked at above, GPG reported the following when verifying a signature:
This signature verification is what we want and expect: a "good signature." But GPG may not always give you the same unambiguous report when verifying signatures. In some situations, GPG's signature verification report may include something else: a "warning," such as the following:
This warning is similar to one you might receive when encrypting a message or file to someone else with the --encrypt command:
In the case of the signature verification warning, you're probably wondering why GPG reports "Good signature from..." on one line and then issues a "Warning" about the key not being "certified with a trusted signature" on the very next line. It might seem that there's a contradiction here -- i.e., how can a signature be both "good" and "untrusted" at the same time? -- but there really isn't a contradiction at all. Let's look in detail at what GPG is telling us. The first line tells us what key was used to make the signature and when the signature was made.
The next line confirms that the signature on the file was in fact made using this particular key (with Key ID 49B58839). It also tells us that the User ID on that key is for Alice Wong (a-wong@big-corp.com) and that the signature is valid or "good."
What GPG has done is verify that the signature on the file does indeed match the signature it would expect from this key for this file. The fact that the signature matches tells us that the file has not been altered or tampered with in transit. If the file had been altered in transit, GPG would have reported a "bad signature" instead:
In other words, the signature on the file didn't match what GPG expected. Perhaps the contents of the message in the file were altered somehow. Another potential cause for this "bad signature" is that the signature itself was altered or doesn't even belong to the contents of the file (it might be a signature that was produced for some other file). Whatever the cause, it's a "bad signature." The example we're looking at, though, has a "good signature." The problem with this signature is that it was produced with a key that is not "trusted."
As GPG insists, we don't have any reason to suppose that the key used to produce the signature does in fact belong to the person identified in the key's User ID. In other words, while we know that this key was indeed used to make the signature on the file and that the file hasn't been altered, we do NOT know that this key really belongs to Alice. (The same holds true for the warning GPG issues with the --encrypt command: you don't know for certain that the person specified in the User ID of the key to which you're encrypting is actually the owner of the key.) It's always possible that someone other than Alice generated the key, used Alice's name and email address in the User ID, and is now masquerading as Alice. In short, the key is "untrusted." We can make this key "trusted" by "certifying" the key. To certify the key, we need to sign the key. Once we sign and certify the key, the trust level associated with the key will change. In this example, GPG has warned us that we are using an "untrusted key" because we have not yet certified the key that was used to verify the signature. Put another way, GPG is telling us that we have have not "certified" the key used to make the signature by signing that key with our own secret key in order to change the trust level associated with the key. ("This key is not certified with a trusted signature!") Once we sign the key to certify it, the key will become "trusted." The trust level on a key is a measure of our confidence in the identity of the owner of the key. If we are confident that this key does actually belong to Alice (who is listed in the key's User ID), we can change the trust level on Alice's key by signing it with our own secret key. Once we sign Alice's key and change the trust level associated with the key, GPG will no longer warn us that we are using an "untrusted" key when we verify signatures from Alice. Instead, GPG will simply report:
And when encrypting files or messages with the --encrypt command, GPG will no longer warn you about the "untrusted" nature of the key -- it will simply encrypt the file without complaint. To learn how to sign keys and change the trust level on a key, see the Signing Keys section below. You can also suppress GPG's trust warnings by adding the --always-trust option to your Options file. (For more general information on signing keys and using the Web of Trust, see the GNU Privacy Handbook.) Combining Commands
Most commands used by GPG cannot be combined with other commands. Although you can use multiple options at the same time (as we did in many of our examples earlier), commands must be used one at a time. In some situations, though, you can combine commands instead of issuing them separately. Encrypt & Sign (gpg [--options] --encrypt -- sign file) You can encrypt and sign a file at the same time by using the --encrypt and --sign commands simultaneously.
With the combined --encrypt and --sign commands, GPG produces a signed and encrypted file.
The --encrypt command cannot be combined with the --clearsign or --detach-sign commands. Indeed, it wouldn't make sense to do so, because we want to encrypt the original file, not leave it in plaintext form, as both the --clearsign and --detach-sign commands do. Decrypt & Verify (gpg [--options] --decrypt file) To decrypt and verify a file that has been both signed and encrypted, use the --decrypt command. GPG will decrypt the contents and verify the signature automatically..
Of course, you can always specify an output file for the decrypted contents.
The output file will contain only the decrypted (plaintext) contents of the encrypted file. GPG still reports the results of its signature verification inline. Key Management
Key Generation (gpg [--options] --gen-key) Before you can receive encrypted messages and files from others or digitally sign files and messages to send to others, you must generate a keypair for yourself. A keypair consists of a public key -- which others use to encrypt messages to you and to verify signatures that you make -- and a secret key (often called a private key) -- which you use to decrypt messages sent to you by others and to sign files and messages that you send to others. (For more information on encryption, ciphers, and keys, see the GNU Privacy Handbook.) The key generation process in GPG involves several steps and requires you to make a several important decisions along the way. We start the key generation process with the --gen-key command.
The first choice we must make is the type of key to generate. As this is our first keypair, we should generate a keypair that can be used to both sign and encrypt, which means we'll choose option (1) or (4). We'll choose (1) DSA/ElGamal (default). DSA/ElGamal keypairs include a DSA master signing key and an ElGamal encryption subkey. Both the master signing key and the encryption subkey will have public and secret keys. (For a discussion of DSA/ElGamal keypairs, see the Note on Key Types & Subkeys section below.) Next we choose a keysize. Note that we are choosing the size for the ElGamal encryption subkey -- the size of the master DSA signing key is fixed at 1024 bits.
The larger the keysize, the stronger the key and the more robust the encryption used for messages and files. The minimum keysize you ought to consider using is 2048 bits. The largest keysize you can choose is 4096 bits.(An intermediate step between the two would be 3072 bits.) (For more information on key sizes, see the GNU Privacy Handbook.) GPG now asks us to specify an expiration. We can always revoke our key in the future should we decide to, so we'll choose no expiration. (For more information on expiration dates, see the GNU Privacy Handbook.)
Next, we must create a User ID for our keypair. The User ID is a kind of name tag for our keypair. It lets those who get our public key know who that public key belongs to. The User ID, in other words, identifies us as the owner of the keypair. GPG asks us for a name and email address to create the User ID. We can change both at a later time should we need to.
Finally, we must specify a passphrase for our secret key (private key). This passphrase is critical, as GPG uses it to protect and control access to our secret key. If your passphrase is compromised or broken, anyone who gets a hold of your secret key will be able to use it to decrypt messages sent to you and to sign files sent to others just as if they were you. A strong passphrase should consist of a mix of upper and lowercase letters, numbers, and non-standard keyboard characters. Your passphrase should not use familiar names and numbers (e.g., names of friends and family, names of pets, social security numbers, etc.). It should also avoid repeated characters as much as possible. Finally, your passphrase should be long (a standard 8 character password will not suffice) and yet easy to memorize.
GPG asks you to enter your passphrase twice. As you type, GPG will not "echo" what you type on screen. If what you type differs even slightly from the first time to the second time, GPG will ask you to type your passphrase from scratch. Once you successfully enter a passphrase, don't forget it. If you forget your passphrase, you'll lose access to your own secret key, and you won't be able to regain access to it. Also, don't write it down anywhere. If other people learn your passphrase, your secret key will no longer be secret, and those persons will be able to decrypt and read all of your encrypted messages and files. They'll also be able to sign messages and files just as if they were you. After confirming your passphrase, GPG generates a keypair for you. While it is generating a keypair, GPG asks you to move the mouse around and type randomly on the keyboard in order to generate "seed" data to randomize the key generation process (thus making your keypair stronger and harder to break).
Once GPG has finished generating a keypair, it adds the keypair (both the public and secret keys) to our keyring.. Notice that GPG has signed our public key with our secret key (an act known as self-signing) and has marked our public key as "ultimately trusted." (See the GNU Privacy Handbook for more information on the Web of Trust.) Now that you've generated a keypair, you ought to consider creating a revocation certificate as well. (For more information on generating keypairs, see the GNU Privacy Handbook.) The DSA/ElGamal keypair that we generated above consists of a public key and a secret key (or private key). It also has a special type of key known as a subkey (which has its own public and secret keys). Subkeys are often used to encrypt, but not sign. DSA/ElGamal keypairs are a common combination of master signing key and encryption subkey. In some cases, as was the case with our DSA/ElGamal keypair, GPG will create the necessary subkey for you when you generate a keypair. In other cases you will have to create a subkey yourself, depending on the type of keypair you choose to generate. When you select choice (1) (DSA and ElGamal) from the key type menu, GPG automatically creates a keypair consisting of a DSA master signing key and an ElGamal encryption subkey. (ElGamal keys are a variant of the Diffie-Hellman keys familiar to PGP users.) Each key on your keypair will be used for a particular task (signing or encryption). Moreover, each will probably be different in size: the DSA master signing key is limited to 1024 bits (GPG sets this size automatically); the ElGamal encryption subkey can be up to 4096 bits (GPG allows you to set this size yourself). GPG lists the master signing key and encryption subkey separately when providing basic information about your keypair (such as with the --edit-key command).
Notice that the main public key (pub) is a DSA (D) signing key of 1024 bits; the ElGamal (g) encryption subkey (sub) is 2048 bits and is listed separately. (You might compare these two keys with the single key from the RSAv4 key generation example below.) When using your DSA/ElGamal keypair to encrypt or sign, GPG (and PGP) automatically selects the proper key (master key or subkey) to use. RSAv4 Keypairs (Sign & Encrypt) Keypairs do not have to include an encryption subkey. It is possible to create an RSAv4 keypair, for example, that consists of but one key which is used both to sign and encrypt. RSAv3 keys (discussed below) also use a single signing and encryption key. By default, though, GPG will not let you create RSAv4 keypairs with a single signing and encryption key. Since we're using the "Nullify" build of GPG 1.0.7, we can get a wider range of choices for key types by using the --expert option in conjunction with the --gen-key command.
Notice the new choice (7): an RSAv4 keypair that can encrypt and sign. With the --expert option, we now have three choices for keypairs that can encrypt and sign. If we choose (7) RSA (sign and encrypt), GPG will create a keypair with a single signing and encryption key. Once we're finished creating the keypair, we can edit it (--edit-key) and view basic information about the key.
Note that there is no subkey -- only a single key used to sign and encrypt. RSAv4 keypairs with single signing and encryption keys are not recommended, however. Re-using an RSA key for encryption and signing exposes the key to potential cryptoanalytic attacks. If you're interested in generating an RSAv4 keypair, you'd be better off generating an RSAv4 keypair with a master signing key and an encryption subkey. For a discussion of this type of RSAv4 keypair, see the next section. RSAv4 Keypairs (w/ Encryption Subkey) Although we generated an RSAv4 keypair in the previous section, we generated a special kind of RSAv4 keypair that uses a single key for encryption and signing. Here is the RSAv4 key from our example above:
A single RSA key for encryption and signing is not recommended because of its vulnerability to certain types of attacks. In fact, the only way we were able to generate such a key was with the --expert option. Normally, to generate an RSAv4 keypair, we would select choice (5) from the default menu of key types. Without the --expert option, choice (5) is RSA (sign only). After creating the master signing key, we can generate an encryption subkey.
When it has finished generating the RSA master signing key, GPG warns us that the key can be used for digital signatures only.
As GPG recommends, we can create an RSA encryption subkey. To create a subkey, use the --edit-key command and issue the addkey command from the --edit-key command line. GPG will ask for our passphrase before it allows us to make changes to our keypair.
GPG then asks what kind of subkey type we want to generate.
We'll choose (6) RSA (encrypt only), a choice that did not appear when we originally generated our master signing key above. Next we specify a keysize and expiration for the subkey.
Finally, GPG confirms our choice and generates the subkey. You probably noticed that GPG did not ask us for information to create a User ID -- that's because the master signing key already has a User ID.
Now our RSA keypair has an encryption subkey (sub). Don't forget to save your changes. If we had neglected to generate an encryption subkey and simply distributed our public key "as is," other people wouldn't have been able to use it to encrypt messages to us (they could have used it only to verify digital signatures from us). If they attempted to use our key to encrypt, they would receive an error message from GPG.
Whether you choose to generate an RSAv4 keypair that uses the same key for encryption and signing or an RSAv4 keypair with a master signing key and an encryption subkey is up to you. Remember, though, that most crypto experts recommend not re-using the same RSA key for encryption and signing. The "Nullify" build of GPG 1.0.7 (which was compiled with the RSAv3 key patch) allows you to generate RSAv3 keys, RSAv3 keys (known to PGP 7.x users as "RSA legacy keys") are PGP 2.6.x compatible. RSAv3 keys use a single key for encryption and signing -- there are no subkeys. RSAv3 keys are not recommended for precisely this reason -- re-using an RSA key for encryption and signing exposes the key to potential cryptoanalytic attacks. (This is the same reason that standard RSAv4 keys use a master signing key and an encryption subkey, as we discussed in the previous section.) Since we're using the "Nullify" build of GPG 1.0.7 (which was compiled with the RSAv3 key patch), we can use the --expert and --pgp2 options in order to generate a PGP 2.6 compatible RSAv3 keypair.
Notice choice (5), which is now slightly different from the "original" choice (5) RSA (sign only). Instead of RSAv4 keypair that can sign only, choice (5) is now an RSAv3 keypair that can sign and encrypt. Once GPG finishes generating an RSAv3 keypair, it will erroneously warn you that the key cannot be used for encryption.
Ignore this warning. Not only can this single RSAv3 key be used to encrypt, but if you try to generate a subkey for it with the --edit-key and addkey commands, GPG will refuse to generate a subkey.
RSAv3 keys can be useful if you're corresponding or working with PGP 2.6x users. If you don't need the compatibility of an RSAv3 key, though, you would be better off generating either an RSAv4 keypair with an encryption subkey (as we did just above) or a DSA/ElGamal keypair (also discussed earlier). If you've generated a keypair with an encryption subkey, you can manage the subkey somewhat independently of the master signing key. You can revoke (revkey) or remove (delkey) the encryption subkey from the master signing key and then add (addkey) a new encryption subkey. You can also set the expiration (expire) on a subkey. To work with encryption subkeys, use the --edit-key command, which allows you to use the addkey, revkey, delkey, and expire sub-commands. In case you were wondering, it is possible to create multiple subkeys for a single master signing key (the second subkey will be a signing subkey). In fact, you can even mix key types, as DSA/ElGamal keypairs do. You can mix RSAv4, DSA, and ElGamal keys in a variety of different ways (e.g., a DSA master signing key with an ElGamal encryption subkey and an RSAv4 signing key; or an RSAv4 master signing key with an RSAv4 encryption key and a DSA signing key, et al). In such cases, only one encryption key and one signing key will be used (with the last key added taking precedence). Moreover, keyservers may have problems handling such hybrid keys and end up mangling them. Unless you have a good reason to mix and match multiple subkeys in non-standard combinations, it's probably best to stick to the standard keypairs we've discussed here. (For more information on working with keypairs and subkeys, see the GNU Privacy Handbook's discussion.of adding and deleting subkeys, revoking subkeys, and setting expirations for subkeys.) Importing Keys (gpg [--options] --import files) Before you can encrypt files and messages to send to other people, you must have their public keys on your keyring. You might receive copies of other people's public keys as .ASC or .GPG files in email or in person. You can also get people's public keys by downloading them from the Internet or a keyserver. Whatever the case, once you get someone's public key, you must import it onto your keyring with the --import command. In this example, we've received a copy of someone's public key as an ASCII Armored file (prz.asc), which we can import onto our keyring
If we want to confirm that this person's public key has been imported onto our keyring, we can use the --list-keys command, which is discussed below. After you've imported someone's public key onto your keyring, you should consider signing the key and setting the owner trust level. Once a recipient's public key is on your keyring, you can use it to encrypt files and messages to that person. You can also use it to verify signatures on messages and files from that person. To give your own public key to other people (so that they can encrypt files and messages to you and verify signatures from you), you'll need to export your public key, which is discussed in the next section. GPG's --import option can also be used to import secret keys onto your keyring. For example, you might also want to import keys from your old PGP keyrings to GPG's keyrings. Some of those keys will undoubtedly be your own secret keys, and GPG will import them without a problem.
In previous versions of GPG, it was necessary to use the --allow-secret-key-import option with the --import command when importing secret keys. That is no longer the case with GPG 1.0.7 (making the --allow-secret-key-import option largely obsolete). There are still a few issues with importing secret keys from PGP 2.6.x, however. See the next section for more information on migrating your PGP keys to GPG. If you've imported your own public and secret keys onto your GPG keyrings, you'll probably want to set the owner trust and calculated trust levels to "ultimately trusted" ( u/u ) for those keys. Use the --edit-key | trust command and select "5 = I trust ultimately" when asked how much you trust the user "to correctly verify other users' keys." Setting the owner trust level to "ultimately trusted" will also set the calculated trust level to "ultimately trusted." See the Setting Owner Trust section below for a discussion of the --edit-key | trust command. (For more information on importing keys, see the GNU Privacy Handbook.) If you're moving to GPG from Pretty Good Privacy (PGP), then you'll undoubtedly have public and secret keys that you want to migrate from your PGP keyrings to your new GPG keyrings. Moving your keys from PGP to GPG is a simple, straightforward process.
What follows are instructions for exporting (or extracting) keys from PGP's keyrings using PGP 6.x/7.x or PGP 2.6x. Migrating Keys from PGP 6.x and 7.x To export your keys from PGP 6.x or 7.x:
Once you've exported your PGP keys to a key export file, you can import that file with GPG's --import command. GPG will recognize and properly import all the separate keys from that common key export file. If you've imported your own public and secret keys onto your GPG keyrings, you'll probably want to set the owner trust and calculated trust levels to "ultimately trusted" ( u/u ) for those keys. Use the --edit-key | trust command and select "5 = I trust ultimately" when asked how much you trust the user "to correctly verify other users' keys." Setting the owner trust level to "ultimately trusted" will also set the calculated trust level to "ultimately trusted." See the Setting Owner Trust section below for a discussion of the --edit-key | trust command. Migrating Keys from PGP 2.6.x To export keys from PGP 2.6.x (or other command line versions of PGP):
Once you have exported all of your public and secret keys from PGP to key export files, import those files with GPG's --import command. If you have exported multiple keys to a common file, GPG will recognize and properly import all the separate keys in that common key export file. If you are importing PGP 2.6.x keys that are not self-signed, don't forget to use the --allow-non-selfsigned-uid option when importing those keys. If you've imported your own public and secret keys onto your GPG keyrings, you'll probably want to set the owner trust and calculated trust levels to "ultimately trusted" ( u/u ) for those keys. Use the --edit-key | trust command and select "5 = I trust ultimately" when asked how much you trust the user "to correctly verify other users' keys." Setting the owner trust level to "ultimately trusted" will also set the calculated trust level to "ultimately trusted." See the Setting Owner Trust section below for a discussion of the --edit-key | trust command. Exporting Public Keys (gpg [--options] --export names) Before other people can encrypt messages to you or verify signatures from you, they must have a copy of your public key. In order to distribute your public key -- either to a keyserver or to other people.directly -- you need to export your public key. Use the --export command to export your public key. Although you can export your public key as binary data to a .GPG file, you'll find it more useful to use the --armor option and export your public key as ASCII Armor.
You can also use the --output option to specify an output file so that you have an easily transportable file.
If you open up that output file (gumbel-pub.asc), you'll see that the ASCII Armored public key block is easily usable in text email messages and other contexts that require plain text (say, posting on a web page).
This ASCII Armored file containing your public key can be distributed to others so that they can import your public key onto their keyrings. Once your public key is on their keyrings, they can use it to send you encrypted email and verify signatures that you make with your secret key. (For more information on exporting public keys, see the GNU Privacy Handbook.) Exporting Secret Keys (gpg [--options] --export-secret-keys names) You can export secret keys as well as public keys. You should exercise great caution in exporting your secret keys, though. Once exported, secret keys should be guarded as zealously as your keyrings. Use the --export-secret-keys command combined with the --armor and --output options to export secret keys to ASCII Armored files.
The output file (gumbel-sec.asc) consists of a private key block (private key being another name for secret key).
Think hard about exporting your secret keys and have a plan for guarding them before you do export them. Exporting Secret Keys for Other Platforms One reason you might want to export your secret key is so that you can import it and use it in PGP or a different installation of GPG. If you're running GPG 1.0.7 and plan to export one of your secret keys to import and use in PGP or an earlier version of GPG, you'll first need to convert your secret keys to a format that those older programs recognize. To perform that conversion, use the --simple-sk-checksum option in conjunction with the --edit-key | passwd command. You should convert your secret keys to the older format before exporting them. GPG 1.0.7 protects the integrity of its secret keys with a 20-byte SHA1 hash, a format which PGP (including the last version from NAI, PGP Corporate Desktop 7.1.1) and older GPG versions don't recognize (PGP and older versions of GPG use a simple 16-bit checksum).* If you simply export one of your secret keys from GPG 1.0.7 and then import it into PGP, for example, the key will be unusable. When you attempt to decrypt files and messages with the secret key that you imported, PGP will not recognize the passphrase (or let you change the passphrase) and thus will refuse to decrypt with the secret key. To avoid this problem, change the passphrase on your secret keys by using the --simple-sk-checksum option in conjunction with the --edit-key | passwd command before you export your secret keys. This converts the key integrity check from the newer 20-byte SHA1 hash format (which only GPG 1.0.7 recognizes) to the older 16-bit checksum format recognized by PGP and earlier versions of GPG. Here's how to do it. First edit the key (--edit-key) with the --simple-sk-checksum option.
Next, change the passphrase on your secret key with the passwd command. You'll have to enter the current passphrase before you can change it.
Note that you don't actually have to choose a new passphrase -- you can simply use the same passphrase as before. Once you enter a "new" passphrase, GPG generates the simple 16-bit checksum that PGP and older versions of GPG recognize. Make sure to save your changes. Now you can export your secret key with the --export-secret-keys command and import that secret key onto your keyring for PGP or an older version of GPG. To change your secret key's integrity check back to the newer SHA1 hash format (which provides protection against certain kinds of attacks), simply re-edit your key (--edit-key) without the --simple-sk-checksum option and change the passphrase with the passwd command. Once you save your changes, GPG will restore the format of the secret key integrity check to the newer SHA1 hash format. It is possible to use the --simple-sk-checksum option in the Options file. With --simple-sk-checksum in the Options file, any new keys generated with GPG will use the older key integrity format. Keys that were generated and placed on your keyring before --simple-sk-checksum was added to the Options file must still be converted with the --edit-key | passwd command, as described above (though you won't need to use the --simple-sk-checksum option with the --edit-key command since that option is already in the Options file). * Note: PGP 6.5.8ckt build 09 betas 1-3 do recognize the newer SHA1 format. Also, they will convert from the old format to the new, but not convert from the new to the old format like GPG 1.0.7. CKT builds of PGP are enhanced versions of PGP 6.5.8 that include support for very large keys and a wider range of encryption and hash algorithms. See Imad's PGP Page for more details. And for more information on the new 20 byte SHA1 secret key hash and how it affects PGP and GnuPG usage, see THIS page. Listing Public Keys (gpg [--options] --list-keys) You can see the public keys that are on your keyring with the --list-keys command.
GPG tells us that both keys are public keys (pub). For each key GPG also tells us the key length (2048 or 1024), the key type (R for RSA, D for DSA, g for ElGamal), the Key IDs (0A484ECB, ADBD19AD, and FAEBD5FC), as well as the creation dates and the User IDs. Finally, GPG lets us know that George and Phil's keys have subkeys (sub), both of which are 2048 bit ElGamal (g) keys. (For a discussion of subkeys, see the Note on Subkeys in the Key Generation section above.) Remember that the --list-keys command displays only the public keys on your keyring, not any secret keys for your own keypairs. To view a list of secret keys on your keyring, use the --list-secret-keys command, which is discussed in the next section. (For more information on listing keys, see the GNU Privacy Handbook.) Listing Secret Keys (gpg [--options] --list-secret-keys) You can see the secret keys on your keyring with the --list-secret-keys command..
GPG provides the same type of information for your secret keys as for the public keys on your keyring. Editing Keys (Basic) (gpg [--options] --edit-key name) While GPG can use a wide range of commands to work with the keys on your keyring, one of the more versatile and powerful commands is the --edit-key command..
When you use the --edit-key command on a particular key, GPG first displays basic information about that key (which is a public key with a subkey in this example) and then gives you a special command line. From this command line you can use particular sub-commands from the edit-key menu. We'll look at a few of them here, though you should consult the command reference for a full list of the sub-commands that can be used with the --edit-key command. In fact, many of the commands covered on this page of examples use the --edit-key command. You'll notice, in the example above, that GPG gives us much the same information about a key as we received with the --list-keys command. The --edit-key command also gives us information about signatures on the key (none at this point) as well as the trust levels assigned or associated with this key: "Trust: -/-" means that the user has not assigned a trust level to the owner of this key and that the overall trust level associated with this key is none. To change the trust levels and make this key trusted, we'll have to sign the key and set an owner trust level. (See the command reference for the --editkey command and the GNU Privacy Handbook for a more complete explanation of GPG and the Web of Trust.) You can get more information about the key owner's preferences specified on the key with the showpref command..
Note that we didn't use the leading dashes ( -- ) with this command since we're working at the --edit-key command line. There is also a pref command, but the showpref command provides information in a slightly friendlier format. (For more information on key preferences and using the pref and showpref commands, see the section Setting Preferences below.) If the key you edit is part of a key pair (meaning that you have the secret key), GPG lets you know that a secret key is available.
Right now, though, we're looking at the public key (GPG displays the public key first with the --edit-key command). To view the secret key (sec), use the toggle command..
You can revert to viewing the public key by using the toggle command again. To exit the --edit-key menu and return to a normal command line, use the quit command. If you've made changes to any of your keys, use the save command to save your changes and exit back to a normal command line. (If you make changes to your key but merely quit, GPG will prompt you to save your changes.) (For more information on editing keys, see the GNU Privacy Handbook.) Signing Keys (gpg [--options] --sign-key name) One of the more important things you will do with keys is sign them. You'll recall that when you generated your own keypair, GPG used your secret key (or private key) to sign your public key (an act known as self-signing). You can use your secret key to sign other people's public keys as well. Signing other people's keys is important because it certifies those keys as trusted and integrates them into the Web of Trust used by GPG and PGP. When you sign and certify someone else's public key, you are making a statement about your confidence that the public key you're signing actually belongs to the person specified in the User ID for that key. By signing someone's public key, you are building the Web of Trust for the keys on your own keyring and contributing to the Web of Trust for the larger community GPG and PGP users. Until you sign someone's public key and change the trust level associated with that key, GPG will warn you that the key is untrusted whenever you use that key to verify signatures or encrypt files and messages (see the note on Understanding Signatures & Trust above for a discussion of this warning). (For more information on signing keys and using the Web of Trust, see the GNU Privacy Handbook.) Before signing someone's key, you should validate it. Validating a key means that you have checked with the owner of the key (identified in the User ID) and verified that the key that you have is in fact that person's key. Ideally, you would contact the key owner and check the key fingerprint on the key you have against the key fingerprint the owner has. (A key's fingerprint is preferable to the Key ID, even the long version of the Key ID, as there is the remote chance the multiple keys can have the same Key ID.) You can get the key fingerprint either by using the --fingerprint command...
...or by editing the key (--edit-key) and using the fpr command.
Once you have validated the key, you can sign it. To sign someone's public key on your keyring, use the --sign-key command and specify the key you want to sign. GPG will ask you how carefully you have checked the identity of the person specified in the key's User ID.
If you have multiple secret keys of your own that you can use to sign others' keys, either use the --local-user option to indicate which secret key you wish to sign with, or specify the default-key option in your Options file. As you are signing with your secret key, GPG will ask you for the passphrase for your secret key.
You can also sign keys by using the --edit-key command (introduced earlier) and the sign command from the --edit-key command line..
If you chose option (2) or (3) when asked about how carefully you checked the identity of the person in the User ID, the calculated level of trust changes from none to something else. GPG prompts you to save your changes when you quit. (You could also save in order to exit back to the command line.) You can check the level of trust by using the --edit-key command.
Notice that the calculated level of trust (the right-hand value) has changed from none ( - ) to full ( f ). To set the other trust level -- the owner trust level -- you'll need to use the trust command. See the Setting Trust section below for more details. Keep in mind that the secret key you use to sign other people's keys should be a key that is itself "ultimately trusted" (u/u). (GPG automatically marks keys that you generate within GPG as "ultimately trusted.") If you sign someone else's key with a secret key that is not ultimately trusted, the trust level on the key you sign won't change. You can't build a Web of Trust around key that is not ultimately trusted. (For more information on managing and building your Web of Trust, see the GNU Privacy Handbook.) Listing Signatures (gpg [--options] --list-sigs names) You can view a list of the signatures on public keys with the --list-sigs command.
This is the same key that we signed just above. There are many signatures from other PGP and GPG users on Phil's public key, but GPG can't give us the User IDs for many of the keys used to sign Phil's key ("User id not found") because we don't have those users' keys on our keyring at this point. (We could use the Key IDs that are listed here and track down those keys on a keyserver, though.) Contrast the signatures on Phil's public key with the signatures on our own public key.
While Phil's public key has a wealth of signatures, our public key has only one signature (our own self-signature). Phil's key will be inherently more trusted in the larger PGP and GPG community -- at least until we can get others to sign our public key. For our own level of trust, however, Phil's key is just as trustworthy as our own. Why? Because we don't have the other keys used to sign Phil's key on our keyring; thus we can't assess the trustworthiness of those other signatures. In effect, those other signatures are next to meaningless for our own level of trust. The only signature on Phil's key that we know and trust is the one we made ourselves. As noted earlier, though, we could track down the other keys used to sign Phil's key and start building a Web of Trust around Phil's key on our own keyring. (For more information on signed keys and the Web of Trust, see the GNU Privacy Handbook.) Checking Signatures (gpg [--options] --check-sigs names) You can view a list of the signatures on public keys and verify those signatures with the --check-sigs command.
The exclamation point ( ! ) next to each signature indicates that GPG has verified that signature against the key used to generate the signature. Notice that GPG could not verify seven signatures because we don't have the corresponding public keys on our keyring. (We could locate and download those missing keys from a keyserver, however, and re-check all of the signatures on Phil's key.) You can also verify signatures by editing the key (--edit-key) and using the check command.
The results are the same as the --check-sigs command. (For more information on signed keys and the Web of Trust, see the GNU Privacy Handbook.) Setting Owner Trust (gpg [--options] --edit-key name | trust) Signing a key gives it a certain calculated level of trust (depending on how carefully you said you checked the identity of the person specified in the key's User ID). The calculated level of trust is but one of two different levels of trust associated with a key. The other type of trust is the owner trust level. We can assign a level of trust to the owner of the key by editing the key (with the --edit-key command) and then using the trust command. Let's look at the trust on one of the public keys on our keyring.
This is the same key that we signed earlier. The trust for this key ( -/f ) consists of two parts:
We can use the trust command to specify an owner trust level. When we use the trust command to set an owner trust level, GPG ask us specifically how much we trust the owner of this key to verify the identities of owners of other keys.
Notice that the owner trust level has changed from none ( - ) to full ( f ). You should save your changes. If you've imported public and secret keys of your own onto your GPG keyrings, you'll probably want to set the owner trust and calculated trust levels to "ultimately trusted" ( u/u ) for those keys. Use the --edit-key | trust command and select "5 = I trust ultimately" when asked how much you trust the user "to correctly verify other users' keys." Setting the owner trust level to "ultimately trusted" will also set the calculated trust level to "ultimately trusted." (For more information on importing keys onto your keyrings, see the Importing Keys section above.) (For more information on trust in a key's owner, see the GNU Privacy Handbook.) Removing Public Keys (gpg [--options] --delete-key name) There may come a time when you want to remove someone's public key from your keyring (perhaps you no longer correspond with that person). To remove people's public keys from your keyring, use the --delete-key command.
Remember that the --delete-key command removes only public keys. If you want to remove one of your own keypairs (which contains a secret key as well as a public key), you'll have to use another command, discussed in the next section.. Removing Secret & Public Keys (gpg [--options] --delete-secret-and-public-key name) Although you can use the --delete-key and --delete-secret-key commands in succession to remove one of your own keypairs from your keyring, you can remove both keys at once with the --delete-secret-and-public-key command..
Keep in mind that once you remove a secret key from your keyring, you won't be able to use it to decrypt messages and files from other people or use it to sign messages and files to send to others. Revoking Signatures (gpg [--options] --edit key name | revsig) In some circumstances you may wish to revoke a signature you made to someone's public key (perhaps you no longer trust the identity of the person specified in that key's User ID). In that case, edit the key with the --edit-key command and use the revsig command.
If you have signed someone's public key with more than one of your own secret keys, GPG will ask you about the signature made with each of those secret keys. GPG also asks you to specify a reason for the decision to revoke your signature.
As is always the case when working with your secret key, you will be prompted for your passphrase.
GPG prompts you to save your changes when you quit. (You could also save to exit back to the command line.) Once you have revoked your signature from someone's public key, you can use the --list-sigs command to view the status of all of the signatures on that key.
Notice that there is now a revocation (rev) that was generated with our secret key. This revocation effectively cancels the original signature we made (and which is still listed). And once our signature on Phils's key is revoked, the calculated trust level on his key drops to none (-/-).
(For more information on revoking signatures and other key components, see the GNU Privacy Handbook.) Adding User IDs (gpg [--options] --edit-key name | adduid) When you generated your keypair, GPG asked you for a name and email address to identify you in the User ID for your public key. At some later time, though, you may wish to add another User ID to your key (for example, to include a new email address that you use). You can add User IDs to your key by editing the key (--edit-key) and using the adduid command.
GPG asks for your passphrase because you are making changes to your key.
The dot ( . ) next to your original User ID tells you that it is the primary User ID on this key. As you have made changes to your key, GPG prompts you to save those changes when you quit. (You could also save to exit back to the command line.) (For more information on adding User IDs, see the GNU Privacy Handbook.) Setting a Primary User ID (gpg [--options] --edit key name | primary) If you have multiple User IDs on your key, you may wish to change the User ID that is designated as the primary User ID. The primary User ID is the User ID that GPG displays by default. To change the primary User ID, edit the key (--edit-key) and select the User ID that you want to be the primary User ID.
GPG uses an asterisk ( * ) to indicate your selection. Now issue the primary command to set theUser ID you've selected as the primary User ID. You'll need to enter your passphrase because you're making changes to your key.
After you quit the --edit-key menu (GPG will prompt you to save your changes) and then re-enter it, you'll see that GPG has in fact changed your primary User ID.
You should re-distribute your public key now that you have changed the primary User ID on it. Removing User IDs (gpg [--options] --edit key name | deluid) Removing User IDs is similar to changing the primary User ID. Edit the key (--edit-key), select the User ID you wish to remove...
...and issue the deluid command.
GPG does not require a passphrase to remove User IDs (though you must keep at least one User ID on the key). Don't forget to save your changes. (For more information on removing User IDs, see the GNU Privacy Handbook.) Setting Key Preferences (gpg [--options] --edit-key name | setpref) When you created your keypair, GPG set a default list of preferences for the several different types of algorithms that can be used for encryption, message digests (hashes), and compression. These preferences tell GPG what algorithms are to be employed when your key is used. Since these preferences are stored with your key, they can even affect what algorithms are used by GPG (or PGP) when others use your public key to encrypt messages to you. (For more information on ciphers, keys, hashes, and algorithms, see the GNU Privacy Handbook.) The default preferences that GPG sets on your key are:
You can get a list of the preferences on your key by editing your key (--edit-key) and using the showpref command.
You can get another version of the same list with the pref command.
The pref command, however, presents the preferences on your key as a string using a special set of codes (a kind of notation). If you compare the list (or string) of preferences from the pref command with that of the showpref command, you'll find that they match exactly. What follows are summary tables of the algorithms supported by GPG 1.0.7, the code (n) for each algorithm ("Pref Code" column), and the name of each algorithm. (The code n and the name for each algorithm can be used with many other GPG options pertaining to algorithms.) The tables also indicate which algorithms are supported by major versions of PGP as well as the previous version of GPG (1.0.6).
You can change the list of preferences on your key by using the setpref command and specifying a new list (or string) of preferences in a string just like the string that the pref command generated. After you change the preferences on your key with the setpref command, issue the updpref command to save your changes. Since you're making changes to your key, GPG will ask for your passphrase.
Once you've updated your preferences, you can check the list of preferences on your key with the pref and showpref commands -- you'll see that they've changed.
You can reset the preferences to their defaults by using the setpref command and not specifying a string of preferences. GPG also lets you specify a default set of preferences in the Options file with the --default-preference-list option (sans the leading dashes, -- ). The --default-preference-list option uses the same kind of string of preferences as the setpref command. The string of preferences that you set with the --default-preference-list option will be the default set of preferences for new User IDs, not new keypairs that you generate, however -- meaning that after you create a new keypair, you'll have to use the updpref command to set the list of preferences on your key to the defaults specified in your Options file. Keep in mind that not all versions of PGP and GPG support the whole range of algorithms that GPG 1.0.7 "Nullify" (the Win32 build used in our examples here) does. In particular, the SHA-2 hashes (SHA256, SHA384, SHA512) and the TIGER hash are not supported by most versions of PGP. (GPG can support them with the SHA-2 extension and clear signature patch, and the TIGER extension.) Moreover, no version of GPG supports the IDEA symmetric encryption algorithm by default, since it is still patented in many countries including the United States. GPG can support IDEA with the IDEA extension (or module), but IDEA can be used freely only for non-commercial purposes (for commercial uses, you'll have to buy a license from MediaCrypt). Note on RSAv3 Keys: The setpref and updpref commands, as well as the --default-preference-list option, cannot be used with RSAv3 keys, as RSAv3 keys do not store preferences. These commands and options can be used only with DSA/ElGamal and RSAv4 keys, which do store preferences. Revoking Keys (gpg [--options] --gen-revoke name) At some point in the future you may wish to revoke your key so that no one can use it to encrypt email to you. Perhaps your secret key has been compromised; or perhaps you've generated another keypair and prefer to use that key instead. Whatever the case, you'll need a revocation certificate (which is a special kind of signature) for the key. You can then import that revocation certificate onto your keyring to revoke the key. You can also distribute the revocation certificate to others in order to revoke copies of your public key that you previously distributed. You ought to consider generating a revocation certificate immediately after creating your keypair. You need not import that revocation certificate; you can simply store it for future use. Revocation certificates are especially useful if you've forgotten the passphrase to your secret key and you need some way to "disable" or revoke that key. Since you've forgotten the passphrase, the only way to revoke the key will be with a revocation certificate that you generated earlier (when you still remembered the passphrase). In a way, a revocation certificate is a kind of insurance plan that lets you keep ultimate control over your key, even if you lose or forget the passphrase. You can generate a revocation certificate by using the --gen-revoke command and specifying the key for which you want a revocation certificate generated. Use the --output option to specify an output file for the revocation certificate.
GPG asks you for a reason for the revocation.
You will need to enter your passphrase -- that's why it's a good idea to generate a revocation certificate now, while you are confident that you know the passphrase. If you've forgotten your passphrase, you won't be able to generate a revocation certificate.
Once you've generated a revocation certificate, you can either store it safely for future use, or immediately import it onto your keyring. To import the revocation certificate, use the --import command.
After you've imported the revocation certificate, you can verify that it was imported properly to the revoked key with the --list-sigs command.
Notice that the revocation certificate shows up as a signature. The --edit-key command shows the calculated trust as revoked ( r ).
Other people can import your revocation certificate onto their keyrings to revoke their copies of your public key. If someone who has imported your revocation certificate attempts to encrypt messages or files to you using that revoked key, GPG will tell them that the key is unusable (because it's been revoked).
Of course, some PGP and GPG users may not receive your revocation certificate before they use your (revoked) key to encrypt messages or files. In other words, some people may not know that you have revoked your key and will encrypt messages to you using that key. If someone does encrypt a message or file with your revoked key public key, you will still be able to decrypt it with your secret key (private key), so keep the revoked key pair on your keyring. (For more information on generating revocation certificates, see the GNU Privacy Handbook.)
Home [frames] Home [no frames] © 2000, 2001, 2002 Eric L. Howes (eburger68@myrealbox.com) |
