OpenPGP

OpenPGP is an open standard that describes a message (file) format originally used by the Pretty Good Privacy (PGP) program, initially developed by Phil Zimmermann in 1991.^[1] A number of standard-track Request for Comment documents augment its functionality, one example being PGP/MIME which defines the use of OpenPGP in email via MIME.^[2] OpenPGP's encryption can ensure the secure delivery of files and messages, as well as provide verification of who created or sent the message using a process called digital signing.

Using OpenPGP for communication requires participation by both the sender and recipient. OpenPGP can also be used to secure sensitive files when they are stored in vulnerable places like mobile devices or in the cloud.^[3]

OpenPGP is on the Internet Standards Track and is under active development. Many e-mail clients provide OpenPGP-compliant email security as described in RFC 3156. The current specification is RFC 9580 (July 2024), the successor to RFC 4880. RFC 9580 specifies a suite of required algorithms consisting of X25519, Ed25519, SHA2-256 and AES-128. In addition to these algorithms, the standard recommends X448, Ed448, SHA2-384, SHA2-512 and AES-256. Beyond these, many other algorithms are supported.

(Open)PGP encryption uses a serial combination of hashing, data compression, symmetric-key cryptography, and finally public-key cryptography; each step uses one of several supported algorithms. Each public key is bound to a username or an e-mail address. The first version of this system was generally known as a web of trust to contrast with the X.509 system, which uses a hierarchical approach based on certificate authority and which was added to OpenPGP implementations later. Current versions of OpenPGP include options through an automated key management server.

A public key fingerprint is a shorter version of a public key. From a fingerprint, someone can validate the correct corresponding public key. A fingerprint such as C3A6 5E46 7B54 77DF 3C4C 9790 4D22 B3CA 5B32 FF66 can be printed on a business card.^[4][5]

As OpenPGP evolves, versions that support newer features and algorithms can create encrypted messages that older OpenPGP systems cannot decrypt, even with a valid private key. Therefore, it is essential that partners in OpenPGP communication understand each other's capabilities or at least agree on PGP settings.^[6]

See § Version history below for a list of version codes.

PGP can be used to send messages confidentially.^[7] For this, PGP uses a hybrid cryptosystem by combining symmetric-key encryption and public-key encryption. The message is encrypted using a symmetric encryption algorithm, which requires a symmetric key generated by the sender. The symmetric key is used only once and is also called a session key. The message and its session key are sent to the receiver. The session key must be sent to the receiver so they know how to decrypt the message, but to protect it during transmission it is encrypted with the receiver's public key. Only the private key belonging to the receiver can decrypt the session key and use it to symmetrically decrypt the message.

PGP supports message authentication through digital signatures to verify whether a message was actually sent by the person or entity claimed to be the sender. The sender uses PGP to create a digital signature for the message with one of several supported public-key algorithms. To do so, PGP computes a hash, or digest, from the plaintext and then creates the digital signature from that hash using the sender's private key.

Both when encrypting messages and when verifying signatures, it is critical that the public key used to send messages to someone or some entity actually does 'belong' to the intended recipient. Simply downloading a public key from somewhere is not a reliable assurance of that association; deliberate (or accidental) impersonation is possible. From its first version, PGP has always included provisions for distributing user's public keys in an 'identity certification', which is also constructed cryptographically so that any tampering (or accidental garble) is readily detectable. However, merely making a certificate that is impossible to modify without being detected is insufficient; this can prevent corruption only after the certificate has been created, not before. Users must also ensure by some means that the public key in a certificate actually does belong to the person or entity claiming it. A given public key (or more specifically, information binding a user name to a key) may be digitally signed by a third-party user to attest to the association between someone (actually a user name) and the key. There are several levels of confidence that can be included in such signatures. Although many programs read and write this information, few (if any) include this level of certification when calculating whether to trust a key.

The web of trust protocol was first described by Phil Zimmermann in 1992, in the manual for PGP version 2.0:

As time goes on, you will accumulate keys from other people that you may want to designate as trusted introducers. Everyone else will each choose their own trusted introducers. And everyone will gradually accumulate and distribute with their key a collection of certifying signatures from other people, with the expectation that anyone receiving it will trust at least one or two of the signatures. This will cause the emergence of a decentralized fault-tolerant web of confidence for all public keys.

The web of trust mechanism has advantages over a centrally managed public key infrastructure scheme such as that used by S/MIME but has not been universally used. Users have to be willing to accept certificates and check their validity manually or have to simply accept them. No satisfactory solution has been found for the underlying problem.

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 (like those included in web browsers); it allows the owner of the key to make other keys certificate authorities.

(Open)PGP versions have always included a way to cancel ('revoke') public key certificates. A lost or compromised private key will require this if communication security is to be retained by that user. This is, more or less, equivalent to the certificate revocation lists of centralised PKI schemes. Recent OpenPGP versions have also supported certificate expiration dates.

