[ Current Issue Home | Issue #2 Home | FAQ ]��

The FreeBSD 'zine
Featured Articles: PGP
## Secure your Email
## Oben O. Candemir <>

Privacy in our modern age has become a thing that requires an expenditure of effort to gain. Everywhere, we are watched, listened to, and monitored. Many people do not even blink an eyelid before they hit the send button on their email program. Perhaps they think that their email is seen only once on their computer and then through the wonders of the net arrives on their correspondents computer to be seen again. They are perhaps unaware of the circuitous routes of email traveling from machine to machine available to be read at each step of the way. I would guess that that scenario describes many users of popular 'no fuss' OSes where email sending is as opaque as the workings of most of the core of the system. Unix and FreeBSD users on the other hand are probably very aware (usually due to potentially hours of setup) that email may take many steps in arriving at their recipient's computer. It is surprising then that more people do not think about privacy when sending off email.

However I'm not here to advocate privacy to you. Each user can make up their own mind as to whether they think their email is worth protecting from unwanted reading. Phil Zimmerman the author of PGP (Pretty Good Privacy) describes it well in the PGP man pages by likening the sending of un-encrypted email to the sending of all of your normal mail on postcards able to be read by anyone. He uses this scenario to remind people that it is not just people with something to hide that need to protect their email. Most law abiding citizens would normally place their normal mail into an envelope even though they could send it as a postcard. Therefore using a program that encrypts email, like PGP, can be thought of as an envelope for your email. In this way, encryption can serve the same purposes as a physical envelope. It prevents unauthorized reading and also prevents alteration of your message.

Once you decide that you do want to put your email into an 'envelope', your next step should be to get the FreeBSD PGP 5.0i package and install it. The 'i' stands for 'international', US residents may download a version from the main PGP site. The reason that there is two versions is due to US bans on the export of encryption technology. Cryptographic systems are understandably important to the military (their are some excellent essays on the role that 'cracking' of the German 'Enigma' ciphers played in their defeat), and software like PGP is classed as a 'munition' and therefore export controlled. The 'i' versions of the software are made by scanning in hard copies of the PGP code in Europe and compilation thereby getting around the technical problem of exporting compiled software.

The Theory

To use PGP successfully depends upon the user understanding the concept of 'public key cryptography'. This is best understood by thinking of a hypothetical key ring you own containing two keys; say a green key and a red key. These keys operate in the following fashion; what one key locks only the other can open. So if we lock something with the red key then only the green key can open it up again. And in a similar fashion, what the green key locks only the red key can open. These keys are said to be a complementary pair. Now say that we always kept the red key to ourselves in a secret fashion but made as many copies of the green key as we wanted and gave them to anybody interested in sending something to us. The green key could be called the 'public' key that is distributed to everyone to use and the red key the 'private' key that is solely for our use.

I hope the picture is becoming clear now. Your friends could now lock/encrypt something that is intended for your eyes only with the green key you have given them. Note that once they lock it up even they cannot open it up again. Only the red key can do that, and that happens to be in your safe hands (we hope). So when they transmit the locked 'object', only you are able to unlock and see the contents. In a similar way if your friend had a similar 'key pair' he could give you a copy of his 'green' public key to use to lock things up you intend to send to him. That way he can unlock them with his red 'private' key. Therefore we now have a way of sending each other things in the knowledge that no-one else can see true contents, even though they may be handled by many people.

Obviously when speaking in terms of email, the keys we speak of are of the silicon variety. The keys are generated using various 'one way' algorithms. These are mathematical systems in which it is trivial to go in one direction but very difficult to go in the other. There are many such 'one way' algorithms in mathematics. The most widely used is the 'factorization' problem. Most people should be familiar with the fundamental theorem of arithmetic that says that all numbers can be factored into a unique set of prime numbers. Imagine we had two extremely large prime numbers (in the order of eighty or ninety digits in decimal notation - huge by any human standards) and multiplied them together. We would have an even larger composite number that has two prime factors. Given just this latter number (and no knowledge of either prime) the problem of factoring it into the two primes we had originally turns out to be a very difficult problem. Even the most sophisticated factoring algorithms combined with the most powerful computers are unable to factor a 2048-bit (binary notation) number in anything approaching a human lifetime. In fact the average times to factor such numbers can be in the order of billions of years!! There is no question as to the security of these systems. Note that it is still not proven whether a simple factoring algorithm exists. No one has been able to prove that it does or doesn't (either would be useful).

What is the advantage of this over other cryptographic systems you might ask. Cryptographic methods have existed for as long as humans have been communicating. All methods of cryptography require the use of 'keys' or more formally 'ciphers'. The classical methods of encryption require the knowledge of the same key by both parties (simple substitution cipher for example where A is encoded as Z, B is Y, C is X etc). The transmission of the key or cipher to be used from one party to the other requires a secure channel of communication to protect the code from 'enemies'. Now if the two parties have a completely secure channel to transmit the key then why not just use that same channel to transmit the message? The beauty of public key systems is the elimination of the need for secure channels of communication.

A final question may be: Why PGP and not some other program? The answer to that is that PGP is one of the only strong encryption programs that has source code fully available. This serves the purpose of opening up the code for peer review and scrutiny. This means PGP is unlikely to have any major flaw in its encryption algorithm; it is basically bombproof in that regard. The next issue is the incorporation of secret 'back doors' into encryption software that would allow decryption without the required keys. PGP does not have any such backdoor decryption techniques. This has a downside (if you can call it that); it means that if you lose your decrypting key (your private key) then all material encrypted with your public key will be unreadable... forever. That's why you must backup your private key (multiple times) on separate media.

That's the theory, here's the good stuff...

The Practical Part

I'm assuming you have got and installed the PGP 5.0i package. Version 5.0i for Unix differs from the 2.6 series of the software in that it has divided the various PGP tools into separate binaries. The package will install the following files into /usr/local/bin:

  1. pgp:	Displays message informing of change to multiple binary files
  2. pgpe:	Encryption (including Encrypt/Sign) binary
  3. pgpv:	Verify/Decryption binary
  4. pgps:	Sign binary
  5. pgpk:	Key management binary
  

The first step in using PGP, is the generation of a key pair for yourself. This is done by using the 'pgpk' binary. On a recent Pentium system, key generation can take as little as several minutes. The command to give is: 'pgpk -g'

This will start up key generation in an interactive fashion. It is relatively straightforward and explained more than adequately in the documentation anyhow. The most important thing to remember is to use a 'strong' pass phrase. By phrase I really mean that; so a phrase of 'ace' would be extremely poor whereas 'I milk 101 cows on Saturday' for example would be better. The key generation program will create a '.pgp' folder in your home directory and populate it with your new key pair. This consists of two files 'pubring.pkr', and 'secring.skr'. You can generate an ASCII version of your public key that you can send to your friends by issuing the following command: 'pgpk -xa userid >pub_pgp.asc'

The 'userid' field needs to be replaced with the id you used when generating your key earlier. The key will be in the pub_pgp.asc file that you may now send your friends in an email. If you have forgotten (silly you) the userid you used you can list the contents of your 'key ring' that stores all keys you have by typing: 'pgpk -l'

When your friends generate their keys they can send their ASCII key file to you in a similar way. After you save this file you can add the key (public key remember) to your key ring to use later. Do this by typing: 'pgpk -a filename'

That is the basics of key management. You may also want to send a copy of your public key to a 'key server'. This is like a telephone directory where anyone who wants to can obtain your public key to send you secure email. See the PGP site for the address of key servers.

The keys you generate can then be used to encrypt/decrypt, sign/verify practically anything on your machine with the pgpe, pgpv, and pgps binaries.

I might just comment on that 'signing' program pgps. This is another one of the advantages of public key systems. If you cast your mind back to the discussion above about the red and green keys and how they worked in a complementary fashion it may occur to you that locking something with the red key would make it unable to opened with anything but your green key. Now everyone has access to your green key and therefore it may be opened by anyone. What is the use of that you may say. Well, you must remember that these key pairs are actually numbers and there are infinitely many of those. The chances of two users having the same key pair are next to non-existent. Therefore the opening up of an object by the green key you have given to everyone is a way of proving that you locked it in the first place (remember, only you have the red key). This is equivalent to 'signing' an object.

PGP uses a 'hash' function to implement this feature. The simple way of thinking of it is thus: When you 'sign' an email (or other file), PGP in effect uses your private 'red' key to generate a small encrypted signature that it adds to the file. The signature created is unique to the thing being signed (otherwise it could be forged) and depends upon the contents. This is achieved by running the hash function on the file and then using the private key to encrypt this hash value. Now when you transmit such a 'signed' message, a person can verify that firstly the signature came from you (by virtue of your green key being able to decrypt the signature portion and) thus obtaining the original hash function value your PGP generated, and secondly the contents are unaltered by re-running the hash function on the contents and comparing the hash values it now has. If everything is OK, PGP will say that everything checks out. If the message is altered or corrupted the signature will not check out against the added encrypted hash value in the signature component. Neat huh?

I hope that having got this far you are now seeing PGP as a useful tool with many benefits for the user. What will clinch the deal in most instances is a way of making the whole process of encryption, decryption, and signing of email automatic. Fortunately for us, this is possible. There is a catch though, and it is really not a catch at all unless you are extremely tight on hard disk space. Because, the benefits of automation will come most easily if you use PINE as your email program. The latest version of PINE available on the -STABLE branch is v4.05. Like I've said in the article on mail setup PINE is just so much better than the other mail programs that unless you have a dire shortage of disk space I would suggest installing it.

Now that you have installed it (you did install it didn't you?) it needs to be configured to use PGP automatically. The PINE package will install some PGP scripts in your /usr/local/bin directory called 'pgpencrypt', 'pgpdecode', and 'pgpsign'. We will use these scripts in the next step.

Firstly start up PINE, and you will be at the main menu of the program. Hitting 'S' and then 'C' will bring you to the configuration options in PINE. Press the down arrow key to get down to near the end of the options. You will find an option named:

	'display filters = '
  

Make the highlighting cursor select this option and then press 'A'. This should make PINE ask you for a value to set this option. Type or select and paste the following value here:

	"-----BEGIN PGP" /usr/local/bin/pgpdecode
  

exactly like that and hit return. Then you will see below this option the:

	'sending filters = '
  

Again highlight this option and press 'A'. Type or paste the following value here:

	/usr/local/bin/pgpencrypt _RECIPIENTS_
  

Then hit return. The _RECIPIENTS_ is an internal keyword used by PINE. Entering this will make PINE give you the option when you are sending email, of encrypting. Note that this will occur only if PGP can find a user id in your key ring that matches the recipient. This should not be a problem if you do as PGP suggests and set your userid to resemble 'User <[email protected]>' formatting as it appears on the 'To:' header line. If you would like to also be given the option of signing outgoing email then with the 'sending filters' line highlighted type 'A' again and enter or paste the following:

	/usr/local/bin/pgpsign
  

and hit return. Now PINE will also offer you the option of signing as explained earlier. Note that you may encrypt and sign outgoing files giving the ultimate in security.

I have setup Procmail to send an auto reply to any email to me with the word 'pgpkey' in the 'Subject:' of the email. This will send an ASCII version of my public key to the person requesting it. Combined with using the PGP key servers around the world this allows anyone to send you secure email.

Congratulations, if you got this far, you have turned your insecure email habits into military grade encryption technology and it has not even taken all that long. It is probably also time that you read up on the other features of PGP (such as revoking a key pair when security is compromised or if you accidentally lose a key) in the excellent man pages and how you can build up a 'web of trust' amongst your email correspondents. One thing that I will stress in case it wasn't clear from the discussion above. Your private key is the lynch pin of the entire process. Your security depends upon the sanctity of your private key. Do not divulge it to anyone under any circumstances; and make a backup of it on a floppy or other removable media and store it in a safe place. Sensible precautions, that you ignore at your peril. Someone with your private key can read all your encrypted files/mail and also sign things thus masquerading as you. Don't be caught with your pants down...

  ======================================================================
  Copyright (c) 1999 by Oben O. Candemir <[email protected]>
  This may be used for fair non-commercial purposes without the consent
  of the author provided this copyright notice accompanies any usage of
  the material herein. The instructions here are provided AS IS; whilst
  all care has been taken in preparing them, no responsibility whatsoever
  is taken for any damage caused by following them properly or otherwise.
  ======================================================================
  

Return to Issue #2

Contact: <>
Last modified: $Date: 1999/06/26 05:24:31 $
Copyright � 2023, The FreeBSD 'zine
All rights reserved.