What PGP encryption is (and what it isn’t)

PGP (often used as shorthand for OpenPGP) is a way to protect digital communication with cryptography. It can provide two related benefits:

  • Confidentiality: messages are encrypted so only someone with the matching private key can read them.
  • Authenticity/integrity: messages can be digitally signed so recipients can detect tampering and verify that the signature matches a trusted public key.

PGP is not the same as “secure browsing” or a VPN. It typically protects the contents of messages/files you encrypt and/or sign. It does not automatically protect every detail around your communication (for example, who contacted whom, when, or routing metadata).

How PGP works in practice

PGP is built on public-key cryptography, which uses key pairs:

  • A public key can be shared with others.
  • A private key must be kept secret by the key owner.

A typical encrypted message flow looks like this:

  1. You obtain the recipient’s public key.
  2. Your software creates a new session key for this specific message.
  3. The message is encrypted using that session key.
  4. The session key is encrypted using the recipient’s public key.
  5. The recipient uses their private key to recover the session key and decrypt the message.

For signatures:

  1. The sender signs the message (or a cryptographic hash of it) with their private key.
  2. The recipient verifies the signature using the sender’s public key.
  3. If the signature is valid, the recipient can be confident the message was produced by the private key holder (within the limits of how trust is established).

In real tools, these steps happen automatically, but understanding them helps you spot failure modes—most problems are about keys and trust, not the underlying math.

Limitations and boundaries that matter

PGP can be strong, but its real-world effectiveness depends on operational details:

Key trust is the critical dependency

Even though signatures can be mathematically verified, you still need to decide which public keys you trust for a given person or identity. If you accept the wrong key as “belonging” to someone, you may encrypt to an attacker or verify the attacker’s signature.

Because PGP trust often involves manual steps (like obtaining public keys from a reliable channel or verifying key fingerprints), mistakes here can outweigh cryptographic strength.

It protects content, not everything around it

PGP generally focuses on confidentiality and integrity of message bodies or files you encrypt/sign. It does not automatically hide:

  • Email/service metadata (depending on how messages are sent and stored)
  • Communication patterns
  • Whether someone can see that a message exists

If your goal is broader privacy, you may need additional measures, but PGP alone should not be assumed to cover all tracking.

Backups, device compromise, and key loss

If your private key is stolen, an attacker who has it may decrypt your past and future messages (depending on how you and recipients manage keys). If your private key is lost and you don’t have a recovery path, you may not be able to decrypt new or existing messages.

This is why secure key storage, passphrase protection, and sensible backup/recovery planning are part of “using PGP.”

Decryption errors are sometimes user errors

Common issues include attempting to decrypt with the wrong private key, using a private key that doesn’t match the sender’s expected public key, or importing keys incorrectly. Tools may show an error that looks cryptographic, but the cause can be practical.

Practical checks you can do before relying on PGP

If you want to use PGP responsibly, you can perform verification steps that don’t require faith in the software:

  • Verify signatures: When you receive a signed message, check that the signature is reported as valid by your client.
  • Check key fingerprints: Confirm the fingerprint of the public key used for verification (e.g., out-of-band or via a channel you trust). This reduces the risk of accepting an impostor key.
  • Confirm the key you’re using for encryption: Make sure you’re encrypting to the intended recipient’s public key, not a stale or similarly named one.
  • Look for clear status indicators: Use your client’s displayed trust and validity state (for example, warnings about unknown keys). Treat warnings as signals to pause, not as noise.
  • Test with a non-sensitive message: Before sending important content, send a small encrypted test and confirm that you can decrypt and verify signatures on both ends.

These checks help you answer the operational questions: “Do I have the right key?” and “Did the message stay unmodified?”—which are the questions PGP can actually answer.

PGP sits within a broader ecosystem of cryptographic ideas:

  • Public-key cryptography: the foundation for encrypting to and verifying with keys.
  • Digital signatures: a mechanism to detect tampering and support authenticity.
  • Web of trust / trust models: some PGP workflows rely on establishing trust through relationships and endorsements; others may rely more on explicit verification. Your chosen trust model affects how confidently you can map keys to identities.
  • Key management: generating, rotating, revoking, and distributing keys.

Understanding these concepts won’t replace good practice, but it clarifies what PGP can and cannot guarantee.

If you’re unsure whether a particular PGP setup is appropriate for your situation, treat the limiting factor as “key trust and workflow,” not the PGP algorithm itself.