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. 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. 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.
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 base specification is (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.
The additional specification (June 2026) defines Post-Quantum Cryptography in OpenPGP, based on ML-KEM composite public key encryption and ML-DSA composite public key signatures, both in combination with Elliptic Curve Cryptography (ECC), as well as SLH-DSA as a standalone public key signature scheme.
Design
(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.
PGP fingerprint A public key fingerprint is a fixed-length unique identifier of a public key. By comparing fingerprints, a recipient can validate that they have obtained the expected public key. A fingerprint such as C959 BDBA FA32 A2F8 9A15 3B67 8CFD E121 9796 5A9A can be printed on a business card.
Compatibility 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.
See § Version history below for a list of version codes.
Confidentiality PGP can be used to send messages confidentially. 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.
Digital signatures 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.
Web of trust
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:
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.
Certificates
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.
Implementations
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). Several other vendors have also developed OpenPGP-compliant software. GnuPG implements RFC 4880, and more recently 4880bis.
PGP implements OpenPGP, but the GnuPG documentation notes a number of departures from the standard in versions 6 and 7.
RNP (the library used by Mozilla Thunderbird) implements RFC 4880, 4880bis/LibrePGP, and (unannounced on its website, but available as a build option) RFC 9580.
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, has allowed web-based applications to use PGP encryption in the web browser.
Libraries that feature comprehensive support for RFC 9580 include Bouncy Castle Java (since version 1.82), GopenPGP (since version 3.0.0), hOpenPGP (since version 3.6), OpenPGP.js (since version 6.0.0), PGPainless (since version 2.0.0), rnp (since version 0.18), rPGP (since version 0.14.0), Sequoia-PGP (since version 2.0.0).
OpenPGP.org provides a list of implementations with a focus on the current version 6 (RFC 9580). A list is provided in OpenPGP.dev, an online book describing RFC 9580.
Integration The open source office suite LibreOffice implemented document signing with OpenPGP as of version 5.4.0 on Linux.
PGP keys are supported in Mozilla Thunderbird (Built-in in version 78 onwards on PC, and with the OpenKeychain app as of version 9 on Android), GitHub, and GitLab.
History
PGP RFCs 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 , an Informational document titled "PGP Message Exchange Formats". This document described PGP version 2.x (packet versions 2 and 3).
A contemporary specification, of October 1996, specified PGP/MIME, a way to embed PGP messages into e-mail.
Version 4 RFCs 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. This effort culminated in of November 1998, which additionally described the format used by the "PGP 3" still in prototype stage (packet version 4).
The next standard, 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".
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").
Schism
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 key and signature packets with version 5, and new AEAD encryption modes. According to the timeline on the LibrePGP website, support for 4880bis 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.2 of July 2020.
In April 2020, Vincent Breitmoser, the author of OpenKeychain, an OpenPGP extension for K-9 Mail on Android, sent a message to the IETF OpenPGP working group email list, titled "Requesting the editor to step down" in which he outlines complaints about Werner Koch's work in the role as editor of the rfc4880bis draft.