Encyclopedia > PGP
Pretty Good Privacy
Redirected from PGP
When used properly, PGP is capable of very high security; most informed observers believe that even government crypto agencies are incapable of cryptographically breaking PGP messages. But, like all cryptography, misunderstanding and confusion are common, and improperly used PGP can be (and will likely be) no more secure than other, poorly designed or implemented, crypto systems. Users must take the trouble to learn and to understand how to use PGP, lest the security it is capable of not be achieved. In most respects, this means 'read the documentation'. And pay attention. 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, and Mutt). Several are included with many PGP distributions.
|
PGP uses asymmetric encryption (originally RSA and several others in current versions) which have a public key and a private key. The recipient's public key is used encrypt a shared key[?] (or conventional key[?]) for a symmetric cypher algorithm (originally Zimmerman's Bass-O-Matic, but rather quickly IDEA and in current versions any of several others) 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, and (after some inevitable and usually unimportant delays) all have the same content. The recipient of an encrypted message decyphers the symmetric algorithm session key using his private key, and uses the recovered session key to decypher the message itself. Two cyphers are useful due to the very considerable difference in operating speed between all asymmetric cyphers to date, and the better symmetric cyphers (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, the sender uses PGP to 'sign' the message (this originally used the RSA algorithm, but more recent versions of PGP have added other asymmetric algorithms and signature protocols). PGP computes a message digest (= cryptographic hash value[?]) from the message, and then encyphers it using the signer's private key. The message recipient uses the signer's public key to decypher the hash value and compare it to the hash value the recipient computes independently from the decyphered message. If both hashes are identical it is certain (at least to a very high degree of confidence) that the message was not tampered with since it was encrypted (deliberately or accidentally). 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 decypher else the message wouldn't have been decypherable 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. If that private key has become known to someone else, anyone using that key can produce messages which will successfully pass PGP's tests. This is true for all crypto systems using asymmetric key algorithms, however; PGP is not in any sense specially vulnerable.
Both in encrypting 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 sufficient assurance of that association. PGP includes provisions for distributing users' public keys in 'identity certificates' which are so constructed that all tampering with any bit in the certificate is readily detectable. But merely making keys, or any other part of the other information in a certificate, impossible to change (without detection, anyway) is also insufficient. It may prevent tampering after certificate creation, but does not prevent corruption before certificate creation. Users must also attempt to 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 a certificate 'vetting scheme' to assist with this; it has been called a 'Web of Trust'. PGP identity certificates (which include public keys and owner information) can be 'digitally signed' by other PGP users who, by that act, are 'endorsing' the association of that public key with the person / entity listed in the certificate as its owner. PGP includes a 'vote counting' scheme which can be used to determine which public key<-->owner association a user will be willing to trust. For instance, if three partially trusted endorsers have vouched for a certificate (and so its included public key), OR if one fully trusted endorser has done so, the association in that certificate will be trusted. The parameters are user adjustable, and can be completely bypassed if a PGP user wishes. The scheme is flexible, unlike most public key infrastructure designs, and leaves the trust decision in the hands of individual users. It is not perfect and requires both caution and intelligent supervision by users. Nearly all PKI designs are much less flexible and require users to follow the 'trust endorsement' of the PKI generated certificates. Intelligence is normally neither required nor allowed.
This 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 there is no known solution. PGP's scheme leaves the decision to the user (with or without PGP's endorsement arithmetic), essentially all other PKI schemes (all of the commercial PKI schemes!) do not.
The first version of PGP released by Zimmermann found its way onto the Internet. No license was required, there was no charge, and all the source code was included. As a result of that release, PGP found its way outside the US, and Zimmerman became the target of a multi year criminal investigation by the US Government for munitions export without approval. At that time, and still, crypto systems were a 'munition' within the meaning of US law and regulation -- rather like a bomb or an fighter jet or a machine gun. The investigation was finally closed without bringing charges. But in the meantime, PGP had acquired a considerable following around the world. Supporters included the 'free communications' activists who called themselves cypherpunks, and who provided both publicity and distribution.
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 (the RSA algorithm was patented in the US, but not elsewhere; IDEA was patented internationally but non-commercial use was permittted) meant that US PGP versions operated under different legal rules than non US versions. In addition, the US government prohibited export of crypto systems of PGP's high quality; this is why Zimmerman was under criminal investigation for so long. All this produced forks in the original PGP software. Stale Schumacher in Norway supervised development of the most important independent PGP version. This version 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 largely reconverged back to one 'genetic line'.
New developments: OpenPGP and new PGP-like programs
Eventually an open source standard for 'PGP' was proposed, implemented and released (called OpenPGP[?]). It has become an Internet standard: OpenPGP, RFC 2440. It is semicompatible 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 available, with all source code, under the FSF's copyleft license GPL. Development was/is supported with funding from the German government.
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 of PGP for assorted markets; only some of them continued to be available with source code or in versions without cost. In early 2001, Phil 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, 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 is at Zimmerman's Web site. Filecrypt, the base version of PGP from PGP Corp, and of course GPG, continue to be available in source code.
compatibility amongst PGP versions
Because of the patent problem in the US, versions of PGP prior to v2.3 were deliberately made incompatible with later 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 holder (RSA Data Security) and was able to make arrangements to serve as a distribution point for 'patent permissible' open source versions of PGP to residents of the US and Canada. Elsewhere, others distributed various versions, with Stale's site (pgpi.org) 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, adding and changing while it controlled 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 some differences from existing and older PGP versions, though there remained considerable 'backward' interoperability. Some of this was due to longstanding reluctance to specify commerically controlled algorithms (eg, RSA and IDEA) in open source projects. The Free Software Foundation's GnuPrivacyGuard (GPG) project is committed to implementing the OpenPGP standard and in its newest version is said to have done so. 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[?] files at pgpi.org for more details on the compatibility question. 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. 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 all other software.
External Links and references
- Simson Garfinkle wrote a book about PGP (O'Reilly and Associates) which is excellent, and MIT Press has published Zimmerman's documentation for several PGP versions (also excellent), as well as the source code for them in separate volumes. Even the older volumes remain valuable.
- http://www.pgp.com - PGP Corporation
- http://www.veridis.com/openpgp/en/index.asp -- OpenPGP compatible - command line
- http://www.gnupg.org - The GNU Privicy Guard. A Free Software implementation of OpenPGP
- http://openpgp.org - Standards body for PGP -- RFC 2440
- http://www.pgpi.org - more information on currently available open source versions of PGP and for information on GPG and PGP generally.
- http://philzimmermann.com - Home page for creator of PGP, lots of PGP related information
All Wikipedia text is available under the terms of the GNU Free Documentation License
|
Search Encyclopedia
|
Featured Article
|