Pretty-Good-Privacy under Linux

Introduction
Public key Cryptography
PGP versions
Installation
Configuration
Making keys
Adding keys
Removing keys
Extracting keys
Ring Content
Encoding Messages
Extracting Messages
Signing Messages
Decoding Messages
Dealing with Text Files
Fingerprints
Shells
Integration with Mail Readers

Introduction

PGP stands for Pretty Good Privacy, making reference to one of the most popular cryptographic applications in the computer community.

PGP is the tool appropriate to ensure the privacy and authentication of information in insecure communication networks such as the Internet.

The privacy ensures that only the recipient of the information can make use of it. If this information were to make it in other hands, it would be totally useless because it could not be decoded.

The authentication ensures that certain information generated by person "A" effectively comes from "A" and has not being falsified or manipulated by anyone along the way.

PGP is based on a cryptographic system known as public key, which can be used through insecure channels. This makes it ideal for ensuring the privacy of information transmitted through networks such as the Internet.

It is not necessary to be involved in a thick industrial spy plot :) in order to be interested in the privacy of your communications and therefore having the need of a tool for cryptography. Something as simple as E-mail can be a perfect reason for beginning to use PGP. Let's look at why:

We can compare E-Mail to a postcards. Anyone who puts his hands on it can read it because there is no physical obstacle to prevent it. On the other hand, a letter inside an envelope is more private. People can handle the envelop but cannot read the letter. If they want to read it they must break the envelop.

We could make an analogy between our envelops and PGP, which acts as the support for our E-Mail. PGP does not allow anybody except the legitimate recipient to read it the message; this is one of the many advantages of using PGP.

How Public Key Cryptography Works

In systems with a public key, every person has two keys that are complementary; one is the public key and the other is the private key.

The public key can and must be divulged freely, since it will be with that key that the rest of the world will be able to send information to you privately. However, the public key one does not endangered the privacy of the private key.

Let us consider the case of two friends, Juan and Pedro. Juan will be able to send information to Pedro privately if he knows Pedro's public key. On the other hand Pedro, using his own private key, will be able to decode the message Juan just sent. Let us suppose there is another person, Marcos, who intercepts the message that Juan has sent to Pedro. Marcos will not be able to do anything with the message because he does not have the private key of Pedro. Even Juan himself, the sender and creator of the message, is unable to decode it, only Pedro can, with the private key.

The security of a system is based on every user storing their private key safely, even while the public key is widely known. If someone would try to break the system, not knowing the private key of the recipient, it would take so many years that it would be useless.

As mentioned before in the introduction, besides the privacy, PGP also offers the possibility of authenticating the information. Let's see why:

Our private key not only encodes messages but it can also "sign" the information sent; quite analogous to the signatures often added to paper documents.

A document digitally signed without a private key can be authenticated by anyone having a public key. This authentication provides a means to check that the document effectively originated with the person it claims it comes from and that it has not been altered or falsified.

Both processes, encoding and signing, can be performed to offer privacy and authentication. First the document is signed with our private key and then it is encoded using the public key of the recipient.

When the recipient gets the message he inverts the steps, first decoding the document with his private key and then checking our signature with our public key.

All these processes can be automated as we will see later on.

A public key is stored in what is known as a key certificate , this is simply the public key itself together with the name of the owner and the date when it was generated.

The private key is protected with a password that forbids its usage by unauthorized persons.

Both keys are stored together in a file known as key ring which stores also various key certificates. Normally there is a ring for public keys and another one for private ones.

The keys are internally reference by a key ID which is made up of the last 64 bits of the key. When displaying information about the key, what actually gets shown are the last 32 bits of the key. These key IDs will be used by PGP, for example, to locate a key at the moment of decoding a message.

When signing a document, PGP generates 128 bits that represent the document. This signature is a sort of checksum or CRC that enables it to detect changes in the document. In contrast to usual CRC or checksum, no impostor can regenerate this signature to legitimize any changes made to the original document. The signature is made using the private key of the sender and the impostor normally will not have access to it.

PGP Versions

Now that you know what PGP is useful for, you will surely want to start using it right away.

At this point it must be emphasized that there is considerable confusion surrounding the various versions of PGP. Due to the politics existing in the United States with regards to the export of cryptographic material, several versions of PGP have emerged, along with several laws regarding their use. In order to make as clear as possible all this mess I will enumerate the various versions available for PGP to date.
Freeware PGP Versions:

