| • Science | • People | • Locations | • Timeline |
| Contents | ||
PGP was originally designed and developed by Phil Zimmermann in 1991. The name was suggested by a grocery store in radio host Garrison Keillor's 'hometown', Lake Wobegon. The grocery was "Ralph's Pretty Good Grocery"; its slogan was, "If you can't find it at Ralph's, you can probably get along without it."
PGP has been sufficiently influential that its design has been made an IETF Internet standard known as OpenPGP. Versions of PGP more recent than the standard are, more or less, compliant or compatible with it. Compatibility amongst PGP versions, and the history of the OpenPGP standardization effort, are both discussed below.
When used properly, PGP is capable of very high security; informed observers believe that even government agencies such as NSA are incapable of directly breakingCryptanalysis (from the Greek kryptos and analyein "to loosen" or "to untie") is the study of methods for obtaining the meaning of encrypted information without access to the secret information which is normally required to do so. Typically, this involves properly produced, PGP-protected, messages.
PGP is easier to use than many cryptosystems, but as with all cryptography, implementation and use greatly affect the security actually achieved. Implementation errors are always possible, and incautious use can easily render protected plaintextIn cryptography, plaintext (occasionally, cleartext though there are differences) is information used as input to an encryption algorithm. This could be, for example, a diplomatic message, a bank transaction, an email, a diary — any information that someo unprotected. Any cryptosystem can be insecure -- no matter how good its design. Generally, proper use involves reading and following the user documentation.
In contrast to security protocols like SSLSecure Sockets Layer SSL and Transport Layer Security TLS , its successor, are cryptographic protocols which provide secure communications on the Internet. Description These protocols provide endpoint authentication and communications privacy over the Int which only protect data 'in transit' (meaning while 'on the network'), PGP can also be used to protect data stored on disk, in backups, etc.
However, in some circumstances, even correct use may not be enough. In one case, the FBI obtained a court order permitting them to secretly install a keystroke logger (a sort of spywareStrictly defined, spyware is computer software that gathers and reports information about a computer user without the user's knowledge or consent. More broadly, the term spyware can refer to a wide range of related malware products which fall outside the) on a suspect's computer (near Philadelphia); when they harvested the information, they recovered his PGP passphraseA passphrase is a collection of 'words' used for access control, typically used to gain access to a computer system. Passphrases are also used to control both access to, and operation of, special security programs such as cryptographic systems. The origin and thereby gained access to all his protected files and emails. He was tried and convicted.
No cryptosystem, including PGP, can protect information (i.e., plaintextIn cryptography, plaintext (occasionally, cleartext though there are differences) is information used as input to an encryption algorithm. This could be, for example, a diplomatic message, a bank transaction, an email, a diary — any information that someo) that is available (or can be acquired) in other ways. PGP cannot protect the user from eavesdroppers, just as it can't prevent blackmailers or extortionists from demanding information, or prevent dumpster divers from recovering carelessly discarded papers with important information. Most cryptosystem users give little thought to such possible attacks; they are much more difficult to defend against than purely cryptanalytic "fair play". True information security requires operator security as well as high quality cryptographic design and implementation, and absolute information security is probably impossible.
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 email security systems which are currently NIST specified standards.
Plug-ins 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.From the viewpoint of security, each such plug-in is independent of PGP itself; each might have implementation errors, or interact insecurely with PGP or other software. Using such plug-ins does not necessarily provide the same level of security as would standalone (and correct) use of PGP itself. At best, such add-ons can be equivalent to PGP in security; at worst, a plug-in 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. However, like all security considerations, this is necessarily balanced against other system constraints and user needs. But, whatever risks there may be in a quality security system, not using it is always riskier.
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, which it predates. 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. The presumption is based on a number of considerations. It is extremely unlikely, with the algorithms and protocols used in PGP, that an adversary can create a signature for an arbitrary message and so a received message which passes this test must have been sent by the claimed sender. Security experts sometimes call this property non-repudiation.
However, anyone who has the private half of the signing key can trivially create a proper signature for anything whatsoever. In a world of email viruses, rootkits, Trojan horses, other malware, and FBI agents with court orders, the term 'non-repudiation' must therefore be taken with some caution as private keys can sometimes be compromised surreptitiously. But this is true for all cryptosystems using asymmetric key algorithms for non-repudiation and digital signatures. PGP is not in any sense specially vulnerable, but Zimmermann may have been wise, and not merely bemused, in calling his system "pretty good".
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. PGP has also always included a way to cancel 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.
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 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.
PGP became entangled in US Government restrictions on export of cryptography almost from its earliest existence. The tangle illustrates some of the public policy issues surrounding high quality modern cryptography, and is, regrettably, an actual, hard-to-follow, mess. One that threatened rather substantial jail time and fines as well.
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.
Shortly after that 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". Many found this hard to understand, and it has been observed, satirically, that a software program can easily become a weapon with the addition of a fuse and some explosive.
Nonetheless, cryptosystems using keys larger than 40-bits were then considered munitions within the definition of 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 and remain substantial. The US export regulations remain in force, but were changed substantially throughout the late '90s by: moving jurisdiction from the State Department to the Commerce Department, reclassifying cryptosystems as dual-use rather than only arms, liberalizing the approval process (in 2000), and increasing the key length routinely permitted from 40 bits (in several -- confusing -- stages). Since 2000, compliance with the regulations is also much easier. For example, in the early 1990s, approval was by default not granted. Post-2000, there is a 30-day review period during which the application may be denied; no action is now, by default, approval. There are also easier paths to approval for source code in contrast to object code, and other liberalizations that make the process easier for open source and small developers. However, it still remains safest to consult a crypto-knowledgeable attorney before embarking on any major cryptographic project which might interact with these requlations.
As a result of all this, PGP no longer meets the definition of a non-exportable weapon, and can be used (and exported) anywhere (assuming local regulations permit). And, the investigation of Zimmermann was eventually closed without filing criminal charges against him or anyone else.
PGP rapidly acquired a considerable following around the world after it was released; US export regulations didn't apply elsewhere. 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. These last provided both publicity and distribution (see their assorted manifestos for details).
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 verbal permission for non-commercial use in an early meeting, RSA disagreed. The criminal investigation in l'affaire Zimmermann was started by a complaint RSADSI made to US Customs about PGP's use of the RSA algorithm.
Complicating matters further, RSA was patented only in the US (for tricky legal reasons having to do with patent filing regulations), which meant that it was freely usable (as to the patent issues anyway) elsewhere. However, IDEA's inventors / assignees were considerably more liberal in their licensing in the US than in the EU. As if this weren't enough confusion, the patent on the RSA algorithm was partially controlled by MIT via the patent assignee, RSADSI; RSA's inventors were all at MIT at the time of their invention. Whatever the facts actually were in the Zimmermann/RSADSI dispute, 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 into
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 that he (or she) was a resident of one or the other. Outside the US, most people ended up going to pgpi.org (Ståle's Web site).
In Norway, Ståle Schumacher (now Ståle Schumacher Ytteborg) supervised development and maintenance of the international PGP version, which eventually came to be called PGPi (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.
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.
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".
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 crypto 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. (PGP, Pretty Good Privacy, and Pretty Good are all registered trademarks (as of 2002) belonging to PGP Corporation). The IETF accepted the proposal and started the OpenPGP Working Group.
OpenPGP has become an Internet Standard: adopted as RFCs 2440 and 3156. The Free Software Foundation has developed its own OpenPGP-compliant program called GNU Privacy Guard (GnuPG), as have several other vendors. GPG is, naturally, freely available together with all source code under the GNU General Public License (GPL). Development was supported with funding from the German government. OpenPGP is still under active development and a follow-on to RFC 2440 is being actively finalized as of mid-2004.
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.
In the summer of 2002, a new company, PGP Corporation, was formed by several ex-PGP team members. They bought the PGP assets (except for the command line version) from NAI, and formed a new company, PGP Corporation, in August 2002. 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, all 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. In 2002, PGP Corporation released PGP 7.2 for Mac OS 9, followed closely by PGP 8.0 for Macintosh and Windows, PGP Personal 8.0 for Macintosh and Windows, PGP Freeware and PGP source code for peer review. In 2003, PGP Corporation released PGP 8.0.1DE for German language users, PGP Universal (a new PGP policy based server product line implementing a self-managing security architecture). In 2004 to date, PGP Corporation has released PGP Desktop 8.1 for Macintosh and Windows, PGP Command Line 8.5 for Windows, Solaris and Linux (The non-compete agreement between PGP Corporation and NAI expired in January 2004), and PGP Universal 1.2.
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.
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. 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. All the patchable ones have been patched (ie, in up to date (ie, 'current') releases of the latest version of 2.x), 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.
If you are not one who requires such compatibility, this will not be of much concern. If you are, you will -- eventually -- become incompatible with OpenPGP compatible software. Nevertheless, 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.