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 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.
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 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.
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:
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.
Certificates
… excerpt ends here. Continue reading the full article.