PGP 2.3a

This is the "classic" PGP. It can still be used although it may experience incompatibility problems while processing keys and messages generated with versions 2.6.x and later or when using keys bigger than 1280 bits. Supposedly PGP 2.3a can not be used outside the United State due to restrictions in the patent.

PGP 2.6ui

This is the non-official version of PGP 2.3a that corrects for the incompatibility problems previously mentioned. This version is not a version 2.6.x because it is based on the sources for 2.3a

PGP 2.62ui

It is based on the sources for 2.6ui, is a modification that attempts to be compatible with the latest innovations introduce in versions 2.6.x.

MIT PGP 2.6.2

This is the last official version of PGP. Its messages can be read by versions previous to 2.5 and it uses the RSAREF encoding library. It is illegal to export this version outside the United States but curiously, once exported can be used freely.

PGP 2.6.3i

Based on the sources for MIT PGP 2.6.2 which have been modified for its international use. One of the changes introduced is the removal of the RSAREF encoding library mentioned above. The use of this version in the United States is illegal.

PGP 5.0

PGP 5.0 (previously known as PGP 3.0) is a completely new version of PGP. Its sources have been written from scratch. It adds new options, including support for other cryptographic algorithms besides RSA and IDEA. It will include a GUI interface to simplify its use. This version will be available mid summer.

Commercial PGP Versions (only for the USA and Canada):

ViaCrypt PGP 2.7.1 y 4.0

Being commercial includes manual and individual usage license. It does not include the sources.

PGP 4.5 y 5.0

In June 1996 PGP Inc. buys ViaCrypt and starts developing commercial versions of PGP for the United States and Canada. The most recent version is PGPMail 4.5.

In our case, if we are outside of the USA, the correct version to use would be 2.6.3i, if in the USA we must opt for 2.6.2 or 2.6.3.

It must be taken into account that in some countries like France, Iran, Iraq, Russia and China the use of cryptography is regulated or prohibited.

Some interesting links to get version 2.6.3i for various Linux distributions:

Binaries ELF:

tonelli.sns.it/pub/Linux/pgp/pgp263.is.bin.tgz

Binaries and Sources for Red Hat:

ftp.replay.com/pub/replay/ub/redhat/i386/pgp-2.6.3i-1.i386.rpm

ftp.replay.com/pub/replay/ub/redhat/SRPMS/pgp-2.6.3i-1.src.rpm

Sources:

ftp.dit.upm.es/mirror/ftp.ifi.uio.no/pub/pgp/src/pgp263is.tar.gz

Installation of PGP

Let say you have gotten PGP. Supposed you downloaded the sources for version 2.6.3i and that on your hard disk now is a file called pgp263is.tar.gz

The first step is to create a directory for the sources:

mkdir pgp

Next uncompress the archive file:

tar -C ./pgp -xzvf pgp263is.tar.gz

Now change to the newly created directory:

cd pgp

Next, uncompress the file pgp263ii.tar which contains the documentation and source code for the program. To do this execute:

tar -xvf pgp263ii.tar

At this point you are ready to compile PGP. If you did not download the sources, but a compiled version (either a.out or ELF), you can omit this step. If you have the sources ready, the compilation can be performed issuing the following commands:

cd src
make linux

If everything goes well the makefile would have created an pgp executable. In the case of a global installation you can copy it to /usr/local/bin, /usr/bin wherever you find best. Otherwise you can leave it in your personal directory.

Similarly, one can copy the manual page pgp.1 to /usr/man/man1 in case of a system wide installation.

Basic Configuration

By default PGP uses the directory ~/.pgp to find the key rings and some configuration files, so as a first step let us make this directory in our HOME:

cd
mkdir .pgp

Paying attention to the distribution files you will find a file named config.txt that serves the purpose of configuring some aspects of PGP. In order to have a personalized configuration you must copy this file to your recently created ~/.pgp

Optionally, instead of ~/.pgp/config.txt you can rename it .pgprc and save it in your home directory, that is ~/.pgprc

Among other things, this file can specify the language to use through the parameter Languaje, the possibilities are:

Languaje = en (English)
Languaje = es (Spanish)
Languaje = ja (Japanese)

