GPG: the Best Free Crypto You Aren't Using, Part I of II
GnuPG is, as I mentioned at the beginning, now a standard package in most Linux distributions. As is true of all security software, it's particularly important that you keep current, so even if your distribution includes gpg you'll want to check http://www.gnupg.org/ from time to time so you know when new versions are released.
Naturally, this web site is where you can also obtain the latest source code release of GnuPG. Should you need or wish to build GnuPG from source, simply download the tarball to the directory of your choice (/usr/src is good), and execute the commands below:
cd /usr/src tar -xzvf gnupg-1.0.6.tar.gz cd gnupg-1.0.6 ./configure make make check make install
Note that your tarball's name may be different; as of this writing GnuPG v1.0.6 was current, but by the time you read this it may not be. The same applies to the directory extracted from the tarball.
Note also that the make check command is optional and somewhat time consuming, but I think it's useful: it prints out some interesting information about supported encryption algorithms and runs a battery of tests that let you know immediately whether gpg built properly. If any of these tests fail, there's no point in running make install until you've fixed the problem. In the unlikely event of a failed test, refer to the files INSTALL and README for clues as to why.
You may be aware that in general, running programs with their SUID (set user ID) bit set is to be avoided. The SUID bit, which can be set for each file using the chmod command, causes an executable program to run with its owner's privileges regardless of who runs it.
For example, if a program has an s instead of an x in the user portion of its file permissions (as displayed by s -l), and if that program is owned by root, then any time that program is executed it will have the same rights on the system as root; it will be able to do all the things root can do.
Sometimes programs are installed with this bit needlessly set and with ownership assigned to root. This, however, is not one of those cases. You really should run gpg SETUID (SETUID=root, since root owns gpg) in order to mitigate the risk of a hostile user reading memory containing a gpg private key or its passphrase.
After make install finishes, I recommend that you set this bit with the following command:
chmod u+s /usr/bin/gpg
After you've installed gpg (whether from source as described above or from your Linux installation media), you're ready to create a personal key pair and start building your own little corner of the Web of Trust. But I've already reached the end of this month's column, so instead let's do something that doesn't require us to have a key pair of our own: verifying a signature created by someone else.
As I mentioned earlier, digitally signing a software package has become a popular means of providing end users with a means of verifying that the software they download is the same software its developer put on-line.
The command to verify a detached signature (a PGP signature can either be attached to the file it was created for, or it may be stored separately in its own file) is gpgv. If we invoke this command on a signature but don't have a copy of the signer's public key, gpgv will return an error. In Listing 1 we see a session in which this occurs.
Let's dissect Listing 1. There were three commands invoked:
gpgv gpa-0.4.1.tar.gz.sig gpg --keyserver pgp.mit.edu --recv-keys 621CC013 gpgv --keyring pubring.gpg gpa-0.4.1.tar.gz.sig
The first time I ran gpgv (which you may recall is a stripped-down version of the gpg command used for verifying signatures) I simply supplied the name of the detached signature I wished to verify. Had I had the appropriate public key on gpgv's keyring, $HOME/.gnupg/trustedkeys.gpg, this command would have succeeded, but I didn't, and it didn't.
In the second command, therefore, I ran the regular gpg command with the --recv-keys directive followed by the ID of the key I had been told by gpgv had been used to create the signature. I also specified that gpg should look for this key on the keyserver pgp.mit.edu. The key was there, so this command succeeded.
In the third command, I realized I'd just downloaded the key to my default keyring, $HOME/.gnupg/pubring.gpg, so I used the gpgv's --keyring parameter when I reran it. And this time it worked!
There's only one thing I left out in the example, of course, and that was verifying that the key I took the trouble to download was actually from its alleged owner, Werner Koch. And I did do this—it took all of 20 seconds to do a search on www.google.com for “621CC013 werner koch” that turned up a number of mailing-list postings and web sites on which Werner had included this key ID in his e-mail signature.
Were someone to succeed in hacking the web server from which I downloaded, replacing the file with a Trojan horse or virus and a signature created with a bogus key, and then posting the bogus key on pgp.mit.edu, their skulduggery would be easily detectable by a quick web search like the one I did. I doubt very much that even the most intrepid evildoer would succeed in removing or altering all web sites, Usenet archives, etc., linking his or her victim's name to keys other than the bogus one. So you see, the Web of Trust can work, provided one bothers to do a little follow-up now and then.
I'm already out of space for this month, but there are plenty more useful things to do with GnuPG that we'll discuss in-depth next time. I hope you won't wait until then to try them out!
Mick Bauer (email@example.com) is a network security consultant in the Twin Cities area. He's been a Linux devotee since 1995 and an OpenBSD zealot since 1997, and he enjoys getting these cutting-edge OSes to run on obsolete junk.
|Speed Up Your Web Site with Varnish||Jun 19, 2013|
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
- Speed Up Your Web Site with Varnish
- Containers—Not Virtual Machines—Are the Future Cloud
- Linux Systems Administrator
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- RSS Feeds
- Senior Perl Developer
- Technical Support Rep
- Non-Linux FOSS: libnotify, OS X Style
- UX Designer
7 min 5 sec ago
- Reply to comment | Linux Journal
29 min 24 sec ago
- Android has been dominating
33 min 56 sec ago
- It is quiet helping
3 hours 19 min ago
3 hours 36 min ago
- Reachli - Amplifying your
4 hours 53 min ago
5 hours 41 min ago
- good point!
5 hours 44 min ago
- Varnish works!
5 hours 53 min ago
- Reply to comment | Linux Journal
6 hours 23 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?