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..
|