There are other parameters in the file. To take advantage of this option you must copy the file languaje.txt to ~/.pgp

Another recommended step, is to copy the personalized help file for your language to ~/.pgp. In the case of spanish speaking users one would copy the file es.hlp

Creating the Pair of Keys

To begin using PGP one has to create his or her own pair of keys (Public/Private). To this end execute the command:

pgp -kg

One will be asked to choose the maximum size of the key (512, 768 or 1024 bytes), the bigger the key more security will be obtained at the expense of a small speed penalty.

After selecting the size of the key, you will be asked to type the identifier to be given to the public key. People usually write their names here, or their E-Mail address. In my case I have written:

Angel Lopez Gonzalez <[email protected]>

Next comes the password to protect your private key. Choose a phrase that is easy for you to remember. This is necessary to protect the private key, so that if some one steals it, it will not be usable without the password.

Finally the program asks to randomly touch multiple times keys on your keyboard in order to generate a sequence of random numbers. The program will based the sequence of bits on the interval taken between strokes on the keyboard.

PGP will generate the keys after a few seconds and will notify you with a message. After proper generation of the keys they should be saved in the directory ~/.pgp as the following files: pubring.pgp and secring.pgp

The first one, pubring.pgp, is the ring with the public keys. At the moment it contains only our key.

The second, secring.pgp is, as you can imagine, the ring of private keys which only contains at the moment your own private key.

It should be remembered that all the security of the public key methods is based on the secrecy of the private key; therefore, be sure to keep it in a save place and that no one can access it from the ring of private keys. Check the permissions of secring.pgp and make sure that only you have access to read and write, with the rest of people no access at all.

Finally it should be mentioned that both the identification of the keys and the passwords for the private keys can be edited and modified using the command:

pgp -ke identifier [ring]

Adding keys to a Ring

At this moment you probably want to start adding your friends public keys to your ring. For this you must have somehow gotten the keys from: a key server; directly from the person in question; using finger on the account of the person; via E-Mail, etc. . Let us remember that the public key can be distributed freely and there is no need to transmit it through a secure channel, as is the case for cryptology methods based on a single key.

If the file Somekey.pgp contains a key and you would like to add it to one of your rings the procedure is quite simple, execute:

pgp -ka Somekey [ring]

By default the termination .pgp indicates a file with a key, and the names pubring.pgp and secring.pgp are assigned to the files containing the rings of public and private keys respectively.

When a key is added, PGP could notify you that the key being added is not completely certified; what means that the key in hand may authentically belong to its claimed owner or not.

If there is "certainty" that the key truly belongs to its claimed owner, either because he or she gave it to us in person or via a secure channel, then it can be certified by the user him or herself. This implies that we are putting our signature on that key as a prove of certification.

This facilitates passing our key to a person that trusts us and who has the complete certainty that we are passing him a good and authentic key.

There is even a name for this process, a web trust. in the United States there are even gatherings of PGP users where they interchange public keys and sign them :)

Let us consider an example with name to make clear this concept. Consider again two friends, Juan and Pedro. Juan gives his public key to Pedro. Pedro is sure that the key Juan has given to him is correct since there is trust between them. When he arrives home and adds it to his ring of public keys he can then certified that the key truly belongs to Juan, so he signs it with his own private key.

Now two more people enter the scene: Luis and Maria. Luis receives from Pedro, Juan's key and later on Luis sends it to Maria. Maria does not trust Luis but she sees that Juan's key comes with Pedro's certification. Maria can check the public key of Juan thanks to Pedro's signature. She has Pedro's public key because he gave it to her in person, so now she can trust the veracity of Luis' key by checking the authenticity of Pedro's signature. Here we see how Maria can now use and trust the key given to her by an untrustworthy character like Luis.

It is messy :) but necessary in order to protect against the only weak point of this type of cryptography: the fact that the public keys could be falsified.

Removing Keys from a Ring

Continuing with our small guide to PGP, the next step after knowing how to add keys to a ring is finding out how to remove them. This can be done with this command:

pgp -kr identifier [ring]

For example: "pgp -kr juan " will removed any key having "juan" somewhere in the identifier. By default, the key ring inspected is the public key ring.

Extracting a Key

After saving some keys from friends in our public ring let us send them our public key. First it must be extracted from the ring:

pgp -kx identifier file [ring]

For example: "pgp -kx angel mykey" extract the public key identified by the substring "angel" to the file mykey.pgp

The file generated mykey.pgp is not in ASCII format (try using cat to see it). However, if one wishes to get an ASCII formatted key file to send by E-Mail, for example, or to add it as additional information to a finger database, one would type:

pgp -kxa identifies file [ring]

For example: "pgp -kxa angel mykey" extracts the public key identified by he substring "angel" to the file "mykey.asc".

Together with the key are also extracted all the certifications that endorse it.

Content of a Ring

To display the keys contained in a ring, type the command:

pgp -kv [identifier] [ring]

Once again the default ring is pubring.pgp, the public ring. If no identifier is explicitly given, all the keys in the ring are displayed.

In order to see all the certificates for every key, use:

pgp -kvv [identifier] [ring]

Encoding a Message

We have seen how to use the keys, let us now use it for something interesting. Let's look at how to encode a file:

pgp -e file identifier

Here is an example: A teacher wants to send to his college an exam by E-Mail, and he wants to encode it so that no student can intercept it :). Say the second teacher's name is Marcos and the identifier of his public key contains his name. The our first teacher will type:

pgp -e exam.doc marcos

This command generates a file with the name exam.pgp that contains the file exam.doc encoded in a way that only Marcos can decode it with his private key.

Remember that the file generated, exam.pgp, is not an ASCII file, therefore for E-Mail purposes it may be better to add one more option -a, so that the output encoded file is in ASCII format, like this:

pgp -ea exam.doc marcos

For security reason we may want sometimes to delete the original. PGP can do this automatically with the option -w:

pgp -eaw exam.doc marcos

Encoding a Message for Several Recipients

Imagine now that our teacher wants to send the exam to his department colleagues. To do this, he only has to type several identifiers instead of one:

pgp -ea exam.doc marcos juan alicia

Notice that the option -a is also in there so that the output file is in ASCII format, appropriate for E-Mail.

How to Sign a Message

As mentioned before, the digital signature in a message is the analog of a common signature on paper. Signing a document will allow the recipient to verify that the message has not been altered and that its authentic.

To sign a document it is necessary to use our private key:

pgp -s file [-u identifier]

If we have several private keys in our secring.pgp we can select one among them by using an identifier.

When our teacher in the example decides to sign the exam so that his colleagues know the message did not come from a funny student :) he types the following:

pgp -s exam.doc

This command generates a file named exam.doc.pgp which is not in ASCII form because PGP attempts to compress the file. If on the other hand, it you wish to sign a document, leaving the text readable with your signature at the end, then the procedure would be:

pgp -sta exam.doc

This last command is very useful to sign electronic mail that is still readable by those without PGP or by those not wishing to check the signature.

It is also possible to sign a document and then encode it using the following command:

pgp -es file recipient_identifier
[-u my_identifier]

For example:

pgp -es exam.doc marcos -u angel

It encodes and signs the file exam.doc, generating the file exam.pgp. The public key used to encode the file is that identified by the string "marcos" so only the owner of this key can decode it. Then I identify my private key with the string "angel" because in my ring I have several keys.

Even in this case an ASCII file could be generated using the option -a.

Another possibility of interest would be to generate a signature for a file separate from the data. To achieve this, use the -b option:

pgp -sb exam.doc

This command generates a new file exam.sig that contains only the signature.

Decoding

To decode a file and/or check the signature in it, use the command:

pgp input_file [-o output_file]

By default it is assumed that the input_file has the termination .pgp. The output_file is only optional and will contain the decoded file. If no output file is specified, the decoded file is saved into the input_file with the .pgp extension removed.

However, after decoding a file we can also specify the standard output for the decoded file. This is achieved using the -m option:

pgp -m file

There is another possibility; using input and output pipes thanks to the option -f:

pgp -fs identifier < input_file >
output_file

One more interesting scenario is that we wish to decode a signed message someone sent us but we would like to keep the signature because we are interested in encoding it again to send it to a third party. To do this, use the option -d:

pgp -d exam

That would take the file exam.pgp and decode it but leave the original signature in the file. Now one can proceed to encode it with the public key of a third person who, upon receipt, could check the authenticity of the original message.

Dealing with Text Files

