Pretty Good Privacy (PGP), originally designed by Phil Zimmermann in 1991 and formally codified as the OpenPGP standard (historically RFC 4880, updated in RFC 9580), remains one of the foundational building blocks of decentralized digital sovereignty. At its core, PGP solves two classic cryptographic dilemmas: how to exchange confidential data across untrusted media without pre-sharing a secret key, and how to verify the authenticity and integrity of that data beyond mathematical doubt. Rather than relying on a single cryptographic primitive, PGP operates as a hybrid cryptosystem that orchestrates symmetric encryption, asymmetric public-key cryptography, cryptographic hashing, and data compression into a unified protocol.
The Core Mechanism: Hybrid Cryptography Explained
Public-key cryptography, such as RSA or elliptic curve algorithms, relies on computationally expensive mathematical operations like modular exponentiation or scalar multiplication on discrete curves. Encrypting large payloads—such as multi-megabyte documents, source code repositories, or disk images—directly with an asymmetric key is computationally prohibitive and architecturally unsuitable. Symmetric ciphers, such as AES-256 or Camellia, operate orders of magnitude faster and handle arbitrary data streams efficiently, but they require both parties to share an identical secret key beforehand.
PGP resolves this fundamental tension through hybrid cryptography. The operational workflow bifurcates the encryption of the payload from the transmission of the decryption key:
- Payload Encryption: The sender's software generates a cryptographically secure, ephemeral symmetric key known as the session key ($K_s$). The actual message payload is encrypted using this session key via a robust symmetric cipher (typically AES-256 in modern implementations).
- Key Encapsulation: The session key itself is then encrypted using the recipient's public asymmetric key. Because the session key is small (usually 128 to 256 bits), the asymmetric operation completes almost instantaneously.
- Packet Assembly: The encrypted session key and the symmetrically encrypted payload are bundled into standardized OpenPGP packets and transmitted together.
The recipient reverses this sequence: their private asymmetric key decrypts the small session key, which is then used to decrypt the larger symmetrically encrypted message. If a message has multiple recipients, the software encrypts the same single-use session key multiple times—once for each recipient's public key—and prepends each encrypted key packet to the single encrypted payload packet, avoiding redundant ciphertext duplication.
Message Flow: The Cryptographic Pipeline
An OpenPGP implementation, such as the open-source GnuPG (GPG) suite, does not merely encrypt raw data; it processes input streams through a deterministic, layered pipeline designed to optimize security, transportability, and size.
Data Compression
Before any encryption occurs, the plaintext is usually compressed using algorithms like ZIP, ZLIB, or BZip2. This serves two vital defensive purposes. First, it reduces transmission bandwidth. Second, and more importantly from a cryptanalytic perspective, compression flattens the statistical redundancy and language-specific patterns of the plaintext, significantly frustrating frequency analysis attacks against older ciphers.
Symmetric Encryption and Integrity Protection
The compressed data is packaged into an integrity-protected container. In current standards, this is handled by the Symmetrically Encrypted and Integrity Protected Data (SEIPD) packet. Historically, unauthenticated OpenPGP encryption was vulnerable to cipher block manipulation attacks (such as the Efail vulnerability family). Modern SEIPD packets (SEIPD v1 with SHA-1 Modification Detection Codes, and SEIPD v2 defined in RFC 9580 utilizing Authenticated Encryption with Associated Data, or AEAD, such as OCB or GCM modes) guarantee that any bit-flipping or injection in transit will cause immediate decryption failure before data is processed by the host application.
ASCII Armoring
Cryptographic operations output raw binary streams. Because legacy communication channels (such as SMTP mail gateways) often strip or alter non-ASCII characters, OpenPGP uses a mechanism called ASCII Armor. This encodes raw binary packets into standard 7-bit ASCII using a modified Radix-64 format, appending a cyclic redundancy check (CRC) checksum at the tail to detect line-ending corruption or truncation during transit:
-----BEGIN PGP MESSAGE-----
hQGMA4xT... [Base64-encoded binary OpenPGP packets] ...
=abcd
-----END PGP MESSAGE-----Digital Signatures and Authentication
Confidentiality is meaningless if the sender's identity can be spoofed. PGP addresses this through non-repudiation and cryptographic integrity checks using digital signatures. A digital signature operates in the inverse mathematical direction of asymmetric encryption: it is produced by the sender's private key and verified by anyone holding the sender's corresponding public key.
The signature generation process follows strict protocol stages:
- Hashing: The sender's software computes a cryptographic hash of the plaintext (such as SHA-256 or SHA-512). This reduces an arbitrary-length message to a fixed-length digest.
- Signing the Digest: The hash digest, along with metadata (such as timestamps and signature type), is signed using the sender's private signing key. With algorithms like Ed25519 (EdDSA) or RSA, this mathematically ties the digest to that exact key pair.
- Simultaneous Signing and Encryption: When a user signs and encrypts a message, the signature packet is generated first and embedded inside the encrypted envelope alongside the plaintext. This ensures that passive eavesdroppers inspecting the ciphertext cannot even determine whether a digital signature exists, let alone view the identity of the signer.
A valid PGP signature guarantees two immutable facts: the content has not been modified by a single bit since the signature was generated, and the entity that generated the signature possessed the specific private signing key associated with the public key.
Key Architecture: Primary Keys vs. Subkeys
A common point of confusion for new practitioners is that an "OpenPGP key" is almost never a single key pair. Instead, it is an integrated collection of keys consisting of a Primary Certification Key and one or more specialized Subkeys.
OpenPGP categorizes cryptographic capabilities using distinct key usage flags:
- [C] Certification: Held exclusively by the Primary Master Key. Its sole purpose is to sign other keys, create or revoke subkeys, and sign user identity packets (User IDs).
- [S] Signing: Used to produce cryptographic signatures on documents, emails, and software commits.
- [E] Encryption: Used to encapsulate session keys for inbound encrypted communications.
- [A] Authentication: Used for challenge-response authentication, such as replacing SSH keys or logging into remote systems.
In secure operational practice, the primary master key is never stored on a daily-driver machine. Security researchers and privacy-conscious users generate the master key on an air-gapped machine, export the operational subkeys ([S], [E], [A]) to active machines or hardware security tokens (like smartcards or YubiKeys), and keep the primary master key completely offline in cold storage. If an endpoint device is compromised or physically seized, the attacker acquires only the subkeys. The defender simply connects their offline master key, issues a cryptographic revocation certificate for the compromised subkeys, generates new subkeys, and distributes the update—all without changing their core public identity or invalidating their existing Web of Trust relationships.
Identity, Verification, and the Web of Trust
Unlike TLS, which relies on a centralized hierarchy of commercial Certificate Authorities (CAs) to assert that a domain name matches a public key, PGP was designed around a decentralized model: the Web of Trust (WoT). In the OpenPGP model, anyone can certify anyone else's public key by applying a digital signature over that key and its associated User ID (Name and Email).
The primary vulnerability in public-key cryptography is the adversary-in-the-middle attack: an attacker replaces the intended recipient's public key with their own, intercepts the ciphertext, decrypts it, re-encrypts it with the true recipient's key, and forwards it unnoticed. To defend against this, the recipient's identity must be validated using their immutable Key Fingerprint.
A fingerprint is a cryptographic hash of the public key's fundamental components: the key creation time, algorithm parameters, and public exponent/modulus. For modern keys, this is rendered as a 40-character hexadecimal string, often grouped into blocks:
pub ed25519 2024-01-15 [SC]
8F3A 2B1C 9D0E 4F5A 6B7C 8D9E 0F1A 2B3C 4D5E 6F7A
uid Alice <[email protected]>
sub cv25519 2024-01-15 [E]Modern OpenPGP workflows have largely shifted away from large, global Web of Trust keyservers—which suffered from denial-of-service vulnerabilities via un-deletable spam certificates—toward direct, authenticated discovery models. These include:
- Web Key Directory (WKD): A protocol where mail server administrators host their users' public keys at a deterministic HTTPS path (e.g.,
https://example.org/.well-known/openpgpkey/...), allowing automated, domain-authenticated key retrieval. - Direct Fingerprint Verification: Out-of-band verification via voice, cryptographic messaging apps, or secure hardware-scanned QR codes, entirely bypassing third-party discovery infrastructure.
Modern Implementations: Legacy RSA vs. Modern Curves
The OpenPGP standard has evolved continuously. The updated RFC 9580 specifies the version 6 (v6) OpenPGP format, resolving structural legacy quirks dating back to the 1990s. While 4096-bit RSA keys were the standard recommendation for over a decade, modern configurations prefer Edwards-curve (Ed25519) and Montgomery-curve (Curve25519) cryptography.
Elliptic curve implementations provide significant security and practical benefits:
- Shorter Key Lengths: A 256-bit Curve25519 key delivers approximately 128 bits of symmetric security equivalence—comparable to a bulky 3072-bit RSA key—greatly reducing packet sizes and metadata overhead.
- Side-Channel Resistance: Curve25519 algorithms are specifically designed to execute in constant time, eliminating timing attacks that historically targeted variable-time RSA modular arithmetic operations.
- Modern Key Derivation: Transitioning from older String-to-Key (S2K) algorithms like iterated-and-salted S2K (vulnerable to high-throughput GPU cracking) to memory-hard key derivation functions like Argon2, which protects passphrases securing private key files on disk.
Defensive Utility and Residual Metadata Risks
PGP provides robust, mathematically verifiable confidentiality and integrity for the contents of a payload. However, threat modeling requires understanding its boundaries. PGP encrypts the body of a transmission, not its surrounding communication metadata. When used for email via standard OpenPGP/MIME:
- The To, From, Date, and message transit routing headers are transmitted in plaintext across every intermediate mail transfer agent.
- Subject lines are, by default, unencrypted in legacy clients (though contemporary clients mitigate this using "Memory Hole" / RFC 7508 encrypted headers).
- Traffic analysis can deduce that two endpoints are communicating, the frequency of their exchanges, and the approximate size of the encrypted payloads.
For high-risk individuals—such as investigative journalists handling classified leaks, human rights observers in hostile territories, or software maintainers signing release binaries—PGP remains an essential tool when deployed correctly. By combining offline primary keys, modern authenticated ciphers (RFC 9580), verified fingerprints, and metadata-aware operational security, PGP provides verifiable end-to-end cryptographic control completely independent of centralized cloud platforms or third-party authority.