Understanding OpenPGP and How Email Encryption Works
Pretty Good Privacy, commonly abbreviated as PGP, was created by Phil Zimmermann in 1991. Over three decades later, the underlying specification—maintained as an open standard known as OpenPGP by the Internet Engineering Task Force (IETF)—remains one of the primary methods for securing electronic mail. To understand its relevance today, it is necessary to examine how the system operates under the surface.
OpenPGP relies on asymmetric cryptography, which pairs two mathematically related keys:
- Public Key: Shared openly with anyone who wants to send you an email. It can encrypt content, but it cannot decrypt it.
- Private Key: Kept strictly confidential on your personal device and protected by a passphrase. It decrypts messages scrambled with your matching public key.
In practice, modern implementations combine asymmetric encryption with symmetric encryption to ensure speed. The software generates a random, single-use session key to encrypt the actual message body and attachments using algorithms such as AES. That short session key is then encrypted using the recipient's public key. OpenPGP also allows digital signatures: by signing a message hash with your private key, recipients can verify with mathematical certainty that the text originated from you and was not altered in transit.
Key Benefits That Keep the Protocol Alive
Despite its age, OpenPGP possesses several architectural strengths that closed-source or proprietary messaging services struggle to match. These properties keep it relevant among systems administrators, privacy advocates, and security researchers.
The first advantage is decentralization. OpenPGP does not depend on a single corporation, identity provider, or proprietary server network. You can generate a key pair locally on an offline machine using free software such as GnuPG (GPG), exchange keys directly with peers, and communicate across any standard email service, whether self-hosted or provided by an enterprise.
Second, OpenPGP provides true client-side end-to-end encryption. When implemented properly on your desktop or mobile device, the email service provider—whether it is Google, Microsoft, or an independent host—transports only an unreadable block of ciphertext, beginning with the standard ASCII header:
-----BEGIN PGP MESSAGE-----
Version: OpenPGP
...
-----END PGP MESSAGE-----Recent revisions to the standard, notably RFC 9580 (colloquially called the OpenPGP Crypto Refresh), have modernized the cryptographic primitives. The specification officially deprecates older, weaker algorithms like SHA-1 and encourages the default use of modern elliptic curves, such as Ed25519 for signatures and Curve25519 for key exchange, offering robust security with smaller key sizes.
Persistent Usability Hurdles for Everyday Users
The principal critique of OpenPGP has always centered on user experience. Even today, the protocol demands a high degree of technical understanding from both participants in an exchange. If one party makes a mistake, the entire security model collapses.
Key distribution and verification present the largest barrier. Historically, users relied on a decentralized "Web of Trust" and public keyservers. However, the legacy SKS keyserver network suffered from structural flaws, including the inability to delete keys or prevent certificate poisoning (where attackers attach thousands of fake signatures to a public key to break client software). Modern keyservers, like keys.openpgp.org, mitigate this by verifying email addresses before publishing and stripping unauthorized signatures, but discovering authentic keys still requires deliberate effort.
Furthermore, human error remains a persistent threat. If you misplace your private key without a backup, your encrypted archive becomes permanently unreadable. If you do not create and store a revocation certificate, you cannot inform the world that a compromised or abandoned key should no longer be trusted.
The Inherent Metadata Dilemma
A critical limitation of OpenPGP stems from the email standard itself. The original internet mail protocols, defined in documents like RFC 5322, were designed in an era when networks were small and trust was assumed. As a result, email routing requires cleartext headers.
OpenPGP encrypts the message payload—the text and the attachments—but it natively leaves the outer transport metadata visible to every router, intermediate server, and surveillance entity along the network path. Exposed information includes:
- The sender address and recipient address
- The exact timestamp of transmission
- The internet protocol (IP) address of the originating mail client (unless routed through Tor or a VPN)
- The subject line (in standard implementations, though some extensions attempt to encapsulate the subject inside the encrypted payload)
In high-risk environments, metadata can be just as damaging as message content. An adversary monitoring an email connection can easily map who is communicating with whom, how frequently, and at what times, regardless of the strength of the encryption protecting the body of the message.
Integrated Services Versus Manual Key Handling
To overcome usability obstacles, commercial email platforms have introduced automated implementations of OpenPGP, shifting the responsibility of key management away from the user.
Proton Mail is the most prominent example. Under the hood, Proton uses OpenPGP libraries (such as OpenPGP.js). When sending an email between two Proton accounts, the platform handles key discovery, encryption, and decryption automatically within the browser or mobile application. Users can also import external PGP public keys to exchange encrypted mail with outside contacts who run software like Mozilla Thunderbird with native OpenPGP support, or Mailvelope on standard webmail.
In contrast, other secure email providers have abandoned OpenPGP entirely. German-based provider Tuta (formerly Tutanota) built a custom cryptographic architecture. Tuta encrypts the entire mailbox, including subject lines and contact lists, and is actively transitioning toward post-quantum encryption protocols. The trade-off is clear: Tuta sacrifices external interoperability with standard email clients to fix PGP's metadata and architectural legacy issues.
OpenPGP Compared to Modern Secure Messaging
For personal communication, standalone messaging apps have largely superseded encrypted email. Protocols like the Signal Protocol—used by Signal and integrated into WhatsApp—provide cryptographic guarantees that standard OpenPGP cannot match.
The most significant difference is Perfect Forward Secrecy (PFS). In a traditional OpenPGP email exchange, a single long-term private key is used to decrypt all incoming mail. If an adversary records your encrypted email traffic for five years and eventually compromises that private key, every past message is decrypted simultaneously.
Modern messaging protocols employ continuous key ratcheting. They negotiate ephemeral, single-use keys for every message or session. If a key is compromised today, an attacker cannot read yesterday's conversations or tomorrow's. While theoretical drafts exist to bring ratcheted key exchange to email, the asynchronous, disconnected nature of the mail system makes forward secrecy exceptionally difficult to deploy in standard OpenPGP clients.
Evaluating Whether OpenPGP Fits Your Threat Model
Whether OpenPGP is worth using depends entirely on what you are trying to protect and who you are communicating with. Security is never absolute; it is a balance of operational friction against realistic threats.
OpenPGP remains a compelling, practical choice if:
- You need independent, vendor-agnostic encryption that does not tie your identity to a single application vendor or phone number.
- You sign software packages, code commits (via Git), or digital documents where message origin verification is paramount.
- You must communicate with organizations, journalists, or whistleblowing channels that maintain established public PGP keys.
- You already utilize a desktop email client like Thunderbird or Apple Mail (with third-party tooling) and are comfortable managing cryptographic backups.
Conversely, for everyday peer-to-peer conversations, sensitive personal discussions, or users seeking protection against metadata surveillance, modern end-to-end encrypted messaging applications provide superior privacy, forward secrecy, and usability. For most general consumers, managing raw PGP keys manually will represent more complexity than benefit, whereas automated implementations or dedicated secure messengers offer stronger default security with far less friction.