Frequently, PGP is used to encode electronic mail, which more often than not, is text. A problem with text files is that they are represented differently in different machines; for example, under MSDOS all the lines end in carriage returns and line feeds; under Linux only line feeds, while in Macintosh, only carriage returns...etc. To avoid problems of platform incompatibilities we can tell PGP that we wish to encode a text file rather than a binary file so that when decompressing, it can adapt it to the peculiarities of the target environment. To encode a text file for E-Mail with this option, use -t. For example:

pgp -sta text_file identifier

"Fingerprints"

A fingerprint is a sequence of 16 bytes that identify a key uniquely. One can check having the correct key of a person by testing these 16 bytes instead of checking all 1024 bytes a key may have, one-by-one.

To display the fingerprint of a key, use the command:

pgp -kvc identifier [ring]

Using PGP in Shells

PGP has options that are especially useful when using PGP from shells in automated scripts.

+batchmode

With this option PGP will not ask anything not strictly necessary. Use this option to check a signature automatically. When the file has no signature the error code returned is 1; if the file has a signature and it was correct it returns 0.

pgp +batchmode file

force

This option forces any operation of overwriting a file or deleting a key.

pgp +force +kr marcos

Within a shell it is useful to avoid PGP asking for passwords when encoding a file. For instance, to avoid being asked interactively during the encoding when we can simply bypass it with the environment variable PGPPASS.

Here is an example:

PGPPASS="password"
export PGPPASS
pgp -s file.txt marcos

Another way of passing the password to PGP in a non-iterative way is using the option -z

As in here:

pgp -sta exams.txt angel -z "password"

Another useful operation under the shell is to make PGP run in a verbose mode using +verbose. This establishes a quiet mode -- that is no informative messages, only errors:

pgp file.pgp +verbose=0

Integration with Mail Readers

Integrating PGP with mail readers to encode, decode and sign mail automatically, is simple, while hardly dependent on the mail reader used.

As an example, I will discuss the integration of PGP with Pine. Hopefully this is the mail reader used by the reader.

Although I will describe working with PGP for Pine, the principles behind these steps can be applied to other readers as well. The configuration options will, of course, be different for different mail programs.

In order to decode mail automatically before reading it, one needs a filter that processes the message in order to display it to the screen. Another possibility would be to write a macro that combines decoding and displaying to the window.

In the case of Pine there is an option for defining filters that are executed before visualizing a message. The option is called 'display-filters' and is found in Pine's configuration menu. In this option we add a new filter that looks like this:

_BEGINNING("-----BEGIN PGP MESSAGE-----")
_ /usr/local/bin/pgp

Every PGP encoded message is enclosed between two specific line-bars which are "-----BEGIN PGP MESSAGE-----" and "-----END PGP MESSAGE-----" so that if you want to know if a message has encoded text in its body, it is sufficient to search for one of the two lines above. The filter defined in Pine does exactly this. Before displaying the actual message, it inspects the body and searches for the string "-----BEGIN PGP MESSAGE-----" with the restriction that it must appear at the beginning of any line. If it finds it, then it executes the program: /usr/local/bin/pgp

Then, if there is, in fact, an encoded message in he body PGP gets executed. It will ask you for the password and then you can read the message. If you wish to automate this process even more, by saving the time required to type your password each time, then you can define the environment variable PGPPASS or use the option -z as described above.

Now we only have to define a filter that will encode our messages with the public keys of the recipients available in our public ring before the message is actually sent. Pine again helps us, with the configuration option 'sending-filters.' Here is the filter to include for this option:

/usr/local/bin/pgp -etaf _RECIPIENTS_

After writing the message and typing CTRL-X to send it, Pine will ask if you want to send it directly without going through any of the filters defined. To send the message decoded, simply indicate affirmatively, but if you want to send the message encoded, then we push CTRL-N or CTRL-P which takes you through a list of all the defined filters. In our case, this will just be the PGP filter written above.

This is a very simple and basic setup which allows you to use PGP under Pine, using only two filters. To obtain more information on how to integrate PGP further, with Pine and other systems, consult these links:

elm | GNU Emacs | tin | mailx | MH | Pine | sendmail | vi | zmail

For more information:

Read the PGP documentation.
Read other articles by the same author: Managing your Mail with Procmail.