Running Linux, 5th Edition - Matthias Kalle Dalheimer [103]
To make this key available for others to encrypt messages to you using it, you have to upload it to a keyserver using
gpg --keyserver wwwkeys.pgp.net --send key-id
where key-id is the ID of the key (461BA2AB in the case of the key created above). The keyserver can be hardcoded into ~/.gnupg/gpg.conf so you do not need to give it on the command line every time you upload or download keys. You do not need to upload a key to more than one server, because the pgp.net servers synchronize new and changed keys among each other.
It is important at this point to take precautions for the case of a lost passphrase: If the key gets compromised, or you simply forget the passphrase, you want other people to know that this key should no longer be used. This is the purpose of a revocation certificate. A revoked key can no longer be used as an encryption target. To create a revocation certificate, however, you need to know the passphrase to unlock your secret key. So in order to have a revocation certificate ready for publishing in the case of emergency, you have to create one while you still remember the passphrase, and then store it somewhere safe.
To create such a revocation certificate, you can use the command gpg --armour --output rev-cert.gpg --gen-revoke key-id. This will create a revocation certificate and save it in rev-cert.gpg. The --armour option tells GnuPG to create a printable version instead of a binary file. This way, you can print the certificate and store it on paper as backup in case of hard disk failures.
To apply the revocation certificate, simply import it by using gpg < rev-cert.gpg, and then upload the changed key using gpg --send key-id, as shown earlier.
* * *
Warning
Keys uploaded to a keyserver cannot be removed. Furthermore, they can only be added to; no data will ever be removed from them. This includes additional user IDs and third-party signatures (discussed shortly), as well as revocations.
* * *
Encrypting with Public Keys
As mentioned earlier, when doing public-key encryption, you need to have the recipient's public keys. For GnuPG, this means they need to be downloaded from a keyserver, and that there should be a trust path (see "The Web of Trust," later in this chapter) from your key to the recipient's key.
For now, we can make do with a speciality of GnuPG: encrypting to untrusted keys.
First you need to find the key on the keysever. You can use the GnuPG search interface for this: gpg --search name-or-email. GnuPG will list all matching keys (which can be hundreds) in a list, from which you can choose one to import.
If you already know the key ID of the recipient's key, then you can download it directly using gpg --recv key-id.
Next, you can encrypt a file using one or more keys. Be aware that GnuPG does not necessarily encrypt using your key, too (this is an option in the config file), so you might not be able to decrypt the message any more. The command to use is:
gpg --encrypt --recipient recip_1 --recipient recip_2 ... file
A shortcut notation for this is:
gpg -e -r recip_1 -r recip_2 ... file
Both versions create the encrypted message in a file called file.gpg, unless the --output (-o) option is used to redirect the output to a non-standard file. No matter to how many recipients you encrypt, there will always be only one output file — it will just be generated such that all the recipients are able to decrypt it.
To decrypt a file, simply run GnuPG on it: gpg file.gpg. GnuPG asks for your passphrase and then saves the decrypted file into file (i.e., the name of the input file stripped of the .gpg extension).
If you want to encrypt a lot of files in one go, consider using --multifile, like this:
gpg --multifile -e -r recip_1 ... file1 file2 ...
Digital Signatures
Public-key