Lurking with PGP
When people verify that their copy of someone else's key is correct, they don't laboriously check 1000-10000 characters of the ASCII representation of the key. Instead, they compare an abbreviated form called a fingerprint. Each key is verified by its fingerprint, which is represented by 32 hexadecimal characters. The possibility of two keys having the same fingerprint is so close to nil that you don't even have to consider it. So if the fingerprints match, the keys match.
Before checking fingerprints, it is best to quickly check the ID. The ID is even more abbreviated; it consists of only 8 hexadecimal characters. If, for instance, a user uses two different sets of PGP keys, the ID is used to differentiate between them.
Since we started with comp.os.linux.announce, let's show how you can easily retrieve the public key for verifying those messages. (I assume that you have PGP installed. If you don't, I'll explain later how to do that. I just want to keep things simple for now.)
PGP normally tries to do the right thing without being told. If you feed it a public key, it figures that you want to add it to your “public key ring”, available for inspection or use at any time. Normally, you call it with the name of a file, so try this:
finger wirzeniu@kruuna.helsinki.fi > /tmp/cola pgp /tmp/cola
If PGP complains “Key ring file 'home/.pgp/pubring.pgp' cannot be created”, then you should create the directory ~/.pgp and try again:
mkdir ~/.pgp pgp /tmp/cola rm /tmp/cola
PGP will ask if you want to add the key to your public key ring; answer yes. When it asks whether you want to certify any keys yourself, answer no. You can't do that without having created your own public and private key. You will still be able to verify messages, but you can't use some of PGP's built-in features. This will look like Listing 2.
The comp.os.linux.announce key is now on your public key ring, and you can now use it to verify posts made to comp.os.linux.announce.
Now let's try checking the signature on a message posted to comp.os.linux.announce. Using your newsreader, save a message to a file, preferably with the extension “.asc” (short for ascii). Let's save it in the file cola.asc, and then call PGP to check the signature:
pgp cola.asc
PGP is verbose (as usual), and checks the signature. Part of what it says lets us know that the signature checks out Okay—but it warns that it can't be sure, because you don't have a key of your own:
File has signature. Public key is required to
check signature. Good signature from user
"Lars Wirzenius <wirzeniu@cs.helsinki.fi>".
Signature made 1996/05/01 11:36 GMT
WARNING: Because this public key is not certified
with a trusted signature, it is not known with
high confidence that this public key actually
belongs to:
"Lars Wirzenius <wirzeniu@cs.helsinki.fi>".
If you want to get rid of that warning, you will have to create your own keys, and before you do that, you ought to read the manual and understand it.
PGP also saves a copy of the message without the signature in a file called cola—it strips the .asc from the filename. If you had saved the original message in a file named “cola”, it would have asked you for a different filename to put the unsigned message in. Unfortunately, at the present time, the only way to check a signature without creating a new file containing the unsigned text is to press CTRL-C when PGP stops to ask you what to do.
In order to verify that your copy of a key is the right one, you need to put the key on your keyring, and then use PGP to print its fingerprint. Use the command:
pgp -kvvc user_id
where user_id is either part of the recipient's e-mail address or the actual 8-character key ID. Listing 3 shows part of the output of this command for the key used to sign Announcements of the Linux Emergency Response Team (ALERTs), which are used to announce security issues related to Linux. This (-kvvc) shows a lot of information for each key; you can get a more concise listing with the command:
pgp -kvc user_id
Now try to print the fingerprint for the key Lars uses to sign comp.os.linux.announce postings. You can check it below.
Once you have generated the fingerprint, you need to compare it to a trusted version. That might mean the fingerprints listed in this article, or it might mean calling the sender on the phone, or it might include a fingerprint listed in a book. There are many options—it's up to you to judge if the option you choose provides good enough verification for your purposes.
Here is a list of IDs and fingerprints for important and useful keys in the Linux world:
Lars Wirzenius's comp.os.linux.announce key:4CBA92D1 E7FA89856D9B781D F530EBFBD811CA3F
Linux Security FAQ Primary Key used to verify ALERTS:ADF3EE95 AB4FE7382C3627BC 6934EC2A2C05AB62
Ted Ts'o's signature key used to sign other people's keys (Ted organizes PGP-signing BOFs at conferences, and so has signed many other people's keys):466B4289 9C056649DF837EEF D8AC7542A2334B91
Your humble author, who will also be organizing PGP-signing BOFs at some conferences, and wants to show off:4536A8DD 2AEC88084064CED8 DDF8122B61438315
(Please note that in order to fit the fingerprints into the article, we have removed many of the spaces. The spaces are just there to help you read the fingerprint, and the fingerprint is the same with or without spaces.)
Linux developers are starting to talk about listing their PGP key IDs and fingerprints in the CREDITS file in the Linux kernel source code.
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.
Sponsored by AMD
If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.
Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.
Sponsored by ActiveState
| 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 |
| Introduction to MapReduce with Hadoop on Linux | Jun 05, 2013 |
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Linux Systems Administrator
- Validate an E-Mail Address with PHP, the Right Way
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Introduction to MapReduce with Hadoop on Linux
- RSS Feeds
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?




18 min 16 sec ago
51 min 25 sec ago
52 min 24 sec ago
53 min 18 sec ago
55 min 23 sec ago
56 min 27 sec ago
58 min 8 sec ago
59 min 7 sec ago
1 hour 39 sec ago
1 hour 1 min ago