GPG: the Best Free Crypto You Aren't Using, Part I of II

An introduction to the underappreciated, 100% free utility you didn't know you needed (but do)--GnuPG.

Obtaining, Compiling and Installing
GnuPG

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:

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.

Should gpg Be SetUID=Root?

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

Quick-and-Dirty GnuPG: Verifying a File
Signature

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.

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
(mick@visi.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.

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.