The problem of correctly identifying a public key as belonging to a particular user is not unique to PGP. All public key/private key cryptosystems have the same problem, even if in slightly different guises, and no fully satisfactory solution is known. OpenPGP's web-of-trust scheme at least leaves the decision as to 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.

This article is missing information about OpenPGP support in current version of PGP. Please expand the article to include this information. Further details may exist on the talk page. (June 2026)

The Free Software Foundation has developed its own OpenPGP-compliant software suite called GNU Privacy Guard, freely available together with all source code under the GNU General Public License and is maintained separately from several graphical user interfaces that interact with the GnuPG library for encryption, decryption, and signing functions (see KGPG, Seahorse, MacGPG).^{[undue weight? – discuss]} Several other vendors^[specify] have also developed OpenPGP-compliant software. GnuPG implements RFC 4880,^[8] and more recently 4880bis.^[9]

PGP implements OpenPGP, but the GnuPG documentation notes a number of departures from the standard in versions 6 and 7.^[8]

RNP (the library used by Mozilla Thunderbird) implements RFC 4880, 4880bis/LibrePGP,^[10] and (unannounced on its website, but available as a build option) RFC 9580.^[11][12]

The development of an open source OpenPGP-compliant library, OpenPGP.js, written in JavaScript and supported by the Horizon 2020 Framework Programme of the European Union,^[13] has allowed web-based applications to use PGP encryption in the web browser.

OpenPGP.org provides a list of implementations with a focus on the current version 6 (RFC 9580).^[14] A list is provided in OpenPGP.dev, an online book describing RFC 9580.^[11]

The open source office suite LibreOffice implemented document signing with OpenPGP as of version 5.4.0 on Linux.^[15]

PGP keys are supported in Mozilla Thunderbird (Built-in in version 78 onwards on PC,^[16] and with the OpenKeychain app as of version 9 on Android^[17]), GitHub,^[18] and GitLab.^[19]

The impetus for creating OpenPGP came after the merging of PGP Inc. into Viacrypt in 1996, with RSADSI challenging the continuation of the Viacrypt RSA license to the newly merged firm. The company adopted an informal internal standard that they called "Unencumbered PGP" which would "use no algorithm with licensing difficulties". Because of PGP encryption's importance worldwide, many wanted to write their own software that would interoperate with PGP 5. Zimmermann became convinced that an open standard for PGP encryption was critical for them and for the cryptographic community as a whole. In August 1996, Atkins, Stallings, and Zimmerman had IETF publish RFC 1991, an Informational document titled "PGP Message Exchange Formats". This document described PGP version 2.x (packet versions 2 and 3).^[20]

A contemporary specification, RFC 2015 of October 1996, specified PGP/MIME, a way to embed PGP messages into e-mail.

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.^{[citation needed]} This effort culminated in RFC 2440 of November 1998, which additionally described the format used by the "PGP 3" still in prototype stage (packet version 4).^[21]

The next standard, RFC 4880 of November 2007, revised RFC 2440 without changing the packet version number (4). It is intended to describe PGP 5.x, the released version of "PGP 3".^[22]

New ciphers were also integrated into OpenPGP during this time in the form of RFCs 5581 ("The Camellia Cipher in OpenPGP") and 6637 ("Elliptic Curve Cryptography (ECC) in OpenPGP").

From 2015 work has been underway in the OpenPGP WG for an updated document in a repository named 4880bis, a project originally started by Werner Koch, author of GnuPG. It describes a packet version 5.^[23] According to the timeline on the LibrePGP website, support for 4880bis "version 5" as defined in this family of drafts had already been implemented in early 2018 in experimental branches of RNP and GnuPG 2.3, and was released as production-quality code in GnuPG 2.0 of July 2020.^[24]

In January 2021 the OpenPGP WG switching to a new editing strategy marked by a new "crypto-refresh" document, which is to start with the text of 4880 and be modified in a string of merge requests into the new specification.^[25] In September 2022 Koch created the draft-koch-openpgp-2015-rfc4880bis-00 as a branch separate from the crypto-refresh. In the abstract section Koch described the merge requests that occurred after crypto-refresh as "mainly prepared in advance by one of the chairs" and the refactoring as unnecessary given that draft-ietf-openpgp-rfc4880bis-10 was "basically ready for last call".^[26]

In November 2022, crypto-refresh modified its "version 5" signature format to avoid confusion with a v3 signature, one of the initial incompatibilities with the "version 5" in Koch's branch.^[27] In February 2023, crypto-refresh renumbered its "version 5" to "version 6" to "avoid[] collision with software that squatted on the version 5 codepoint without getting an IANA registration", referring to software that implement the "version 5" as defined in the older 4880bis.^[28] Open conflict between Koch and the OpenPGP WG broke out in late 2023, with Koch rebranding his version of "4880bis" as LibrePGP and announcing that GnuPG would not support the future specification based on crypto-refresh. Koch considers his more gradual approach to be more reasonable.^[24]

RFC 9580, the finalized version of crypto-refresh, was published in July 2024.

In addition, OpenPGP (with PGP/MIME) is referenced in many derived and/or related standards, including NIST Special Publication 800-177 Trustworthy Email.

In October 2017, the ROCA vulnerability was announced, which affects RSA keys generated by buggy Infineon firmware used on Yubikey 4 tokens, often used with OpenPGP. Many published PGP keys were found to be susceptible.^[29] Yubico offers free replacement of affected tokens.^[30]

In May 2018, a bug named EFAIL was found to be present in certain implementations of PGP/MIME since 2003.^[31][32] The bug allowed for injecting content before and after the encrypted email; with some HTML code this can lead to the plaintext being sent to a remote server.^[33] Neither the OpenPGP specification or the PGP/MIME specification was broken.^[34]

With the advancement of cryptography, parts of OpenPGP have been criticized for being dated:

Large public keys

OpenPGP public keys (pubkeys) may include a lot of extraneous information; these fields are commonly included for historical reasons.^[35] For example, the pubkey includes a field for a photo ID in JPEG format, intended to be checked during key signing parties.^[36]

OpenPGP has conventionally used RSA, which requires keys thousands of bits long. This is mitigated by the use of newer elliptic curve options defined in RFC 6137, but using a key thousands of bits smaller is of no use when kilobytes of extra information is included.^[35]

Because the public keys are too long for human memorization, visual checking, or simple copy-and-paste (compare SSH pubkeys),^[37] there is a reliance on key servers and key fingerprints in the transferring and authentication of keys. These elements of added complexity has allowed security lapses such as collisions of the last 32 bits of the fingerprint and GnuPG (previously) not checking the fingerprint of the actual received key.^[35]

Another element of commonly-included but unnecessary information is signatures on the key made by other people, originally supposed to be used on the web-of-trust as endorsements of the key matching its supposed holder's identity. Key servers had traditionally allowed for merging these signatures from other people onto its existing record of a key, allowing a "signature-spamming attack" wherein lots of bogus signatures are attached to the keyserver copy of the key. The key then becomes large and very slow to process. Such an attack against the public keys of prominent developers of GnuPG happened in 2019.^[38]

Complex key management

The web-of-trust design used in PGP means that the user is actively involved in key management, in contrast to more successful end-to-end encrypted systems that offer transparent key management.^[35] Partly due to this complexity, the web-of-trust strong set remains small, limiting the ability of new users to be recognized by other parts of the WoT. The overall userbase is also small with only 4 million keys having been ever uploaded to the PKS keyserver pool, limiting the reach of OpenPGP users.^[39]

Long key lifetimes

OpenPGP conventionally encourages the use of public keys that last a long time (at least 1 year). This means the key is subject to a longer window of possible exposure as any lapse during this period could result in leakage.^[37][40] In addition, because the key lives on for a long time, PGP does not provide forward secrecy (which involves disposing of the encryption key to render messages unreadable).^[35]

Outdated defaults

Backwards compatibility of the OpenPGP standard results in usage of relatively weak default choices of cryptographic primitives (CAST5 cipher, CFB mode, S2K password hashing).^[37] Also, RSA encryption uses a padding format very similar to the vulnerable scheme from PKCS#1v1.5 (see PKCS 1 § Attacks).^[35]

Insecure implementations

Popular end-user implementations have suffered from various signature-stripping, cipher downgrade and metadata leakage vulnerabilities which have been attributed to the complexity of the standard.^[41] GnuPG, the single most commonly-used implementation, is especially known for a long track record on the Common Vulnerabilities and Exposures database.^[37] In 2025, a collection of 14 vulnerabilities in OpenPGP implementations were released at the Chaos Communication Congress, 11 of which affected GnuPG. LWN.net reported on responses to this "gpg.fail" presentation on the oss-security mailing list.^[42]

Bad user experience

OpenPGP e-mail clients make it very easy to mistakenly sent an e-mail unencrypted, partly because PGP/MIME is intended to retain compatibility with unencrypted email (in a signature-only mode). It is also easy to encrypt the e-mail for the wrong person's key.^[35]

As mentioned before, Werner Koch has forked the OpenPGP standard into LibrePGP, listing his criticism of RFC 9580 on its website, including a "proliferation for algorithms" (addition of new required algorithms), removal of the filename-signature mechanism present in 4880bis, and removal of two metadata flags.^[43] LibrePGP is implemented by GnuPG and RNP, two early implementers of 4880bis. RNP had published a separate announcement praising the direction of LibrePGP.^[44]

Andrew Gallagher published a web page in 2024 listing two theoretical attacks and one practical attack against LibrePGP. This includes the aforementioned version confusion fixed in the crypto-refresh fork after the split.^[45] Another theoretical attack affected both legacy OpenPGP/LibrePGP and CMS (the core of S/MIME).^[46]

• OpenPGP::SDK
• MIT Public Key Directory for Registration and Search
• List of public keyservers
• IETF OpenPGP working group
• OpenPGP Alliance