Jump to content

Pretty Good Privacy

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 71.205.192.51 (talk) at 14:25, 10 September 2006 (→Implementations). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

File:PGP Icon.png
"PGP" redirects here. For other uses, see PGP (disambiguation).

Pretty Good Privacy (PGP) is a computer program which provides cryptographic privacy and authentication. The first released version of PGP, by designer and developer Phil Zimmermann, became available in 1991. Subsequent versions have been developed by Zimmermann and others.

PGP has been sufficiently influential that its operating protocols and data formats have been standardized for interoperability among different versions of PGP and related software. Eventually, the PGP design was adopted as an Internet standards-track specification known as OpenPGP. OpenPGP is now an open standard followed by PGP, GNU Privacy Guard (GnuPG), Hushmail, Veridis[1], Authora, EasyByte Cryptocx[2], and others.

PGP and E-mail

While PGP can encrypt the content of any data (e.g., any binary file or message text), it is most commonly used for e-mail and internet faxing, which have no built-in security as originally implemented. PGP and S/MIME are two [incompatible] official email security systems which are currently NIST specified standards.

PGP was originally used for email by converting an encrypted message into a special formatting (ASCII armor) to prevent changes during transmission. 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 Microsoft Office Outlook, Outlook Express, Eudora, Evolution, Mutt, Mozilla Thunderbird, Apple Mail, and many others). Several are included with many PGP distributions.

From a security viewpoint, every such plugin is independent of PGP itself. Each might have implementation errors or interact insecurely with PGP or with 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 always be careful and to regularly test the whole system by sending test messages to oneself or, better, to a partner who uses an independently installed and configured copy of PGP or compatible software. This will assure that there is at least end-to-end functionality, although more subtle bugs or damage may nevertheless still be present. This sort of check is especially important after any software change or upgrade. The safest method of use is to manually encrypt and sign messages and email them manually; this evades such problems as the possibility of spyware doing automatic hidden transmission of message text copies to an unintended place via a network connection. As with all security considerations, however, ensuring the best possible security must necessarily be balanced against other system constraints and user needs. For instance, users of Microsoft Windows will have a different security environment than those who use OpenBSD. Each implementation must take different measures to maximize security. Whatever risks there may be in a quality security system such as PGP or its relatives, not using it is always riskier.

How PGP works

PGP uses both public-key cryptography and symmetric key cryptography, and includes a system which binds the public keys to user identities. The first version of this system is generally known as a web of trust as opposed to developed later X.509 system with top-down approach based on certificate authority. Later versions of PGP have included something more akin to a public key infrastructure (PKI) that includes certificate authority.

PGP uses asymmetric key encryption algorithms. In these, the recipient must have previously generated a linked key pair, a public key, and a private key. The sender uses the recipient's public key to encrypt a shared key (aka a secret key or conventional key) for a symmetric cipher algorithm. That key is used, finally, 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 in this way is sensible because of the very considerable difference in operating speed between asymmetric key and symmetric key ciphers (the differences are often 1000+ times).

A similar strategy is (by default) used to detect whether a message has been altered since it was completed, or (also by default) 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 has not been tampered with, either deliberately or accidentally, since it was properly 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 has always included 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 has been 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. From its first release, PGP has included 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 the (more recent) OpenPGP specification, trust signatures can be used to support 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, since 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 assumption users must rely on whenever they use the default certificate authority list in Internet Explorer; 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. More recent PGP versions have also supported certificate expiration dates.

The problem of correctly identifying a public key as 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 original 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. It is widely believed, within the cryptographic community, that — if anyone — only government agencies such as the NSA might be capable of directly breaking properly produced, PGP-protected, messages. However, to the best of publicly available information, there is no known method for any entity to break PGP by cryptographic, computational means regardless of the version being employed. In 1996, cryptographer Bruce Schneier characterized an early version as being "the closest you're likely to get to military-grade encryption" (Applied Cryptography, 2nd ed., p587).

In contrast to security systems/protocols like SSL which only protect data in transit over a network, PGP can also be used to protect data in long-term data storage such as disk files. Some products derived from PGP have been developed which streamlined such uses of the PGP security design, largely by Network Associates while it controlled PGP.

Like all cryptography systems and software, the security of PGP can be lost by misuse or by indirect attacks which avoid hard cryptanalysis. In one case, the FBI obtained a court order permitting secret installation of keystroke logger software 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.[1]

