Summary: File and mail security is easy to achieve with the right tools. PGP has proven itself the leader, and GnuPG is the tool of choice in the Linux world..

Sorry for the delay. Read the footnote[1] if you're curious what's going on out here in Seattle.

Anyone who has read this column a while knows I'm a bit obsessive about crypto. With the speed of modern or even old processors, there's no reason that there should be any cleartext transmissions on the Internet at all.

Over the next few articles, I'll cover PGP (Pretty Good Privacy) and the GnuPG (GNU Privacy Guard) implementation of it.

PGP is the defacto encryption and authentication algorithm for file and email security.[2] PGP does not protect transmissions, such as Telnet, HTTP, etc. You could probably build something to do a VPN in a PGP-like manner[3], but it's traditional use is file/email protection.

PGP offers the abilities you'd expect from crypto:

Encryption

The ability to keep anyone except your intended recipient(s) from reading what you send.

Authentication

The ability to verify that a message came from the sender, not someone impersonating as the sender.

Integrity

The ability to prove that the message arrived intact, as the sender created it, without any tampering.

The important thing about the public and private keys is that they are complementary. Specifically:

Data encrypted with the public key can only be decrypted with the private key.

Data encrypted with the private key can only be decrypted with the public key.

To explain how these keys work a bit more, let's take an analogy. In the 'real' world, you have a lock on the front door of your house. You use the same key to lock and unlock the door. This is akin to symmetric key cryptography in the crypto world, algorithms like blowfish, IDEA, or RC4.

In PGP, the keys that the end user will be dealing with are the public/private keys, which are part of an asymmetric cryptographic system. Examples include RSA and DSA. If we had this in the real world, you'd have two front door keys. You could use key 'a' to lock, and then only key 'b' could unlock it, or vice versa.

Over the next weeks I'll show you how all the pieces go together, but here's our rough outline:

First, we'll create a key pair, and learn about the various bits of info it contains. We'll then learn how to exchange this key with others, including key servers, and how you can encrypt, sign, and verify messages manually. We'll also show a bit of how PGP/GnuPG can be integrated with other tools so you can have everything automated.

NOTES:

[1] Delay was due mostly to problems with the twins -- Bree went into pre term labour, ultrasound shows twin-to-twin transfusion syndrome, Bree in the hospital for two weeks over Thanksgiving, daughter having trouble getting accustomed to the situation, etc. Bree's back home now on bed rest.

In other news, we're conducting a survey for baby names for the twins. You can find it at http://www.ifokr.org/bri/name-the-twins.cgi.

[2] S/MIME, which uses X509 certificates, is the other main contender. X509 certs are the same things you are authenticating when you use SSL such as with https:// url's.

[3] And I'd be surprised if no one has done so at some point.

[4] Now had they allowed themselves to be bought out by Microsoft, that'd be another matter.

Bri Hatch is Chief Hacker at Onsight, Inc and author of Hacking Linux Exposed and Building Linux VPNs. Once he's reached the end of this topic of newsletters, he's going to give a free book to one randomly chosen person who's signed his PGP key (keyid 5217530F). If you want to verify it with him, by all means do so. Bri can be reached at bri@hackinglinuxexposed.com.

Copyright Bri Hatch, 2003

This is the December 04, 2003 issue of the Linux Security: Tips, Tricks, and Hackery newsletter. If you wish to subscribe, visit http://lists.onsight.com/ or send email to Linux_Security-request@lists.onsight.com.