![[LinuxFocus Image]](../../common/images/border-short.jpg)
![[Navegation Bar]](../../common/images/Navegator-bar.gif){kind=small}
| News Archives Languages |
|
|
||
|
|
||
|
||
| This article is available in: English Castellano Deutsch Francais Nederlands Portugues Russian Turkce |
Abstract:
This article shows how PGP can be used with Linux.
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:
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.
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:
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.
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:
The first step is to create a directory for the sources:
mkdir pgpNext uncompress the archive file:
tar -C ./pgp -xzvf pgp263is.tar.gzNow change to the newly created directory:
cd pgpNext, uncompress the file pgp263ii.tar which contains the documentation and source code for the program. To do this execute:
tar -xvf pgp263ii.tarAt 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 linuxIf 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.
cd mkdir .pgpPaying 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 Language, the possibilities are:
Language = en (English) Language = es (Spanish) Language = ja (Japanese)There are other parameters in the file. To take advantage of this option you must copy the file language.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
pgp -kgOne 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]
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.
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.
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.
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]
pgp -e file identifierHere 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 marcosThis 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 marcosFor security reason we may want sometimes to delete the original. PGP can do this automatically with the option -w:
pgp -eaw exam.doc marcos
pgp -ea exam.doc marcos juan aliciaNotice that the option -a is also in there so that the output file is in ASCII format, appropriate for E-Mail.
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.docThis 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.docThis 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 angelIt 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.docThis command generates a new file exam.sig that contains only the signature.
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 fileThere is another possibility; using input and output pipes thanks to the option -f:
pgp -fs identifier < input_file > output_fileOne 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 examThat 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.
pgp -sta text_file identifier
To display the fingerprint of a key, use the command:
pgp -kvc identifier [ring]
+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 fileforce
This option forces any operation of overwriting a file or deleting a key.
pgp +force +kr marcosWithin 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 marcosAnother 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
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:
![[Photo of the Author]](../../common/images/transpix.gif){kind=small}
_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:
|
Webpages maintained by the LinuxFocus Editor team
© Angel Lopez, FDL LinuxFocus.org |
Translation information:
|
2002-10-28, generated by lfparser version 2.33