Leaving aside such attacks, the cryptographic security of PGP depends on the assumption that the algorithms it uses are unbreakable by direct cryptanalysis with current equipment and techniques. For instance, in the original version of PGP the RSA algorithm was used to encrypt session keys; RSA's security depends upon the (generally presumed) one-way function nature of mathematical integer factoring. New unknown integer factorization techniques have the potential, therefore, to make breaking RSA easier than now, or perhaps even trivially easy. Likewise the secret key algorithm originally used in PGP was IDEA, which might, at some future time, be found to have a previously unsuspected cryptanalytic flaw. 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 their cryptographic vulnerability varies.

Clearly, since NSA, GCHQ and similar organizations do not discuss the state of their cryptanalytic knowledge, there exists a publicly unknown chance that one or more of them have discovered something which allows them to decrypt some PGP messages without access to the relevant private key. But this is, of course, true of every cryptographic system of any design and from any source, not just PGP.

Since PGP now permits the use of several algorithms, current PGP messages are not equally susceptible to any potential breakthroughs against the original algorithms. However, there has been some speculation that the first released PGP version (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.[citation needed]

On balance, it should be understood from the above discussion that the only currently credible entities with any credible chance of breaking PGP messages have access to government-level resources. The security of PGP encryption from direct cryptanalytic attack by anyone else is almost certainly quite strong.

Early history

Phil Zimmermann created the first version of PGP in 1991. He had been 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 with all copies. PGP found its way onto Usenet and from there onto the Internet.

The ironic 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. See below.

The initial spread of PGP

PGP rapidly acquired a considerable following around the world after it was released and found its way onto the Internet. Users and supporters included dissidents in totalitarian countries (some affecting letters to Zimmermann have been published, and some have been 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.

US export regulations regarding cryptography 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 encountered problems with patent licensing as well. The very first PGP 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 status in different countries. RSA was patented only in the US; IDEA's patent holders were considerably more liberal in their licensing than were the RSA assignees. In addition, the patent on the RSA algorithm was partially controlled by MIT via RSADSI (RSA Data Security, Inc.) . MIT had little trouble with PGP but did have difficulty with RSADSI's hostile position against PGP's non-commercial use of RSA.

The eventual 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 assignee (RSADSI).
  • 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 patent 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; it was available on the Internet, many 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

As noted above, PGP became entangled in US Government restrictions on export of cryptography almost from its earliest existence. 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 a new version (based on PGP 2) that they called PGP 4. To remove confusion about how it could be 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 (it is thought to be the most widely chosen quality cryptographic system), 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 January 2006.

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 under Windows, as in Linux one can use Seahorse) 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 complex ownership history of PGP causes many 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 its aegis, the PGP team added disk encryption, desktop firewalls, intrusion detection, and IPsec VPNs to the PGP family. After the export regulation liberalizations of 2000 which no longer required publishing of source, NAI stopped releasing source code, over the PGP team's objection. There was consternation amongst PGP users worldwide at this 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. The only remaining asset kept was the PGP E-Business Server (the original PGP Commandline). In February 2002, NAI cancelled all support for PGP, with the exception of the re-named commandline product. NAI (now McAfee) continues to sell and support the product under the name McAfee E-Business Server.

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. As of mid-2004, PGP Corporation has its own version of the command line 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 releases 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 a 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.
    • PGP Whole Disk Encryption is officially released as an independent product offering
    • 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, McAfee, 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 (then) patented algorithms which were licensed under various (confusing) terms. The patent on one of those algorithms (RSA) expired in fall 2000, but the patent on IDEA is still in effect and will expire in 2010–2011. 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 legally 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 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 that reason for "US" and "International" versions of any release of PGP has expired.

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 (and key certificates) 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 IDEA
*Triple-DES
CAST5
Blowfish
AES 128, 192, 256
Twofish
Hash algorithms *MD5 MD5
*SHA-1
RIPEMD-160
SHA-256
SHA-384
SHA-512
Compression algorithms ZIP ZIP
gzip
bzip2

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 acceptable algorithms
  • 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 kind 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

See also

  1. ^ "United States v. Scarfo, Criminal No. 00-404 (D.N.J.)". 2002-02-28. Retrieved 2006-09-08.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Pretty_Good_Privacy&oldid=74905881"