Pretty Good Privacy
|
|
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, and others.
Throughout the world, it is, in its various versions, the cryptosystem most frequently chosen by users.
| Contents |
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 email security systems which are currently NIST specified standards.
Traditionally, PGP was integrated with email by simply 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.
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.
How PGP works
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 and other malware, as well as, both, law enforcement and secret agents, with and without warrants; the term, non-repudiation, must 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. 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.
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.
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. 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 other cryptography systems and software, the security of PGP could be simply bypassed: 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 to all his protected files and emails. He was subsequently tried and convicted.
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 verbal 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. In 2002, PGP Corporation released PGP Desktop 7.2 for Mac OS 9, followed closely by PGP 8.0 for Macintosh OSX and Windows 98-XP, PGP Freeware and PGP source code for peer review. In 2003, PGP Corporation released PGP Desktop 8.0.1DE for German language users, PGP Universal Server (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.2.
In May 2005, PGP 9.0 was released. 9.0 has a new email proxying feature that can monitor all incoming and outgoing messages and automatically encrypt and decrypt them according to user-defined rules sets. Another new feature is PGP Whole Disk, which allows complete drive encryption including the operating system.
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. 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 "*".
| Feature | PGP 2.x (RFC 1991) | OpenPGP (RFC 2440) |
|---|---|---|
| Key format | V3 keys | V4 keys |
| Asymmetric algorithms | *RSA (encryption & signature) | RSA (encryption & signature) *DSA (signature) *Elgamal (encryption) |
| Symmetric algorithms | *IDEA (cipher) | IDEA (cipher) *Triple-DES CAST5 Blowfish (cipher) SAFER-SK128 |
| Hash algorithms | *MD5 | MD2 MD5 RIPEMD-160 *SHA-1 |
| Compression algorithms | ZIP | ZIP zlib |
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
- PGP Corporation (http://www.pgp.com) - the current custodian, vendor, and supporter of 'official' PGP
- GNU Privacy Guard (aka GnuPG or GPG)
- Patrick Townsend & Associates (http://www.patownsend.com/PGPencryption.htm) is the first commercial company to bring PGP to the IBM os/400 iSeries operating system.
- Veridis (http://www.veridis.com/openpgp/en/index.asp) - a command line version of PGP
See also
External links and references
- MIT Public Key Directory for Registration and Search (http://pgp.mit.edu/)
- The OpenPGP standard
- IETF OpenPGP working group (http://www.ietf.org/html.charters/openpgp-charter.html)
- openpgp.org (http://www.openpgp.org/), the "OpenPGP Alliance"
- Miscellaneous
- Simson Garfinkle 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) (http://www.eff.org/Net_culture/Folklore/Humor/pgp.song) (MP3) (http://www.prometheus-music.com/audio/pgp.mp3)
- Another song (lyrics): [1] (http://web.archive.org/web/20030203063211/www.rahul.net/starport/xeno/pgp.html)
- PGP Corporation's Support Forum (http://forums.pgpsupport.com/index.php) community support plus contributions from PGP Support staff
- PGP tutorial (http://www.aperiodic.net/phil/pgp/tutorial.html)
- PGP pathfinder (http://www.cs.uu.nl/people/henkp/henkp/pgp/pathfinder/mk_path.cgi) - a page computing paths between people in PGP web of trustbe:PGP
de:Pretty Good Privacy es:Pretty Good Privacy fr:Pretty Good Privacy it:Pretty Good Privacy nl:Pretty Good Privacy no:Pretty Good Privacy ja:PGP pl:PGP ru:PGP fi:PGP sv:Pretty Good Privacy