What Is PGP Encryption Explained: How It Works

What is PGP encryption explained in one sentence: it is a hybrid cryptographic system that combines a one-time symmetric session key with public-key encryption to let two strangers exchange confidential messages over an untrusted channel without sharing a secret in advance. That sentence packs in the reason PGP has remained relevant for over 30 years, so it is worth unpacking each part.

The Core Mechanics: A Hybrid System

PGP stands for Pretty Good Privacy. Phil Zimmermann released the first version in 1991 as a tool for activists and journalists to communicate outside the reach of government wiretapping. The name was deadpan; the cryptography was serious.

The standard version of PGP works like this:

1. Session key generation. When you encrypt a message, PGP generates a random single-use symmetric key (the session key). Modern implementations use AES-256 for this step.

2. Message encryption. The session key encrypts the actual message content. Symmetric encryption is fast, which matters for attachments or long threads.

3. Session key encryption. PGP then encrypts the session key itself using the recipient’s public key — typically an RSA or Elliptic Curve (X25519/X448 in current OpenPGP v6) key pair. Only the recipient’s corresponding private key can unlock it.

4. Transmission. Both the encrypted message and the encrypted session key travel together. The recipient decrypts the session key with their private key, then uses that session key to decrypt the message.

This two-layer approach solves a fundamental problem: public-key operations (RSA, ECC) are computationally expensive on large payloads. By confining asymmetric operations to the small session key, PGP stays fast while keeping the security guarantees of public-key cryptography.

Digital Signatures: Proving the Message Came from You

Confidentiality is half the problem. The other half is authentication — confirming the message actually came from the claimed sender and was not altered in transit.

PGP handles this with digital signatures. When you sign a message:

1. PGP generates a hash (SHA-256 or similar) of the message content.
2. That hash is encrypted with your private key — the inverse of normal encryption.
3. The recipient decrypts the signature with your public key and checks whether the hash matches the message they received.

If the hashes match, two things are confirmed: the message came from whoever controls that private key, and the content has not been tampered with since it was signed. These properties are called authentication and integrity.

You can sign without encrypting (useful for publishing verified announcements) or encrypt without signing (useful when anonymity matters more than attribution), or do both at once.

The OpenPGP Standard and RFC 9580

PGP itself is proprietary software, but the message format was standardized as OpenPGP, allowing competing implementations to interoperate. The latest standard, RFC 9580, was published by the IETF in July 2024. It obsoletes RFC 4880 (2007) and consolidates updates for elliptic curve cryptography and algorithm deprecations.

RFC 9580 introduces OpenPGP version 6, which formalizes support for X25519 and X448 key pairs and deprecates legacy algorithms that had weakened over time. Implementations with support for v6 include Sequoia PGP (since version 2.0.0), OpenPGP.js, and GopenPGP — the library behind Proton Mail’s E2EE email encryption.

The practical consequence: if you generate a new key pair today with a modern client, you will get a v6-format key using current recommended curves. Keys generated before RFC 9580 implementations became widespread may still use RSA-2048 or the older Curve25519 format; they remain valid but will eventually need rotation.

Key Distribution: The Web of Trust vs. Key Servers

PGP does not have a central certificate authority the way HTTPS does. Instead, it relies on a web of trust: users digitally sign each other’s public keys to vouch for their authenticity. If you trust Alice, and Alice has signed Bob’s key, you have indirect reason to trust Bob’s key is genuine.

In practice, the web of trust works well in small communities and poorly at scale. Most people skip it. Common alternatives:

• Key servers (keys.openpgp.org, SKS pool): public directories where you upload your key and others search by email address. The risk is that anyone can upload a key claiming to be you.
• Verified publishing: post your public key fingerprint on your own website, your GitHub profile, or in your email signature. Recipients manually verify the fingerprint before trusting the key.
• TOFU (Trust On First Use): accept the first key seen for a given address, flag any future change. Used by several email clients.

Key distribution is the hardest usability problem in PGP. Getting the cryptography right matters less than ensuring you are encrypting to the correct recipient’s key. A threat actor who can substitute their key for your contact’s key in transit can read everything you think you are encrypting securely.

When PGP Actually Protects You

PGP protects against specific threats. It does not protect against all of them.

PGP is effective against:

• Server-side compromise: even if an email provider’s servers are breached, encrypted ciphertext reveals nothing to the attacker.
• ISP interception: your ISP can see you sent an email and to whom, but not what it contained.
• Subpoenas targeting email content: if the provider cannot decrypt the message, they cannot hand it over. This is why encrypted email providers can credibly claim they cannot read your mail.
• Long-term confidentiality: messages encrypted with strong keys remain confidential even years later, assuming the private key stays secure.

PGP does not protect against:

• Metadata: PGP encrypts the message body but not the To/From/Subject headers in most implementations. Your ISP and provider still see who you are communicating with, which is the exposure an email security threat model has to account for separately.
• Endpoint compromise: if an attacker has access to your device or private key, encryption provides no protection. PGP is a channel protection, not a device protection.
• Phishing, social engineering, or malware that intercepts messages before they are encrypted. An attacker who captures the plaintext at the keyboard never has to defeat the cryptography.

Getting Started: What You Actually Need

To use PGP for email today, you need three things:

1. A key pair. Generate one with GPG (available on all platforms via gpg --gen-key), Kleopatra on Windows, or GPG Suite on macOS. Use the defaults unless you have specific requirements; modern clients will select current recommended algorithms.

2. Your recipient’s public key. Search keys.openpgp.org by their email address, or ask them to send it directly. Verify the fingerprint out-of-band (phone call, Signal, in person) before trusting it for sensitive content.

3. An email client that supports PGP. Thunderbird has native OpenPGP support since version 78. Proton Mail and Tuta handle key management automatically for mail between their own users; Proton Mail supports manual PGP key import for external contacts.

For the command-by-command version of all three steps — GPG installation per platform, key generation and backup, Thunderbird and Proton Mail configuration, and fingerprint verification — see how to set up PGP for email.

If the mailbox you need to add PGP to is Gmail, there is no native support and the route runs through a browser extension instead — how to set up PGP encryption in Gmail covers FlowCrypt and Mailvelope step by step. If it is Outlook, PGP is not the mechanism Microsoft supports at all; S/MIME and Purview are, and how to encrypt email in Outlook compares them.

The honest caveat: PGP is most useful when both parties are using it. Encrypting an email to someone who reads it in Gmail means your message sits in plaintext on Google’s servers the moment it arrives. The security guarantee is asymmetric — it protects your outbound copy in transit, but the endpoint determines whether it stays protected at rest.