GPG: the Best Free Crypto You Aren't Using, Part II of II
After you've generated your key, you should immediately create a revocation certificate. This is a string of text that you can send to a keyserver if and when you need to revoke your key.
Of course, you can create a revocation certificate at any point. The reason it makes sense to create one now is that it's not uncommon for even very knowledgeable and careful people to forget their passphrase. You need your passphrase to create a revocation certificate, but not to use one you created earlier.
That's why it's a good idea to create a revocation certificate now and save it in a safe place (you can even print it out and save it in “meatspace”--revocation certificates aren't very long). Just be sure to set its file permissions to be as strict as your private key's (e.g., not group- or world-readable or writable). The ramifications of someone sending the certificate to a keyserver without your permission aren't as scary as if someone can actually use your private key, but at the very least a prematurely revoked key could inconvenience you.
To generate a revocation certificate, enter this command:
gpg --output rev_cert_filename.asc --gen-revoke keyname
where rev_cert_filename.asc is the filename you'd like the certificate to have (just make sure it ends in .asc) and keyname is the key's ID number (e.g., 0586AF78) or part of your identity (“Smooth JoJo” would be enough to identify our example key).
GnuPG stores its files in a subdirectory of your home directory called .gnupg. Any private keys you have are stored in a file called secring.gpg; public keys are stored in pubring.gpg. By default, secring.gpg is readable only by you; leave it that way. It's extremely important that you protect this file. By all means, back it up to a floppy or CD-ROM, but keep your backup in a safe place. If anyone obtains a copy of your secret keyring, they may be able to guess or brute-force-crack the passphrase of your private key and effectively steal your identity (or at least be able to decrypt your stuff).
Both pubring.gpg and secring.gpg are binary data files. To add, delete or change keys on either keyring, you need to use various flags with the gpg command.
For example, you're going to want to distribute your public key to your friends, right? So let's extract that key from your public keyring into a text file (see Sidebar “Armored ASCII vs. Binary GPG Files”). To print your public key to the screen, from whence it can be copied and pasted as needed, you need simply enter:
gpg --armor --export
the output of which will look something like Listing 2.
I took the liberty of simplifying a bit here; if you don't specify a user ID, gpg will dump the public portion of your default key pair. If you only have one private key, then that key pair is your default key and that pair's public key will be dumped.
If, on the other hand, you wish to dump some other public key, you need to specify a user ID. Continuing our example using Mr. Figplucker, to display JoJo's public key we enter:
gpg --armor --export jojo
As you can see, gpg is fairly intelligent when trying to determine which key you want to work with. In fact, it works a lot like grep: if you give a snippet of your e-mail address or some other text as your key identifier, gpg will match the first key whose user ID contains the string. In managing my own keyrings, in which I have several private-public key pairs and therefore numerous user IDs containing my name, I find it easiest to provide gpg with the entire e-mail-address portion of the key I wish to work with at any given time, e.g., gpg --armor --export firstname.lastname@example.org.
By the way, if you want to print a key to a file rather than to the screen, specify a filename with the --output option. To write JoJo's public key to the file jojo_pub.asc, the command would look like this:
gpg --armor --output jojo_pub.asc --export jojo
Have you backed up your new keys yet? You may consider exporting your entire key pair, including your private key, but I recommend against doing this. You're much better off simply copying the keyring files pubring.gpg and secring.gpg from ~/.gnupg to a safe place. But if for some reason you do need to export your entire key pair, it's the same as exporting a public key except that you use the --export-secret-keys command rather than --export.
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
|Trying to Tame the Tablet||May 08, 2013|
- RSS Feeds
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Download the Free Red Hat White Paper "Using an Open Source Framework to Catch the Bad Guy"
- Tech Tip: Really Simple HTTP Server with Python
- Readers' Choice Awards
- Please correct the URL for Salt Stack's web site
13 min 13 sec ago
- Android is Linux -- why no better inter-operation
2 hours 28 min ago
- Connecting Android device to desktop Linux via USB
2 hours 57 min ago
- Find new cell phone and tablet pc
3 hours 55 min ago
5 hours 24 min ago
- Automatically updating Guest Additions
6 hours 32 min ago
- I like your topic on android
7 hours 19 min ago
- Reply to comment | Linux Journal
7 hours 40 min ago
- This is the easiest tutorial
13 hours 54 min ago
- Ahh, the Koolaid.
19 hours 33 min ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?