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:
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
|