March 7, 2021
Hot Topics:

PGP and Email Security

  • By Joshua D. Drake
  • Send Email »
  • More Articles »

As you will see below, PGP uses a public key infrastructure.

>From the GPG Mini-HOWTO (Slightly edited):

A classic method for encryption will use one key for encryption. The sender encrypts the message or file with this key. In order to decrypt the encrypted file the receiver will need to have the key the file was encrypted with. In order to be secure, the key must have been given to the receiver in a way that others would not have had the opportunity to obtain the key. If somebody intercepts the key, this method of encryption is useless. The use of Public Keys can solve help solve this problem. The Public Keys concept has two keys. The first key is a Public Key that may be obtained by anyone. The second key is called the Private Key. This key is secret and cannot be proliferated. In theory, this key is only available to the owner. When the encryption system is well implemented, the secret key cannot be derived from the public key.


In other words, the private key is yours. Do not share your private key. The public key is the Internets'. You should share your public key with anyone you wish to receive email from. The functional usage of this would be something like this:

Suzy writes an email and then encrypts it with Toms Public Key. Tom will then receive the email. As the email was encrypted with his public key, he can now decrypt it using his private key. Again, do not share your private key.

It sounds very simple and actually it is. PGP, even in its crudest form, is not that difficult to use but it is usually an external application. That means that unlike S/MIME where the encryption is an essential part of the program and usage, this is as simple as click, encrypt and sign. PGP usually requires the usage of an external wrapper. That is not always the case, especially on the Open Source side of things.

The Public Key infrastructure has other limitations as well namely, the proliferation of keys. If you want to send somebody an encrypted email, what do you do if you do not have his or her public key? The popular solution is to use a public key server such as http://www.keyserver.net/en/. If you do not have a person's public key you can just search for it at a public key server. Of course the person must have submitted their key to the public key server, but if they are using PGP they most likely have. The PGP solution is currently the most used, and easily managed. If you are looking for a good solution that will not overly confuse everyone you are dealing with, PGP is a good solution.

If you would like to obtain a version of PGP I would suggest the following two web sites. The first is PGP.com (http://www.pgp.com). It is not an Open Source solution but for Windows or the Macintosh it is the best solution. PGP integrates seamlessly into both operating systems, allowing a great deal of flexibility in the usage of the program. You can even encrypt entire directory structures and/or personal files with a simple click of the mouse.

If you are an Open Source advocate like myself, or you run an operating system that PGP does not support, I suggest GnuPG (http://www.GnuPG.org). The source is freely available and it offers a plethora of resources on the installation and usage of the free implementation of the OpenPGP specification. For additional resources on GnuPG, I would take a look at: http://www.linuxdoc.org/HOWTO/Mutt-GnuPG-PGP-HOWTO.html . This document is a HOWTO on Mutt (a unix console email program or MUA), GnuPG and PGP.

As a closing thought, I would like to bring up the eventual population of IPv6 on the Internet. A lot of people have been talking about it, and some of the larger networks are currently testing and some even using it. The nice thing about IPv6 in regards to security is that every datagram, packet, or piece of data that is sent within a IPv6 stream is encrypted. This will greatly enhance the personal security of the individual and corporate Internet user, although it will not solve the plain text mail spool problem of the Sendmail MTA (Mail Transfer Agent).

Page 2 of 2

This article was originally published on January 11, 2001

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date