PGP Encryption Guide: How to Use GPG Step by Step

Pretty Good Privacy (PGP) is the de facto standard for encrypting email and files at rest. It dates to 1991, was standardized as OpenPGP (RFC 4880), and picked up modern algorithm guidance in RFC 9580 (2024). Journalists, activists, and anyone needing transport-independent confidentiality still reach for it — because adoption and tooling exist everywhere serious crypto is discussed.

This guide walks through the full setup: what PGP is, how it works, and every step from key generation to message verification.

What PGP Actually Is

PGP is an asymmetric encryption system built on the OpenPGP standard. RFC 4880 defines the data formats; RFC 9580 (2024) extends it with modern algorithm support, including X25519 and Ed448 key types. GPG — GNU Privacy Guard — is the most common open-source implementation. It's what you'll actually run on your machine.

The word "encryption" here means mathematical scrambling. Only someone holding the right private key can decrypt what you've encrypted with their public key. That's it. No central server. No company that holds a master key. If you lose your private key, your encrypted data is gone — permanently.

One nuance: PGP encrypts content, not context. Your adversary may still see who you're communicating with, when, and how often. We cover that in the threat model section below.

Public Key vs. Private Key — the Mental Model

Think of a public key as a padlock, and your private key as the only copy of its key.

You hand out the padlock (public key) freely — post it on your website, keyservers, GitHub profile.
Anyone can lock something (encrypt) using your padlock.
Only you can open it (decrypt) with your private key.

Never share your private key. Never paste it into a form, upload it to a website, or store it in cloud storage. A hardware security key like a YubiKey can hold your private key in a way that it never touches your operating system's memory. That's the gold standard, but it's optional for most threat models.

Modern key types are either RSA-4096 (widely compatible) or Ed25519 (smaller, faster, equally secure at this threat level — recommended for new keys as of 2024).

Step 1: Install GPG

macOS:

brew install gnupg

Or download GPG Suite for a GUI that integrates with Apple Mail.

Linux (Debian/Ubuntu):

sudo apt install gnupg2

Most distributions ship GPG by default. Run gpg --version to check.

Windows: Download Gpg4win — includes Kleopatra (a GUI), GpgOL (Outlook integration), and the command-line gpg binary. Version 4.3.1 was the stable release as of early 2025.

After installing, confirm with:

gpg --version

You should see GnuPG 2.x.x in the output. If you see version 1, you're running legacy GnuPG — upgrade.

Step 2: Generate a 4096-bit RSA or Ed25519 Key

gpg --full-generate-key

You'll be prompted for:

Key type — choose (1) RSA and RSA for maximum compatibility, or (9) ECC (sign and encrypt) for Ed25519 (modern, smaller, our recommendation for new setups).
Key size — 4096 if RSA. Ed25519 doesn't prompt for size.
Expiration — set one. Two years is a good default. A key with no expiration is a liability if you lose control of it.
Name and email.

Do not use your real name or email if anonymity is your goal. Use a pseudonym and a anonymous email address.

GPG will ask your OS to collect entropy while it generates the key. On Linux this is fast. On Windows or macOS it might take a few seconds. Normal.

Step 3: Set a Strong Passphrase

During key generation, GPG prompts for a passphrase. This passphrase encrypts your private key at rest. If an adversary gets your key file but not the passphrase, they can't use it.

Choose something long. A Diceware passphrase — five or six random words — is easier to remember than a random string and just as strong. The EFF has a free word list and instructions.

Don't use your regular passwords. Don't store it in a password manager unless that manager uses its own strong master key (KeePassXC is fine; cloud password managers without local unlock are not, depending on your threat model).

Step 4: Publish Your Public Key

List your keys:

gpg --list-keys

Export your public key:

gpg --armor --export [email protected] > pubkey.asc

Post it to keys.openpgp.org — the preferred modern keyserver. Unlike older SKS keyservers, keys.openpgp.org requires email verification before listing third-party signatures, which reduces spam/flooding attacks.

You can also paste pubkey.asc directly on your website, in your GitHub profile, or in your email signature. All are valid.

Step 5: Encrypt a Message

To encrypt a message for a recipient:

# Import their public key first
gpg --import their-public-key.asc

# Encrypt
gpg --armor --encrypt --recipient [email protected] message.txt

This produces message.txt.asc — a block of ASCII-armored ciphertext. Only the recipient's private key can decrypt it. Copy-paste it into an email, Signal message, or anywhere.

To also encrypt to yourself (so you can read your own sent messages):

gpg --armor --encrypt --recipient [email protected] --recipient [email protected] message.txt

Step 6: Sign and Verify a Message

