Main Page | See live article | Alphabetical index

Pretty Good Privacy

PGP (Pretty Good Privacy) is a cryptographic system (implemented as a computer program) originally designed and developed by Phil Zimmermann which provides high quality cryptographic privacy and authentication. It, in any of several variants, is the most widely used high quality crypto system in the world. Those wishing to avoid the problems and hype associated with much of the crypto software available have been well advised to use PGP. It is, properly used, quite seriously good cryptography, not merely "pretty good". The name, on the other hand, is a bit of a joke. Garrison Keillor's Lake Wobegon had a grocery store. Like most things Wobegonian, it was a little different. Among its oddities was the name, Ralph's Pretty Good Grocery. Zimmerman's playful side came out to play, and Pretty Good Privacy was the result.

PGP's design was (and remains) excellent and sufficiently influential that it has been made an IETF Internet standard (OpenPGP). Versions of PGP more recent than the standard are, more or less, compliant or compatible with it. PGP uses both public-key cryptography and symmetric key cryptography, and up to a point, a PKI with some similarity (but many differences) with the X.509 certificate standard.

When used properly, PGP is capable of very high security; most informed observers believe that even government agencies such as the NSA are incapable of cryptographically breaking properly produced PGP messages. But, like _all_ cryptography, misunderstanding and confusion are common, implementation errors are not unknown, and improperly used PGP can be (and will likely be) no more secure than messages produced by other, poorly designed / implemented / used, crypto systems. Failure to learn and understand how to use PGP can result in not achieving its excellent security potential. In most respects, this involves reading and following the user documentation. PGP is easier to use than many crypto systems, but neither it, nor any other, is foolproof.

PGP is most commonly used for e-mail, which had no built-in security as originally implemented (the SMIME attachement standard finally included confidentiality much later, but there were and remain concerns about the quality of protection specified). Plug-ins implementing PGP functionality are available for many popular e-mail applications (such as Microsoft's Outlook and Outlook Express programs, as well as Eudora, Evolution, Mutt, and many others). Several are included with many PGP distributions. Note that, from the viewpoint of security, each such plug-in is independent of PGP itself; each might have implementation errors, and not necessarily those which may have already been noticed in PGP. Using such plug-ins do not necessarily provide the same level of security as would independent (and correct) use of PGP itself. At best, one can be equivalent; at worst, a plug-in may reduce your security to nothing. Distinguishing amongst these cases is non-trivial even for the most cryptographically skilled and informed. The best advice for the ordinary user is to use PGP on its own and to send the already protected file manually (eg, as an attachement).

How PGP works

PGP uses asymmetric key encryption, in which the recipient of a message has previously generated a linked key pair; a public key and a private key. The recipient's public key is used by a sender to encrypt a shared key (aka a secret or conventional key) for a symmetric cypher algorithm; that key is then used to encrypt a message. Many PGP users' public keys are available to all on the many PGP key servers around the world which act as mirror sites for each other. The recipient of a PGP protected message deciphers it using the session key for a symmetric algorithm. That session key was, of course, included in the message in encrypted form and was itself decrypted using the receipient's private key. Use of two cyphers is sensible due to the very considerable difference in operating speed between asymmetric key and symmetric key cyphers (the latter of which are much faster).

A similar strategy is (optionally) used to detect whether a message has been altered since it was completed (eg, during transmission), or (also optionally) whether it was actually sent by the person/entity claimed to be the sender. To do both at once, the sender uses PGP to 'sign' the message (this originally used the RSA asymmetric key algorithm, but more recent versions of PGP have added other asymmetric algorithms and signature protocols). To do so, PGP computes a message digest from the message, and then encyphers it using the sender's private key. The message recipient uses the sender's public key to decipher the hash value and then compares it to the hash value computed from the decrypted message at the recipient's end. If both hashes are identical, it is certain (at least to a very high degree of confidence) that the message was not tampered with (either deliberately or accidentally) since it was encrypted. It is also certain (to that same high degree of confidence) that the sender must have had access to the private key matching the public key used to decipher it, else the message digest wouldn't have been decipherable at all. If that private key has not become known to anyone else, the sender must have been the person/entity who originally generated the key pair; that is, the key's "owner". If that private key has become known to someone else, _anyone_ using that key can produce messages which will successfully pass PGP's signature authentication tests. This is true for _all_ crypto systems using asymmetric key algorithms, however. PGP is not in any sense specially vulnerable.

Both in encrypting messages and in verifying signatures, it is critical that the public key one uses to send messages to some person / entity actually does 'belong' to the intended receipient. Simply downloading a public key from somewhere is not overwhelming assurance of that association; deliberate or accidental spoofing is always possible. PGP includes provisions for distributing users' public keys in 'identity certificates' which are so constructed that any tampering (or garble) is readily detectable. But merely making a certificate virtually impossible to modify is also insufficient to ensure against malicious tampering. It prevents corruption _after_ the certificate is created, but not before. Users must also verify by some other means (for example, by meeting in person to exchange certificates) that the public key in a certificate actually does belong to the person/entity claiming it. PGP includes an internal certificate 'vetting scheme' to assist with this; it has been called a web of trust.

This obligatory care and caution about accepting a public key as correctly belonging to some other user is not unique to PGP. _All_ public key / private key crypto systems have the same problem, and no fully satisfactory solution is known. PGP's scheme, at least, leaves the decision whether or not to use the endorsement system to the user, while most other PKI schemes do not.

Early history

The first version of PGP released by Zimmermann found its way onto the Internet. No license was required, there was not even a nominal charge, and the complete source code was included. Shortly after that release, PGP found its way outside the US, and Zimmerman not long thereafter became the target of a multi-year criminal investigation by the US Government for munitions export without approval. Crypto systems using 'large' keys (that is, larger than some specified size, then 40-bits) were considered as munitions within the scope of US regulation; PGP used long enough keys that its export violated those regulations. The definition of 'large' in this context changed substantially ca 2000. Penalities for violation, if found guilty, were substantial. The investigation was eventually closed with no charges brought against Zimmerman; prosecutors seem to have decided that they could not prove that Zimmerman had exported, or helped export, PGP. But in the meantime, PGP had acquired a considerable following around the world. Users, and supporters, included dissidents in totalitarian countries (some affecting letters to Zimmerman have been published), civil libertarians in other parts of the world (see Zimmerman's published testimony from various hearings), and the 'free communications' activists who called themselves cypherpunks. These last provided both publicity and distribution (see assorted manifestos from these folks).

After the success of the original PGP release, independent and (more or less) interoperable implementations of the PGP crypto system design were developed. Patent restrictions meant that US PGP versions operated under different legal rules than non US versions. Specifically, the RSA algorithm was patented only in the US and the IDEA was patented internationally though non-commercial use was permittted. In addition, the US government prohibited export of crypto systems of PGP's high quality. All this produced forkss in the original PGP software. Stale Schumacher in Norway supervised development of the most important independent PGP version, which eventually came to be called PGPi (the 'i' standing for international). Having been developed, maintained, and distributed outside the USA, PGPi was not subject to US export controls nor to the US patent on the RSA algorithm. After the US export laws were relaxed in early 2000, and especially after the RSA patent expired in Sept 2000, PGP versions have -- mostly -- reconverged back to one 'genetic line'.

New developments: OpenPGP and new PGP-like programs

Because of PGP's importance worldwide, an open source standard for 'PGP' was proposed, implemented and released (called OpenPGP). It has become an Internet standard: OpenPGP, RFC 2440. It is nearly compatible with late versions of PGP; additional protocols and algorithms and new data formats prevent complete compatibility. In addition, the Free Software Foundation developed its own, also somewhat compatible, version of PGP called GNU Privacy Guard (GPG). GPG was meant to comply with the OpenPGP standard and the most recent version does. It is freely available along with all source code under the GNU General Public License (GPL). Development was/is supported with funding from the German government.

PGP goes commercial

After the criminal investigation was dropped in 1996, Zimmerman and some associates founded PGP, Inc. to further develop PGP. It funded itself by selling a commercial version of the software, though the source code remained available and was supported. PGP, Inc. was acquired by Network Associates, Inc. in 1998 and Phil Zimmermann became a NAI employee. NAI produced several variants and 'brand extensions' of PGP for assorted markets; only some of them continued to be available with source code, or in versions without cost. In early 2001, Zimmerman left NAI. In August 2002, NAI sold the rights to all versions of PGP -- except the command line version -- to a new company, PGP Corporation. Zimmerman now serves as special advisor and consultant to PGP Corp.

Because PGP Corp. is prevented by its arrangement with NAI from offering a command line version of PGP for some time to come, Zimmerman has cooperated with a Danish company, Veridis, to produce such a version. It's called Filecrypt, since the PGP name is controlled by PGP Corp and NAI. The story can be found at Zimmerman's Web site. Filecrypt, the base version of PGP from PGP Corp, and of course GPG, all continue to be available in source code.

Compatibility amongst PGP versions

Because of the RSA patent in the US, versions of PGP after v2.3 were deliberately made incompatible with earlier versions. Since the problem didn't exist outside the US, PGPi (and some other variants now lost in time) maintained compatibility with both early and later versions of PGP v2.x. MIT had complex relationships with the RSA patent licensee (RSA Data Security) and was able to make arrangements to serve as an Internet distribution point for 'patent licensor acceptable' open source versions of PGP to residents of the US and Canada, and only to them. Elsewhere, others distributed various versions, with Stale's site ( eventually becoming first among many.

PGP Inc added several new algorithms, and a new data format or two, at PGP v5.0, just before it was acquired by NAI. NAI continued development while it controlled the software, adding and changing various aspects of PGP , and PGPi more or less kept pace on a delayed basis. NAI released some PGP variants without the RSA algorithm, charging less than for the RSA licensed versions. Thus, some NAI PGP releases were compatible with earlier versions of PGP using RSA, and some are not. The situation became rather confused.

When the OpenPGP standard was adopted, it also included differences from existing and older PGP versions, though there remained considerable 'backward' interoperability. Some of this was due to longstanding IETF reluctance to specify commercially controlled algorithms (eg, RSA and IDEA) in its standards. The Free Software Foundation's GnuPrivacyGuard (GPG) project is committed to implementing the OpenPGP standard and in its newest version claims to have done. The MIT distribution site has not entirely kept up with new versions of PGP. At last look, it was several versions behind.

Filecrypt is said to be fully compatible with current versions of PGP from PGP Corp.

See the Frequently Asked Questions pages at for more details on compatibility questions. PGP compatibility intricacies are an excellent example of the damage commercial amibition without perspective, onerous patent licensing without good sense, and clueless government regulation can do to useful software designs.

At present, it may perhaps be best to use a recent version of PGP from PGP Corp, or Veridis, or the most recent version of GPG. Compatibility problems will be reduced if not entirely eliminated by doing so; all are more (or less) backward compatible with assorted earlier versions of PGP from various sources. This will, unfortunately, require users to be somewhat aware of the compatibilty status of their correspondents. For instance, "Bob is using a current version of PGP, so I can tell my software to use any currently supported algorithm". "But Alice is still using PGP 2.6, and so she can't use anything other than RSA and IDEA, and I must use 2.6 compatible certificates". PGP has acquired version compatibility issues, just like much other successful software. Unlike most others, there remains substantial interoperability. In short, there's hope for the ordinary user.

External links and references

PGP is also a song by Psykosonik.