Surveying Pretty Good Privacy After Three Decades
Historical Background
Philip Zimmermann released the first version of Pretty Good Privacy in 1991. With support for encrypting email messages, PGP offered confidentiality, but also raised concerns related to United States export regulations. After navigating the legal issues, Zimmermann founded PGP Inc, which proposed the creation of a public standard named OpenPGP in 1997. The OpenPGP Working Group codified format requirements under RFC 2440 in 1998, and released the current specification under RFC 4880 in 2007. Three decades after initial publication, Pretty Good Privacy is not without detractors, but it still provides a common protocol for message encryption and digital signatures.
In conjunction with the standardization of OpenPGP, Werner Koch developed GNU Privacy Guard, which has served as the de facto open source implementation of the format since the initial version in 1997. With the PGP trademark and commercial ownership changing hands over the years, GnuPG became common enough that some applications use the acronym GPG in place of PGP. In addition to various commercial products, numerous open source projects, plugins, and libraries have grown up around the OpenPGP standard.
Cryptographic Features
Implementing and using cryptography can be complicated, particularly in reference to OpenPGP. With support for both symmetric-key and public-key encryption, as well as a wide array of cryptographic hash functions, selecting an optimal configuration can be challenging. Some researchers have highlighted this flexibility as a fundamental design flaw. Others have touted the adaptability of the standard as a beneficial feature. Understanding basic functionality as well as the current capability gaps is helpful when considering any implementation. With a grasp of the foundational concepts, reading additional resources can provide a better understanding of the features and weaknesses of OpenPGP.
Password-Based Encryption
OpenPGP supports both password-based encryption and public key encryption. Password-based encryption involves using the same word or phrase for both encryption and decryption. Although this method is simple to understand and configure, it is subject to brute-force attacks. The fundamental security of password-based encryption relies on the length, complexity, and protection of the password used. OpenPGP specifies several variations of a String-to-Key function, which implementing libraries use to derive an encryption key from a password. The Iterated and Salted S2K variation is the best current option, but lacks features such as memory and parallelism cost factors found in newer functions like Argon2.
Public Key Encryption
Public key encryption is an asymmetric operation where the key material consists of a public key and a private key, known as a key pair. Applications use the public key for encryption and the private key for decryption. The relationship between the public and private components allows for open distribution of the public key, while ensuring that only the associated private key can perform decryption. This approach is one of the building blocks of the Transport Layer Security protocol, which provides a common security standard for Internet protocols such as HTTPS. Although OpenPGP is not a network protocol, similar key algorithms provide the foundation for both standards.
Hybrid Implementation
Building on these concepts, OpenPGP uses public key encryption to protect an internal session key, which in turn protects the message contents itself. Based on this approach, OpenPGP supports several asymmetric-key formats, as well as a number of symmetric-key algorithms. As a result, the security level of OpenPGP encryption depends on a combination of selected algorithms. OpenPGP supports several public-key algorithms including RSA , DSA and ElGamal. Current implementations of the OpenPGP standard also support Elliptic-curve cryptography following the RFC 6637 specification.
Symmetric-key algorithm support includes AES operating in full-block cipher feedback mode, in addition to less common options such as Camellia and Twofish. Configurable key formats and algorithms make it challenging to evaluate the security of a particular configuration, but also illustrate the flexibility of the standard. The binary format defines specific algorithm identifiers, allowing the potential for registering new algorithms.
Message Integrity
For encrypted messages, OpenPGP supports a Modification Detection Code containing an SHA-1 hash of the original contents. The MDC provides a method for recipients to evaluate whether the decrypted message matches the original. The United States National Institute of Science and Technology deprecated SHA-1 for use in digital signature applications in 2011 due the theoretical attacks first published in 2005. Research efforts such as SHA-1 is a Shambles and SHAttered describe demonstrable collision attacks against SHA-1. The vulnerabilities in SHA-1 have a serious impact on the credibility of the Modification Detection Code for cryptographic message verification.
Digital Signatures
Distinct from encryption itself, OpenPGP also supports digital signatures using several common algorithms. While encryption provides confidentiality, making information unintelligible to unauthorized observers, signing confirms the identity of the message originator. When receiving confidential information, verifying digital signatures provides an important layer of protection against malicious senders.
Although recent addons to email processing provide ways to evaluate whether a mail server is authorized to send messages for a particular domain, the email protocol itself provides no guarantee of sender authenticity. Through the use of public-key cryptography, OpenPGP allows recipients to verify both message originator and message integrity using a trusted public key. Verification relies on both the strength of the cryptographic hash function summarizing the message and the trustworthiness of the public key. Weaknesses in the hash function can compromise message integrity, and an untrustworthy public key undermines the credibility of sender verification. In addition to the deprecated SHA-1 algorithm, OpenPGP supports several variants of SHA-2 including SHA-256 and SHA-512.
Key Distribution
Key distribution has been a common hurdle to widespread OpenPGP adoption. Direct key distribution through email provides decentralization, but does not necessarily provide high confidence for trusting a message originator. Publishing a public key allows an entity to receive encrypted messages, but does not necessarily provide strong assurances when it comes to receiving messages signed using the same public key.
Key Servers
David Shaw drafted the OpenPGP HTTP Keyserver Protocol in 2003, which described standard HTTP operations for storing and retrieving OpenPGP public keys. The HKP standard provided a common method for public key distribution, but also opened the door to abuse. Without the capability to delete entries, HKP servers have grown to contain numbers of expired public keys. Permissive rules for public key signing and uploading allowed OpenPGP Certificate Flooding, which impacted a number of prominent OpenPGP users. With the ability to add an unbounded number of signatures, malicious users increased the size of some OpenPGP public keys to the point of crashing applications such as GnuPG when importing manipulated keys.
Recent Developments
Advances in computing power and algorithm development have highlighted a number of historical issues with OpenPGP. The official format defined in RFC 4880 does not include support for current cryptographic standards such as authenticated encryption with associated data or advanced key derivation functions. Lack of modern features and support for compromised algorithms are just some of many criticisms that researchers such as Matthew Green and Latacora have leveled against OpenPGP. Signal developer Moxie Marlinspike described the technological and philosophical failures of OpenPGP in 2015. Publication of the EFAIL vulnerability prompted WIRED UK to proclaim the death of PGP in 2018.
In the same year that some declared the end of OpenPGP, the Sequoia PGP project announced development of a new OpenPGP library to address the issues inherent in GnuPG. With its release of version 1.0 in December 2020, as well as the creation a new OpenPGP key server, Sequoia PGP represents a response to a number of issues in both the standard itself and available implementations. Writing in June 2021, Sequoia developer Neal Walfield acknowledged protocol shortcomings and usability issues in OpenPGP, but also argued for the importance of continued progress.
As part of a broad protocol refresh, OpenPGP Working Group members have drafted updates to include new algorithms and related features. GnuPG 2.3.0 included support for additional encryption modes and public key algorithms, paving the way for future standard adoption. Sequoia PGP also supports authenticated encryption. Through its own implementation and maintenance of an interoperability test suite, the Sequoia project reflects a commitment to maintaining and improving OpenPGP as a common standard for interoperable encrypted messaging.
Companies such as Proton Technologies AG have made OpenPGP the foundation of their secure email solution ProtonMail. Through publication and maintenance of OpenPGP.js, ProtonMail has made significant investments in the OpenPGP standard. ProtonMail addresses some significant usability concerns around OpenPGP, while also providing interoperability with external services through publishing OpenPGP public keys. For general email integration, Thunderbird 78 introduced support for OpenPGP in 2020 without the need for external plugins.
Conclusion
In the 30 years since Zimmermann first released PGP, the technological landscape has changed in a number of notable ways. Internet bandwidth and computing capability have continued to grow, while the footprint and form factor of devices have continued to shrink. Despite numerous advancements and innovations, some technologies have persisted. The venerable Simple Mail Transfer Protocol still provides email communication more than 40 years after its creation. After various efforts to improve SMTP security, including TLS , Sender Policy Framework, and DomainKeys Identified Mail, the fundamentals of the protocol have not changed. In the face of many alternatives, email remains an established mode of communication.
OpenPGP has gone through a number of iterations, adding support for new algorithms along the way. Efforts to address shortcomings in the standard itself and historical implementations have introduced some positive changes. Although applications of OpenPGP have extended beyond email messaging, the staying power of the standard remains connected to its roots. As long as SMTP survives, it seems that OpenPGP will have a role to play.