A signature proves the message came from you — it didn't come from someone who found your email address.

# Clearsign (message + signature in one block)
gpg --clearsign message.txt

# Detached signature (separate file)
gpg --armor --detach-sign message.txt

To verify:

gpg --verify message.txt.asc

GPG will tell you which key signed it and whether the signature is valid. If you haven't imported the signer's public key, GPG will say it can't verify — that's expected. Import the key from the keyserver and verify again.

Signatures matter for software you download from onion sites. If the download page provides a .sig file, verify it.

Step 7: Back Up Your Private Key (and Revocation Certificate)

If your private key is gone, everything encrypted to it is gone. Back up immediately after generating.

# Export private key
gpg --armor --export-secret-keys [email protected] > private-key-backup.asc

# Export revocation certificate
gpg --gen-revoke [email protected] > revoke.asc

Store both on an encrypted offline drive. Not in cloud storage. Not on your everyday laptop.

The revocation certificate lets you tell the world "this key is compromised, stop trusting it" — even if you've lost the private key. Keep it safe, but separate from the key itself.

Common PGP Mistakes

Losing your private key. No recovery path exists. Back it up offline, at least twice.

No expiration date. A key that never expires stays "valid" even after you've abandoned it or it's been compromised. Set two years and extend as needed.

Using weak subkeys. GPG generates a primary key (for signing and certification) and subkeys (for encryption). Make sure subkeys use RSA-4096 or Ed25519 — not RSA-2048 or DSA-1024. Check with gpg --list-keys --with-subkey-fingerprint.

Encrypting with your own public key instead of the recipient's. You'll produce a ciphertext only you can read. Slow and embarrassing. Double-check --recipient.

Skipping the passphrase. Your private key file is only as protected as its passphrase. An unencrypted key file on a laptop is one theft away from complete exposure.

Relying on PGP for everything. PGP is not a metadata solution. For metadata-protected messaging, see our guide on secure messaging apps.

Threat Model — What PGP Protects Against (and What It Doesn't)

Every tool deserves a clear threat model. PGP protects against:

Content interception — an email provider, ISP, or government agency reading your message in transit or at rest on a server. The encrypted blob is useless without your private key.
Tampering — PGP signatures let recipients verify that a message hasn't been modified since you signed it.
Impersonation — if you've verified someone's public key fingerprint out-of-band, their signed messages prove authenticity.

PGP does not protect against:

Metadata — who you're emailing, when, and how often. Email metadata is visible to providers even if message content is encrypted. For metadata protection, combine PGP with Tor Browser and an anonymous email provider.
Endpoint compromise — if your device is infected with malware, your decrypted messages can be read before encryption or after decryption.
Key verification failures — if you haven't verified a recipient's key fingerprint by a second channel (phone, in-person, Signal safety numbers), you can't be sure you're not encrypting to an attacker's key. This is the MITM attack PGP's web of trust tries to solve.
Client-side scanning — emerging legislation in some jurisdictions requires apps to scan plaintext before encryption. PGP itself doesn't prevent this.

For higher-risk threat models, pair PGP with a proper threat modeling process and consider Tails OS for air-gapped operations.

Frequently Asked Questions

Is PGP still secure in 2026?

Yes. The underlying cryptography — RSA-4096 and modern elliptic curve algorithms like Ed25519 — remains unbroken by any publicly known attack. The 2024 RFC 9580 update modernized the standard to remove legacy weak algorithms. PGP's weaknesses are operational (key management, metadata leakage) rather than cryptographic.

What's the difference between PGP, OpenPGP, and GPG?

PGP is the original software (now owned by Symantec/Broadcom). OpenPGP is the open standard (RFC 4880 / RFC 9580) that anyone can implement. GPG — GNU Privacy Guard — is the free, open-source implementation you should actually use. When people say "PGP" today they usually mean OpenPGP/GPG.

Do I need PGP if I'm already using Signal?

They solve different problems. Signal encrypts messages in transit with forward secrecy — it's better for real-time conversation. PGP is for encrypting stored files, email, and documents where you need a stable key identity over time. Many privacy-conscious users use both.

How do I verify someone's public key is really theirs?

Call them, meet in person, or use Signal's safety numbers to verify the fingerprint out-of-band. Never trust a key purely because it's on a keyserver — anyone can upload a key claiming any email address.

Can I use PGP with ProtonMail or Tutanota?

Proton Mail has native PGP support — you can import your own keys or let Proton manage them (see our anonymous email guide). Tutanota uses its own encryption scheme and does not support standard PGP imports as of 2025. If PGP interoperability matters, Proton Mail is the better choice.