Open SourcePGP and Email Security

PGP and Email Security content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

If you are a subscriber to the OpenSourceIT technology newsletter, you saw a small introduction from me a couple of weeks ago on how to secure your files and email using industry standard encryption. I mentioned two specific programs, PGP and GnuPG. In the following article we will discuss these two technologies and some other options available to the end user.

Every person, at some point in their life, worries about their security. It may be when they are walking to their car late at night, or as an afterthought when they leave their house unlocked. There are many people who do something every day that is inherently insecure and is easier to snoop or steal than a car- they send email in plain text.

Usually email is harmless. It is casual conversation about the days events or negotiations about a possible contract. Email is not thought of as a business communications tool until it breaks. There are many people on the Internet that, to this day, continue to send passwords, credit card information, personal information such as addresses and anything else you can think of over plain text email. The reality of the dangers that exist within email are not apparent to them. Even with the multiple cracks exposed with major e-commerce sites such as Egghead, too few people consider email potentially dangerous.

There are ways to make email secure. The problem is that it requires that the server and the client support the technology. It usually requires that the person you are sending email to supports it as well. A long available technology is an S/MIME certificate. This technology is similar to the secure web sites that you access. It requires an external party to authenticate the certificate that a file was sent with. As an example:

Suzy writes an email to Tom and signs it with her certificate. If Tom already has Suzys public key, and if Toms email client supports S/MIME, it will check the signature of the certificate and contact the signing authority to check for authenticity. If Tom does not have Suzys public key, Tom’s email client can extract the email as the public key is sent with each encrypted email.

This is a very cumbersome process as it requires that the people using the email have the same capabilities. It can also be expensive because commercial use of S/MIME for email signing usually costs money. You have to pay a subscription to have a signed key from an authority. The certificate authority Thawte will allow people free personal certificates.

There is a suite of technology applications currently available but not widely used that help ease the above burden. They are S/SMTP, S/POP, and S/IMAP. Using these technologies is just as simple as using your web browser to go to a secure web site. S/SMTP is the use of SSL or TLS (Transport Layer Security) to encrypt the SMTP transfer of email. SMTP is the protocol that is used to send email. S/POP and S/IMAP is the use of SSL or TLS to encrypt the transfer incoming email. Although most commercial email applications support this capability, it has its own implementation issues. In order for any of these technologies to be effective, every mail server on the Internet must be upgraded to support them. That is a huge, time consuming prospect, but it would be easier to implement a server wide upgrade over two years than to enforce rules on security to an end user. It also does not address the issue that most email stored on the Internet is stored in plain text. That’s right, if you do not encrypt your email or even if you use the S/ suite of protocols you still run the risk of system compromise. If the server uses Sendmail, which the majority of the Internet does, the email is stored in plain text within a message spool.

As you can see, email security is a simple question to ask but a very difficult question to answer. A security technology that has been around for several years is PGP and it has a correlating standard called OpenPGP (RFC 2440). PGP first appeared on the Internet in 1991 and has enjoyed a great amount of success. It is not difficult to use, has free implementations, and is a defacto standard for file and email encryption. It too suffers from its own share of positives and negatives.

On the plus side, PGP is widely in use. The famed Gnu project has created its own version called GnuPG.. It works on normal files and email and operates on most platforms. The negative is nominal but can still present issues when using the products.

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 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 ( 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 ( 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: . 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).

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories