Pretty Good Privacy (PGP) is a computer program which provides cryptographic privacy and authentication. PGP was originally designed and developed by Phil Zimmermann in 1991.

PGP has been sufficiently influential that its algorithms and data formats have been standardised for interoperability between different pieces of software. Eventually, the PGP design was made an Internet standards-track specification known as OpenPGP. OpenPGP is now an open standard used by PGP, GNU Privacy Guard (GnuPG), Hushmail, Veridis, Authora, and others.

PGP and email

While PGP can encrypt any data or files, it is most commonly used for e-mail which has no built-in security as originally implemented. PGP and S/MIME are the two (incompatible) email security systems which are currently NIST specified standards.

PGP was traditionally integrated with email by adding special formatting (ASCII armor) to the text of an email. A more comprehensive integration of PGP with the MIME email standard is specified by RFC 3156.

Plugins implementing PGP functionality are available for many popular e-mail applications (such as Outlook, Outlook Express, Eudora, Evolution, Mutt, Mozilla Thunderbird, Apple Mail, and many others). Several are included with many PGP distributions.

Each such plugin is, from a security viewpoint, independent of PGP itself; each might have implementation errors or interact insecurely with PGP or other software. Using such plugins does not necessarily provide the same level of security as would standalone (and correct) use of PGP itself. Such add-ons can, at best, be equivalent to PGP in security; at worst, a plugin may reduce your actual 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 test the whole system by sending test messages to oneself, or to a partner, periodically; especially after any software change or upgrade. The safest operational approach is to manually encrypt and sign messages and email them manually. Like all security considerations, however, this is necessarily balanced against other system constraints and user needs. Whatever risks there may be in a quality security system, though, not using it is always riskier.

How PGP works

PGP uses both public-key cryptography and symmetric key cryptography, and a system for linking public keys to identities known as the web of trust.

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 key or conventional key) for a symmetric cipher algorithm; that key is then used to encrypt the plaintext of a message. Many PGP users' public keys are available to all from the many PGP key servers around the world which act as mirror sites for each other.

The recipient of a PGP-protected message decrypts 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 recipient's private key. Use of two ciphers is sensible due to the very considerable difference in operating speed between asymmetric key and symmetric key ciphers (the latter are typically much faster). There are also cryptographic vulnerabilities in the asymmetric key algorithms PGP uses when they are used to directly encrypt messages.

A similar strategy is (optionally) used to detect whether a message has been altered since it was completed, 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 with either the RSA or DSA signature algorithms. To do so, PGP computes a hash (also called a message digest) from the plaintext, and then creates the digital signature from that hash using the sender's private key.

The message recipient computes a message digest over the recovered plaintext, and then uses the sender's public key and the signed message digest value with the signature algorithm. If the signature matches the received plaintext's message digest, it must be presumed (to a very high degree of confidence) that the message received had not been tampered with either deliberately or accidentally since it was signed.

Both when encrypting messages and when verifying signatures, it is critical that the public key one uses to send messages to some person or entity actually does 'belong' to the intended recipient. Simply downloading a public key from somewhere is not overwhelming assurance of that association; deliberate (or accidental) spoofing is possible. PGP includes provisions for distributing users' public keys in 'identity certificates' which are constructed cryptographically so that any tampering (or accidental garble) is readily detectable. But merely making a certificate effectively impossible to modify undetectably is also insufficient. It can prevent corruption only after the certificate is created, not before. Users must also verify by some means 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. A given public key (or more specifically, information binding a person to a key) may be digitally signed by a third party to attest the association between the person and the key. There are several levels of confidence that can be expressed in this signature; although many programs read and write this information, few (if any) incorporate the level of certification when calculating whether to trust a key.

In OpenPGP, the specification of trust signatures supports the creation of certificate authorities. A trust signature indicates both that the key belongs to its claimed owner and that the owner of the key is trustworthy to sign other keys at one level below their own. A level 0 signature is comparable to a web of trust signature, only the validity of the key is certified. A level 1 signature is similar to the trust one has in a certificate authority because a key signed to level 1 is able to issue an unlimited number of level 0 signatures. A level 2 signature is highly analogous to the trust that many have of Microsoft whenever they use the default certificate authority list in Internet Explorer, because it allows the owner of the key to make other keys certificate authorities.

PGP has also always included a way to cancel ('revoke') identity certificates which may have become invalid; this is, more or less, equivalent to the certificate revocation lists of more centralized PKI schemes. Recent PGP versions have also supported certificate expiration dates.

The problem about how to identify a public key as correctly belonging to some other user is not unique to PGP. All public key and private key cryptosystems have the same problem, if in slightly different guise, and no fully satisfactory solution is known. PGP's scheme, at least, leaves the decision whether or not to use its endorsement/vetting system to the user, while most other PKI schemes do not, requiring instead that every certificate attested to by a central certificate authority be accepted as correct.

Security

When used properly, PGP is believed to be capable of very high security. Many believe that even government agencies such as NSA are incapable of directly breaking properly produced, PGP-protected, messages, though there are rumors to the contrary. In 1996, cryptographer Bruce Schneier characterized it as being "the closest you're likely to get to military-grade encryption" (Applied Cryptography, 2nd ed., p587).

In contrast to security protocols like SSL which only protect data in transit over a network, PGP can also be used to protect data in storage.

Like all other cryptography systems and software, the security of PGP could be lost by misuse or indirect attacks avoiding hard cryptanalysis. In one case, the FBI obtained a court order permitting them to secretly install a keystroke logger on a suspect's computer; when they harvested the information, they recovered his PGP passphrase and thereby gained access by way of his PGP private key to all his protected files and emails. He was subsequently tried and convicted.

Leaving aside such problems, the cryptographic security of PGP depends on the validity of the assumption that the algorithms it uses are unbreakable by direct cryptanalysis with current equipment. For instance, in the original version of PGP the RSA algorithm was used to encrypt session keys, and RSA itself depends upon the generally presumed one-way function nature of mathematical [[Integer factorization|integer factoring] for its security. Unknown integer factorization techniques might make breaking RSA easier or perhaps even trivially easy. Likewise the secret key algorithm originally used in PGP was IDEA, which might be found to have a previously unsuspected cryptanalytic flaw. Any specific instances of PGP or IDEA insecurities -- if they exist -- are not publicly known. As current versions of PGP have added additional encryption algorithms, the degree of cryptographic vulnerabilty varies accordingly.

Clearly, since the NSA and GCHQ and similar organizations do not discuss the state of their cryptanalytic knowledge, there exists a publicly unknown chance that one or more has discovered something which allows them to decrypt some PGP messages without access to the relevant private key. Moreover, in consideration of the enormous, non-public budgets accorded these entities, intellectual honesty would bring into question any assertion that they have not accomplished their primary mission of decrypting electronic information regardless of the complexity of the task.

Since PGP now permits the use of several algorithms, current PGP messages are not equally susceptible to such potential breakthroughs. However, there has been some speculation that originally released PGP (using the RSA and IDEA algorithms) might have been broken. PGP's author, Phil Zimmerman, was criminally investigated for three years by the U.S. Government for having violated munitions control regulations in connection with the availability outside the US and Canada of PGP. The investigation was abruptly dropped. Zimmerman has publicly stated that the investigation might have been dropped because the U.S. government had found a way to break PGP messages of that period.

Early history

Zimmermann created the first version of PGP in 1991. He was a long-time anti-nuclear activist, and created PGP so that like-minded people could securely use BBS systems and securely store messages and files. No license was required for non-commercial use, there was not even a nominal charge, and the complete source code was included. PGP found its way onto Usenet and from there onto the Internet.

The name "Pretty Good Privacy" was inspired by the name of the grocery store featured in radio host Garrison Keillor's fictional town, Lake Wobegon. The grocery was "Ralph's Pretty Good Grocery".

PGP became entangled in US Government restrictions on export of cryptography almost from its earliest existence.

The initial spread of PGP

PGP rapidly acquired a considerable following around the world after it was released. Users and supporters included dissidents in totalitarian countries (some affecting letters to Zimmermann have been published, and included in testimony before the US Congress), civil libertarians in other parts of the world (see Zimmermann's published testimony in various hearings), and the 'free communications' activists who call themselves cypherpunks. The cypherpunks provided both publicity and distribution.

Shortly after its release, PGP found its way outside the US, and in February 1993 Zimmermann became the formal target of a criminal investigation by the US Government for "munitions export without a license". Cryptosystems using keys larger than 40-bits were then considered munitions within the definition of the US export regulations; PGP has never used keys smaller than 128 bits so it qualified at that time. Penalties for violation, if found guilty, were substantial. The investigation of Zimmermann was eventually closed without filing criminal charges against him or anyone else.

The US export regulations remain in force, but were liberalized substantially throughout the late 1990s. Since 2000, compliance with the regulations is also much easier. PGP no longer meets the definition of a non-exportable weapon, and can be exported anywhere, assuming local regulations permit.

Patent licensing

Early releases of PGP had issues with patent licensing, as well. The first release used a symmetric cipher Zimmermann himself designed; he called it Bass-O-Matic after a Saturday Night Live sketch involving fish and kitchen blenders. It became apparent rather quickly that it was insecure, and was promptly replaced by the IDEA cipher. Both the symmetric key algorithm, IDEA, and the asymmetric key algorithm, RSA, had been patented and required a license to use. There was vigorous and extended debate as to whether Zimmermann had permission to use RSA in PGP. Zimmermann claimed that RSA Data Security (now RSA Security) had given him oral permission for non-commercial use in an early meeting; RSA disagreed. The criminal investigation was started by a complaint RSADSI made to US Customs about PGP's use of the RSA algorithm.

The situation was complicated by varying patent restrictions in different countries. RSA was patented only in the US; IDEA's patent holders were considerably more liberal in their licensing in the US than in the EU. In addition, the patent on the RSA algorithm was partially controlled by MIT via RSADSI. MIT had little trouble with PGP but did have difficulty with RSADSI's hostile position against PGP's non-commercial use of RSA.

The outcome of the RSA licensing conflict was a fork of PGP:

• A US version which used RSA's shareware crypto library, RSAREF. This version was acceptable to the RSA patent license.
• An international version that used the original RSA code created by Zimmermann and his collaborators, which became known as PGP-i (the 'i' standing for international). It was desirable at the time that there be a version maintained outside the US so as to avoid further difficulties with US export regulations and with RSA licensing. PGP-i was distributed and maintained by Ståle Schumacher in Norway.

The US version was directly distributed by MIT itself, among many others, on the Internet, by BBSs, and by users and groups on private information systems such as AOL and CompuServe. At least on the MIT site, there was a requirement that the email address to which PGP would be sent be in the US or Canada, and there was an additional requirement that the recipient state where they were resident. Outside the US, most people ended up going to pgpi.org, Schumacher's Web site.

Recent developments

During all of this turmoil, Zimmermann's team worked on a new version of PGP called PGP 3. This new version was to have considerable security improvements, including a new certificate structure which fixed small security flaws in the PGP 2.x certificates as well as permitting a certificate to include separate keys for signing and encryption. Furthermore, the painful experience with patent and export problems led them to eschew patents entirely. PGP 3 introduced use of the CAST-128 (a.k.a. CAST5) symmetric key algorithm, and the DSA and Elgamal asymmetric key algorithms, all of which were unencumbered by patents.

PGP goes commercial

After the criminal investigation ended in 1996, Zimmermann and his team started a company to produce new versions of PGP. They merged with Viacrypt (to whom Zimmermann had sold commercial rights to PGP and who had licensed RSA directly from RSADSI) which then changed its name to PGP Incorporated. The newly combined Viacrypt/PGP team started work on new versions of PGP based on the PGP 3 system. Unlike PGP 2, which was an exclusively command line program, PGP 3 was designed from the start as a software library allowing users to work from a command line or inside a GUI environment. The original agreement between Viacrypt and the Zimmermann team had been that Viacrypt would have even-numbered versions and Zimmermann odd-numbered versions. Viacrypt, thus, created an new version (based on PGP 2) that they called PGP 4. To remove confusion about how it was that PGP 3 was the successor to PGP 4, PGP 3 was renamed and released as PGP 5 in May 1997.

Inside PGP Inc., there was still concern about patent issues. RSADSI was challenging the continuation of the Viacrypt RSA license to the newly merged firm. PGP Inc adopted an informal internal standard called "Unencumbered PGP": "use no algorithm with licensing difficulties".

OpenPGP and new PGP-like programs

Because of PGP's importance worldwide, many wanted to write their own software that would interoperate with PGP 5. The "Unencumbered PGP" team inside PGP Inc. convinced Zimmermann, and the rest of the PGP Inc. executives, that an open standard for PGP was critical for them and for the cryptographic community as a whole. Even in 1997, there were other PGP-compatible systems; a notable one was from a Belgian company, Veridis (then called Highware) which had licensed PGP 2 code directly from Zimmermann.

Thus, in July 1997, PGP Inc. proposed to the IETF that there be a standard called OpenPGP. They gave the IETF permission to use the name OpenPGP to describe this new standard as well as any program that supported the standard. The IETF accepted the proposal and started the OpenPGP Working Group.

OpenPGP is on the Internet Standards Track; the current specification is RFC 2440 (July 1998). OpenPGP is still under active development and a follow-on to RFC 2440 is being actively finalized by the OpenPGP working group as of mid-2004.

The Free Software Foundation has developed its own OpenPGP-compliant program called GNU Privacy Guard (GnuPG). GnuPG is freely available together with all source code under the GNU General Public License (GPL). The advantage of using GnuPG over PGP (notwithstanding its lack of a workable graphical user interface) is that by virtue of the GPL license, it will always be available freely. This becomes important when a user wants to decrypt a document in the distant future that was encrypted at the present moment. There is no such guarantee that PGP will be available in the future under terms that are available today (in fact, as of PGP 9, the cost of a license has increased for at least users of PGP Personal; further the troubled ownership history of PGP should cause long-term users some concern).

Several other vendors have also developed OpenPGP-compliant software.

Versions of PGP more recent than the standard are, more or less, compliant or compatible with it.

The Network Associates acquisition

In December, 1997 PGP Inc. was acquired by Network Associates, Inc. Zimmermann and the PGP team became NAI employees. NAI continued to pioneer export through software publishing, being the first company to have a legal export strategy by publishing source code. Under their aegis, the PGP team added disk encryption, desktop firewalls, intrusion detection, and IPsec VPNs to PGP. After the export regulation liberalizations of 2000 that no longer required publishing of source, NAI stopped releasing source code, over the PGP team's objection. There was consternation amongst PGP users worldwide and, inevitably, some conspiracy theories as well.

In early 2001, Zimmermann left NAI. He served as Chief Cryptographer for Hush Communications, who provide an OpenPGP-based email service, Hushmail. He has also worked with Veridis and other companies.

In October, 2001, NAI announced that its PGP assets were for sale and that it was suspending further development of PGP. In February 2002, NAI cancelled all support for PGP.

The current situation

In August 2002, several ex-PGP team members formed a new company, PGP Corporation, and bought the PGP assets (except for the command line version) from NAI. PGP Corp is supporting existing PGP users and honoring existing support contracts. Zimmermann now serves as a special advisor and consultant to PGP Corp., as well continuing his ties to Hush Communications and Veridis, and running his own consulting company.

NAI retained the rights to a command line version of PGP and continues to sell it as "McAfee E-Business Server." Prior to January 2004, PGP Corporation was prevented by its arrangement with NAI from offering a command line version of PGP.

In cooperation with Zimmermann, Veridis developed and sells an OpenPGP compatible command line version, Filecrypt. Filecrypt and GnuPG continue to be available in source code, as do assorted earlier versions for various platforms.

Since the 2002 purchase of NAI PGP assets, PGP Corporation has offered worldwide PGP technical support.

The product release history from the inception of the new PGP Corporation follows:

2002- PGP Corporation offers PGP 7.2 for Mac OS 9. PGP Personal and PGP Freeware released. PGP 8.0 released for Macintosh and Windows. PGP Corporation releases source code for peer review.

2003- PGP Corporation offers PGP Desktop 8.0.1DE for Windows released for German-language users. PGP Desktop 8.0.2 released. PGP Desktop 8.0.3 released for Macintosh and Windows. PGP Corporation announced and shipped PGP Universal INFO, a new self-managing security architecture and product line. PGP Universal 1.1 released on December 30.

2004- PGP Corporation offers PGP Universal 1.2. PGP Desktop 8.1 released. PGP Command Line 8.5 released. PGP Corporation and Symantec offer an integrated email PGP Universal security solution for the enterprise. PGP Software Development Kit (SDK) receives FIPS 140-2 Level 1 validation from NIST

2005- PGP Corporation offers PGP Universal 2.0 and PGP Desktop 9.0 products as well as new PGP Global Directory service. New products for Mac OS X 10.4 "Tiger" released. Enhancement of PGP 9.0.1 Freeware to a full functionality, 30 day Trialware usage period. Release of PGP 9.0.2 German localization and international encoding updates. Release of PGP 9.0.2 Japanese localization update.

Compatibility amongst PGP versions

A combination of the patent licensing and export regulation difficulties has caused some compatibility problems. However, since the OpenPGP standard was adopted, and since 2002 when PGP Corp was formed, the situation is substantially better than it had been.

The OpenPGP standard specified mechanisms for negotiating agreement between the copies of PGP running at either end of a communications link as to which cipher algorithm is to be used with this or that message, as well as other feature additions after PGP 2.x. All OpenPGP conforming implementations are required to follow this part of the specification. Thus, there are no significant interoperability issues between OpenPGP versions, including those from PGP Corp, Gnu/FSF (ie, GPG), Hushmail, Veridis, Articsoft, Forum, and so on. The developers of these programs also work reasonably closely with each other. They consider interoperability difficulties to be bugs, and fix them.

PGP 2.x compatibility issues

The situation is different when recent PGP versions interoperate with PGP 2.x versions. PGP 2 used patented algorithms which were licensed under various (confused) terms. The patent on one of those algorithms (RSA) expired in fall 2000, but the patent on IDEA is still in effect as of 2005. While some current versions of PGP include provisions for interoperating with PGP 2.x, (eg, PGP Corp's and Hushmail), others do not. Most notably, GnuPG does not, by default, support the IDEA algorithm used in all 2.x PGP versions. Support for it can be added as there is a GnuPG plugin for IDEA, but users must build it in themselves, and of course deal with any patent license issues that may apply to their use. Commercial use of IDEA requires a paid license, though non-commercial use has not required one.

As of mid 2004, the best way to deal with interoperability issues regarding PGP 2.x is to simply avoid them; use an OpenPGP-compliant system. Several small security issues have been discovered with PGP 2.x in the decade since it was designed and released, and have been fixed where possible, but some of the fundamental protocols in PGP 2.x are now known to be vulnerable to certain obscure attacks and these have not been changed. None of the known vulnerabilities made it into the OpenPGP standard nor in any of the compliant implementations. While none of these problems with patched versions of 2.x are thought to be seriously insecure, the IETF's OpenPGP working group is in the process of deprecating PGP 2.x compatibility for OpenPGP. Ståle Schumacher Ytteborg still maintains his pgpi.org Web site as a repository for PGP, including the most recent releases of earlier versions such as 2.x.

Historically, there was an additional, deliberate, incompatibility among versions of PGP 2.x caused by the RSA patent license dispute. Part of settling it required that PGP 2.6 be made incompatible with prior 2.x versions. This was done by increasing the version number of some internal data structures and by using the RSAREF implementation of the RSA algorithm. The original PGP code for the RSA algorithm could be used outside the US, and in the 'i' variants, such as PGP 2.6.3i. There were more than adequate engineering reasons for doing so; the RSA algorithm implementation by the PGP team was over twice as fast as that in the RSAREF code.

Meanwhile, in the US, the PGP team had created PGP 3 (actually released as PGP 5, see above) and the OpenPGP IETF standard had been adopted. Continued licensing difficulties for the RSA algorithm forced them, and the GnuPG team as well, to exclude RSA. But, when the RSA patent expired in 2000, RSA support was returned to PGP and to the OpenPGP standard, so there is no longer a need for "US" and "International" versions of any release of PGP.

In summary, it is now best to use a recent version of an OpenPGP system. Cooperation between the OpenPGP developers have essentially eliminated interoperability incompatibilities amongst them.

Feature comparison

Compared to RFC 1991 (PGP 2.x), OpenPGP introduces many features. It is backward compatible in the sense that an OpenPGP implementation can (optionally) read messages and use keys from the older specification; however, this is complicated by the use of encumbered algorithms as described above. PGP 2.x is not forward compatible in that it cannot in general make any use of messages or keys in the OpenPGP format (although OpenPGP implementations may include facilities to interoperate with older implementations).

In the following table, mandatory algorithms are prefixed by an "*".

Extra features in OpenPGP V4 keys as compared to V3 keys include:

• a "public key" can include subkeys alongside the main key, enabling convenient use of separate keys for signing and encryption, for example
• several algorithms of each type are supported. To ensure interoperability:
  • certain algorithms are mandatory (see table)
  • a recipient's public key can specify a preference list of algorithms that that recipient will accept
• the web of trust model is extended with trust signatures, which allow a signature to specify that a key should be trusted not only in itself but also to sign other keys, in effect allowing implementation of certificate authorities
• a public key certificate can authorise other keys to revoke it
• some minor security holes in the specification of key IDs and fingerprints were closed

("V3" and "V4" refer to the version number used internally in the data format, rather than to versions of the PGP software, which are not in general the same.)

Implementations

• Authora Inc. - Founding member of Open PGP Alliance - Creator of Zendit (free Open PGP desktop software for individuals) and EDGE (Open PGP Command Line)
• PGP Corporation - the current custodian, vendor, and supporter of 'official' PGP
• GNU Privacy Guard (aka GnuPG or GPG)
  • WinPT, a graphical interface
  • GPGshell, a graphical interface
  • Enigmail, an email extension for the Mozilla family
  • MacPGP, the Mac OS X port of GnuPG
  • GPGMail, a plugin for Apple's Mail,
• Patrick Townsend & Associates is the first commercial company to bring PGP to the IBM os/400 iSeries operating system.
• Veridis - a command line version of PGP

See also

• Public-key cryptography

External links and references

• MIT Public Key Directory for Registration and Search
• MIT Distribution Site - (dead)
• List of public keyservers
• The OpenPGP standard
  • IETF OpenPGP working group
  • openpgp.org, the "OpenPGP Alliance"
• Miscellaneous
  • Simson Garfinkel wrote a book about PGP (O'Reilly and Associates), and MIT Press has published Zimmermann's documentation for several PGP versions, as well as the source code for them in separate volumes. PGP long included Zimmermann's documentation in every copy.
  • http://www.pgpi.org - Stale Schumacher's Web site. Information on currently available open source versions of PGP, including 2.x versions, and information on GPG and PGP generally.
  • http://www.philzimmermann.com - Home page of PGP's creator, lots of PGP related information
  • http://www.privacy.com.au/pgpatk.html Practical Attacks on PGP security information
  • A filk song about PGP: (lyrics) (MP3)
  • Another song (lyrics): [1]
  • PGP Corporation's Support Forum community support plus contributions from PGP Support staff
  • PGP pathfinder - a page computing paths between people in PGP web of trust