People just unwittingly read E-mail and assume its from the sender- and worse- will download and execute attachments. This is an extremely poor practice, and one that the vast majority of E-mail users don't see any harm in.

If there was some sort of way to be sure the person who sent you the message could prove that it was them; or if the contents themselves were encrypted so only you could read them, then you could believe your eyes and trust the message wasn't tampered with, forged, or molested in any way.

Postal mail is safer than E-mail. Cellular phones are safer than E-mail. The only thing that isn't safer than E-mail is standing on the street corner screaming your message to your buddy down the block.

Enter basic E-mail cryptography and digital signatures. Phillip Zimmerman, legendary cypherpunk and cryptographer introduced the world to easy cryptography for the E-mailing masses. Pretty Good Privacy has migrated from a free piece of software into a multinational enterprise, (inside the Network Associates family) and the de facto standard for encrypting and securing E-mail traffic. Because of projects like PGPi and fancy footwork around ITAR (International Traffic in Arms Regulations), PGP has been given to the entire world from the United States.

PGP's offering these days also offers solutions for VPNs and includes a personal firewall. Quite a far cry from PGP 2.6.3a.

But, what about compatibility? What if someone doesn't want to buy the commercial suite of PGP, or doesn't like the restrictions of the freeware version? Licensing of software is always of great concern; there is an alternative, and it has been moving forward faster than I thought it could.

GNU Privacy Guard, or GPG, is the OpenPGP-compliant encryption tool. (For more information on OpenPGP you should consult RFC2440.) Since it is designed to be fully compliant with current standards, it also works with Network Associates' PGP desktop suite of applications. It can encrypt data, and also sign data. GPG runs on a variety of platforms, such as OpenBSD, FreeBSD, NetBSD, Mac OS X, GNU/Linux, and even Win32 systems. There are also graphical shell tools for GPG for all above platforms. Some are better than others of course, but the variety is nice for the sake of individual preference.

The GnuPG Project started in 1998, and the writer and lead developer of the software is Werner Koch. The website of GPG has a FAQ, links to the software, and various documentation to get the user up and running in no time. For those that use mutt or pine for email, there are really simple ways to incorporate GnuPG into your mailer. Mutt has this support built in, so it's ahead of the game already!

There are other methods of digitally signing and encrypting E-mail that I will address at a later date; for now, you're usually better off with GPG/PGP because their use is so widespread and the market penetration is heavy.

GnuPG offers the same trust scheme that PGP uses. After generating a keypair for yourself, you can get a fingerprint of the key, and use that to easily verify the integrity of your public key on another user's system.

Suppose I send my public key (id E7BEE971) to another user via insecure means. I can read the fingerprint of this key (DE40 C3B3 2D00 B9DF AA58 2A28 3B8C B783 E7BE E971) over the telephone to my associate to verify that the public key wasn't molested in transit.

Of course the best way to give someone a key that is valid is in person or through some other secure means physically.

When you have your keypair generated, you can submit your public key to a local keyserver or the public keyservers. Depending on your mailer, your next stop might be setting up integration with it to automatically encrypt or sign messages to others with your default key.

If you're like me and you decide to bring in your old PGP2 keys, or you keep more than one set of private keys for other reasons, you can set your default in the GPG options file (~/.gnupg/options).

Put in a line that looks like:

	default-key 0xE7BEE971 

But instead you'll put your key ID in there, not mine! This makes the default behavior of GPG more predictable and easier to follow. (Transition users from Win32 or Mac OS PGP will note that this is the same as setting your key as your default in the PGP GUI of course.)

I also need interoperability with PGP6, since I use it on Mac OS 9 and Windows systems on occasion. I have another line in my options file:

	compress-algo 1

If your system has a choice of ways to get entropy for GPG, you can set the use of extensions in the options file also. Many systems have /dev/random these days so this isn't always needed, but some people have to use EGD (entropy gathering daemon, a perl script that generates entropy for you) so you can set its use in the options file also if needed.

Now, you can enter some sketchy territory if you wish and make a key in GPG that will work with GPG, as well as PGP on your other systems. This is accomplished by going into key generation with GPG, (gpg --gen-key) and picking the default key (DSA and ElGamal) and setting the size at 1024 bits, the default.

Some may suggest that a higher keysize is important. This is half right from my understanding and experience: a higher keysize is all well and good, but the private key will stay at 1024, making it the weak link in the chain that can't be changed. Plus, the higher keysize your public key has, the longer it takes for others to encrypt data to you. While the time it takes to encrypt usually isn't great, it's time spent watching the mailer sit there aimlessly doing some big math, which can sometimes be bothersome.

At any rate, using a 1024 bit keypair and setting an expiration, name, and passphrase will finish the key with some things to consider and keep in mind:

1. I always set an expiration date on a key. Actually, I take that back, I have a few keys on the keyserver that don't expire. They are also useless to me because I long ago lost the private keys that matches up with them. Get my meaning? It's easier to see which key is "newest" when one of them will expire before the other, or better yet, has expired.

   Also to note, a key that is "always" going to be valid is more likely to get misused should your passphrase fall into the wrong hands or should the key get cracked open like a walnut.

2. Speaking of passphrases a moment ago, make sure you use a good one. Duh! VaRyInG-cAs3-aNd-Mi$p33l1ngZ help in this, as does the use of sentences or other means of getting one in there.

   Shoulder surfers in your office may think you weird for typing in 15 words or so, but you'll be better off.

3. If you're going to move this immediately to a machine with PGP on it so you can use the same key in both places, *ahem*, don't set a passphrase yet.

Now you should be able to use the key on both systems and both applications fine, but one thing I'd keep in mind is adding UIDs, so if you put four more E-mail addresses into your keys, you'll have to do this again, so be careful and think ahead if possible.

With the above mentioned --edit-key flag, you can also assign trust properties to keys you get from others. You can set various levels of trust depending on how you got the public key from another user, or the method of verification used to make sure the one you got was "good". If you harvest dejanews for a fingerprint in the .signature of the user and get the public key from a keyserver, you may assign a very low trust value to the key.

One way to find out if you trust the key or not is also to check for a path back to a key you do ultimately trust. Suppose I want to evaluate my trust of a key and I go into --edit-key on it.

I would type trust and type s to [s]how me more information. If no certificates come back (i.e. nobody I trust completely has "signed" this key to validate it), it will tell me. If someone I do trust completely via my keyring has signed the key, it will let me know, and I can base my decision on that.

Signed keys are a form of "history" with a public key. Another user can act as an introducer, like at a party. Hello, this is So-and-So, a friend of ours.

File cryptography and digitally signing a file or message is easy as cake.

I took one of my mail folders to use as an example. Now, a lot of my E-mail comes in encrypted, and I have to type in my passphrase to my private key to read it anyway. But, nobody in my family uses it (despite my begging!) so ~/mail/personal/family is where I will demonstrate this capability.

If, for some odd reason, I was going to make this archive of 4 megs of mail available to the world (yeah, right!), I would also have a detached signature of this file, so that people could verify the signature on the archive to verify it was intact and not tampered with.

Now if you want to put an inline plain text signature into this archive, you can do that, too with gpg --clearsign [filename]. This is similar to an inline email signature, since it puts it at the bottom and is ASCII based:

	-----BEGIN PGP SIGNATURE-----
	Version: GnuPG v1.0.4 (OpenBSD)
	Comment: For info see http://www.gnupg.org
 
	iEYEARECAAYFAjqhwxAACgkQO4y3g+e+6XE1ZACeNkBtJyEdjhY/I/fT0rC/kXqO
	/AMAn08BsUapUyX0ZGFvkrBqQnwZi3Na
	=7rVJ
	-----END PGP SIGNATURE-----    

I also thought I may want to encrypt my spam archive for some reason. I have procmail archive a bunch of E-mail that's obviously crap so I don't even have to see it. (For the record don't send me E-mail with "MAKE MONEY" in the Subject: header, nor "XXX" for that matter.)

To do this, I simply typed:

gpg --armor --encrypt spam

I used the --armor tag in my example above because I generally prefer ASCII output in files:

	gleemonex[emory][23:30]% head spam.asc                  
	-----BEGIN PGP MESSAGE-----
	Version: GnuPG v1.0.4 (OpenBSD)
	Comment: For info see http://www.gnupg.org
 	
	hQMOA6iCFZUxNFg5EAv/fcjABHddf1dH9/CmXehJQ1RhOZiWU5EW3H2oKRdSgHxX
	S3tTWb+u0+3cbmvdsanIF+rmo59wNDohxGU4EuLpz4/JBRKcRbqfQh2KPWUqvfIH
	wR+pp5dwmoj2Oas/mpBO1Bg4sQjMN1e/P6e1jhsCy1JPsFFouINFhKD50vnew92a
	r+SaPCwCIc1TzU4EnVgcP1skZRajAjsKb/Rp6/kOOxkjqW9eZ1y30xj7cbm2THL3
	Vy83q3U5rYTGOR4Lefw+mUtNUIY6Hc4CAH+YjCi1MKFb8Gr2ZW3dagWkaef7BMTw
	OlqcsSOGCe2vbEmCMutPqap+AhJgX0hGhk+c81xTo19DBqj5V/TQs6F5BBFwRrFz 

With PGP compatibility, a "more free" license, a talented development team that strives for standards compliance and an amazing list of supported systems, it's hard to go wrong with GnuPG.

In a future article, I will talk about another method of securing your E-mail using S/MIME. Similar methods, and a different trust model make X.509 certificates with E-mail a very interesting topic!

For more information on GNU Privacy Guard, please visit the website at http://www.gnupg.org/, where you can find installation notes, configuration documentation, and FAQ. You can also find links to software related to the project such as front-ends and integration software and scripts.