PGP Encryption Fundamentals: Key Generation, Management and Secure Communication

Pretty Good Privacy (PGP) remains one of the most robust and widely trusted encryption systems available for securing communications and verifying digital identities. Originally created by Phil Zimmermann in 1991, PGP was revolutionary because it brought strong public-key cryptography to ordinary users at a time when such technology was classified as a munition by the United States government. Today, the open standard derived from PGP -- OpenPGP -- and its most popular free implementation, GNU Privacy Guard (GnuPG or GPG), continue to serve as essential tools for journalists, activists, security researchers, and privacy-conscious individuals worldwide.

This article provides a comprehensive, technically detailed guide to PGP/GPG encryption, covering everything from the underlying cryptographic principles through practical key generation, key management best practices, message encryption and signing, the web of trust model, keyserver infrastructure, and the use of graphical tools like Kleopatra. Whether you are encrypting your first message or refining your key management practices, this guide will give you the knowledge you need to use PGP effectively and securely.

How PGP Encryption Works

PGP uses a hybrid encryption scheme that combines the speed of symmetric encryption with the key distribution advantages of asymmetric (public-key) encryption. Understanding this architecture is fundamental to using PGP correctly.

When you encrypt a message with PGP, the following process occurs: First, the plaintext message is compressed (this improves both security and efficiency). Then, a random session key is generated -- this is a one-time symmetric key, typically AES-256. The compressed plaintext is encrypted with this session key using a symmetric cipher. Finally, the session key itself is encrypted with the recipient's public key using an asymmetric algorithm (typically RSA or Curve25519). The encrypted session key and the symmetrically encrypted message are bundled together and sent to the recipient.

When the recipient receives the message, they use their private key to decrypt the session key, and then use the session key to decrypt the actual message. This hybrid approach means that the computationally expensive asymmetric encryption is only applied to the small session key, while the bulk of the data is encrypted with the much faster symmetric algorithm.

Digital signatures work similarly but in reverse. When you sign a message, PGP computes a cryptographic hash of the message content and then encrypts that hash with your private key. Anyone with your public key can decrypt the hash and compare it to their own independently computed hash of the message. If the hashes match, the signature is valid, proving both that the message was signed by the holder of the private key and that the message has not been modified since it was signed.

Installing GnuPG

GnuPG is the free, open-source implementation of the OpenPGP standard and is available on all major operating systems. The official source and documentation are maintained at gnupg.org.

Linux

Most Linux distributions include GnuPG by default. You can verify its installation and version with:

gpg --version

If it is not installed, use your distribution's package manager:

# Debian/Ubuntu
sudo apt install gnupg2

# Fedora
sudo dnf install gnupg2

# Arch Linux
sudo pacman -S gnupg

Windows

On Windows, the recommended solution is Gpg4Win, which includes GnuPG along with Kleopatra (a graphical key management tool), GPA (another graphical frontend), and GpgOL/GpgEX plugins for Outlook and Windows Explorer integration. Download it from the official Gpg4Win website and run the installer.

macOS

On macOS, you can install GnuPG through Homebrew:

brew install gnupg

Alternatively, GPG Suite (from gpgtools.org) provides a more integrated macOS experience with a graphical key manager, Mail.app integration, and system services.

Generating Your Key Pair

The foundation of PGP is the key pair -- a mathematically linked public key and private key. The public key is shared freely and is used by others to encrypt messages to you and to verify your signatures. The private key must be kept absolutely secret and is used to decrypt messages sent to you and to create digital signatures.

To generate a new key pair using the command line, use the full key generation dialog:

gpg --full-generate-key

You will be prompted to make several choices:

Key type: For maximum compatibility, choose "RSA and RSA" (option 1). For better performance and security with modern software, choose "ECC (sign and encrypt)" which uses elliptic curve cryptography. The recommended curve is Curve25519, which provides excellent security with smaller key sizes and faster operations than RSA.

Key size (RSA only): If using RSA, choose 4096 bits. While 2048 bits is still considered secure against current attacks, 4096 bits provides a larger security margin against future advances in computing power and cryptanalysis. There is minimal practical downside to the larger key size.

Expiration: Setting an expiration date is strongly recommended. A common practice is to set a one or two year expiration. You can always extend the expiration date later using your private key, but if your key is compromised and you lose access, an expiration date ensures the key will eventually stop being used. Keys without expiration dates will remain valid indefinitely, even if you lose control of the private key.

User ID: Enter your name (or pseudonym) and email address. This information is embedded in the public key and helps others identify which key belongs to you. For anonymous usage, you can use a pseudonym and a disposable email address.

Passphrase: Choose a strong passphrase to protect your private key. This passphrase encrypts the private key on disk, so even if someone obtains a copy of your private key file, they cannot use it without the passphrase. Use a long, memorable passphrase -- ideally a sequence of random words (a diceware passphrase) of at least six words.

A complete key generation session produces output similar to:

gpg --full-generate-key

gpg (GnuPG) 2.4.5; Copyright (C) 2024 g10 Code GmbH
Please select what kind of key you want:
   (1) RSA and RSA
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
   (9) ECC (sign and encrypt) *default*
  (10) ECC (sign only)
Your selection? 9

Please select which elliptic curve you want:
   (1) Curve 25519 *default*
   (4) NIST P-384
   (6) Brainpool P-256r1
Your selection? 1

Please specify how long the key should be valid.
         0 = key does not expire
        = key expires in n days
      w = key expires in n weeks
      m = key expires in n months
      y = key expires in n years
Key is valid for? (0) 2y

Key expires at Thu 25 Feb 2028 12:00:00 PM UTC
Is this correct? (y/N) y

Real name: Anonymous User
Email address: anon@example.org
Comment:
You selected this USER-ID:
    "Anonymous User <anon@example.org>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O

Key Management Best Practices

Generating a key is only the beginning. Proper key management is what separates effective PGP usage from a false sense of security.

Exporting and Backing Up Your Keys

Immediately after generating your key pair, create secure backups of both your public and private keys:

# Export your public key
gpg --armor --export your@email.org > public-key.asc

# Export your private key (KEEP THIS SECURE)
gpg --armor --export-secret-keys your@email.org > private-key.asc

# Export your trust database
gpg --export-ownertrust > trustdb.txt

Store the private key backup on an encrypted USB drive or other offline storage medium. Never store private key backups on cloud storage, in email, or on any internet-connected device that you do not fully control. Some security-conscious users print their private key as a paper backup using the paperkey utility, which extracts only the secret bits and formats them for printing.

Generating a Revocation Certificate

A revocation certificate allows you to invalidate your public key if your private key is ever compromised, lost, or you simply want to retire the key. Generate one immediately after creating your key pair and store it separately from the key itself:

gpg --gen-revoke --armor --output revocation-certificate.asc your@email.org

If your key is compromised, you can import the revocation certificate and upload the revoked key to keyservers to inform others that it should no longer be trusted. Without a revocation certificate, you cannot revoke a key if you lose access to the private key.

Subkeys

An advanced but highly recommended practice is to use subkeys for day-to-day operations while keeping your primary key offline. Your primary key pair is the root of your PGP identity -- it is used to certify subkeys and other people's keys. Subkeys are subordinate key pairs that are signed by your primary key and can be used for encryption and signing.

The advantage of this approach is that if a subkey is compromised, you can revoke just that subkey and create a new one, without losing your entire PGP identity and the trust that others have placed in your primary key. Your primary key remains safe in offline storage, used only when you need to certify new subkeys or sign other people's keys.

# Add a new signing subkey
gpg --edit-key your@email.org
gpg> addkey
# Select signing key type and parameters
gpg> save

# Add a new encryption subkey
gpg --edit-key your@email.org
gpg> addkey
# Select encryption key type and parameters
gpg> save

Encrypting and Decrypting Messages

The primary use case for PGP is encrypting messages so that only the intended recipient can read them. Before you can encrypt a message to someone, you need their public key.

Importing a Public Key

# Import a public key from a file
gpg --import recipient-public-key.asc

# Import a public key from a keyserver
gpg --keyserver hkps://keys.openpgp.org --recv-keys KEY_FINGERPRINT

# Verify the imported key's fingerprint
gpg --fingerprint recipient@email.org

Always verify the fingerprint of imported keys through a separate, trusted channel before using them to encrypt sensitive messages. This prevents man-in-the-middle attacks where an attacker substitutes their own public key for the intended recipient's key.

Encrypting a Message

# Encrypt a file for a specific recipient
gpg --armor --encrypt --recipient recipient@email.org message.txt

# Encrypt with multiple recipients
gpg --armor --encrypt --recipient alice@email.org --recipient bob@email.org message.txt

# Encrypt and sign simultaneously (recommended)
gpg --armor --encrypt --sign --recipient recipient@email.org message.txt

# Encrypt text from stdin
echo "Secret message" | gpg --armor --encrypt --recipient recipient@email.org

The --armor flag produces ASCII-armored output that can be safely pasted into email messages, chat windows, or web forms. Without this flag, GnuPG produces binary output that is smaller but cannot be transmitted through text-based channels.

Decrypting a Message

# Decrypt a file
gpg --decrypt message.txt.asc

# Decrypt and save to a file
gpg --decrypt --output decrypted-message.txt message.txt.asc

# Decrypt from stdin
cat encrypted-message.asc | gpg --decrypt

GnuPG will automatically identify which private key is needed for decryption and prompt you for the passphrase.

Digital Signatures

Digital signatures serve two purposes: they prove that a message was created by the holder of a specific private key (authentication), and they prove that the message has not been modified since it was signed (integrity). Signatures do not encrypt the message -- they can be applied to both plaintext and encrypted content.

# Create a detached signature (most common for files)
gpg --armor --detach-sign document.pdf

# Create a cleartext signature (readable text with inline signature)
gpg --clearsign message.txt

# Verify a detached signature
gpg --verify document.pdf.asc document.pdf

# Verify a cleartext signature
gpg --verify signed-message.txt

Signatures are critical for verifying software downloads, as demonstrated in our Tor Browser installation guide where GPG signature verification ensures the integrity of the downloaded browser.

The Web of Trust

The Web of Trust is PGP's decentralized model for establishing the authenticity of public keys. Unlike the certificate authority (CA) model used by TLS/SSL, where a centralized authority vouches for the identity of key holders, the Web of Trust relies on users vouching for each other through key signing.

When you verify someone's identity and confirm their key fingerprint through a trusted channel, you can sign their key to indicate that you have verified the association between the key and the person. Others who trust your judgment can then trust that key as well, creating a chain of trust that extends across the community.

# Sign someone's key after verifying their identity
gpg --sign-key recipient@email.org

# Set the trust level for a key
gpg --edit-key recipient@email.org
gpg> trust
# Choose trust level (1-5)
gpg> save

The trust levels in GnuPG are: unknown, none, marginal, full, and ultimate. A key signed by someone you fully trust is considered valid. A key signed by three people you marginally trust is also considered valid. Your own keys are set to ultimate trust by default.

In practice, the Web of Trust has been partially superseded by verification through alternative channels -- comparing fingerprints over video calls, publishing fingerprints on verified social media accounts, or using services like keys.openpgp.org which provides email-based key verification. The OpenPGP standard and related resources are documented at openpgp.org.

Keyservers and Key Distribution

Keyservers are public repositories where users can upload their public keys and search for others' keys. The traditional keyserver network (SKS keyservers) has largely been replaced by more modern alternatives due to various security and abuse issues with the federated SKS model.

The recommended modern keyserver is keys.openpgp.org, which verifies email addresses before publishing them and provides better privacy protections than traditional keyservers. To configure GnuPG to use this keyserver by default, add the following to your ~/.gnupg/gpg.conf file:

keyserver hkps://keys.openpgp.org

You can also use Web Key Directory (WKD), which allows domain operators to host public keys for their users. This is increasingly becoming the preferred method for key discovery, as it ties key distribution to existing domain ownership verification.

Using Kleopatra (Graphical Interface)

Kleopatra is the graphical certificate manager and universal crypto client included with Gpg4Win on Windows and available separately on Linux. It provides a user-friendly interface for all the operations described above -- key generation, import/export, encryption, decryption, signing, and key management.

For users who are not comfortable with the command line, Kleopatra makes PGP significantly more accessible. You can generate keys through a guided wizard, drag and drop files for encryption and signing, manage your keyring visually, and handle key certification through an intuitive interface. The Kleopatra project is maintained as part of the KDE project, and its source code is available on GitHub.

Video Resources

For a visual walkthrough of PGP concepts and practical usage, the following Computerphile video provides an accessible explanation of the underlying principles:

NetworkChuck also provides a hands-on tutorial demonstrating practical GPG usage:

Common Mistakes and Security Considerations

Not verifying key fingerprints: The most common and dangerous mistake is encrypting messages to a key without verifying its fingerprint. If an attacker has substituted their own public key, they will be able to read all messages encrypted to that key. Always verify fingerprints through a separate, trusted channel.

Weak passphrases: A private key protected by a weak passphrase is only marginally better than an unprotected key. Use a diceware passphrase of at least six words, or a randomly generated password of at least 20 characters stored in a reputable password manager.

Not using subkeys: Operating with your primary key for daily tasks puts your entire PGP identity at risk. If your primary key is compromised and you have no revocation certificate, you lose everything. Using subkeys compartmentalizes this risk.

Ignoring metadata: PGP encrypts message content but does not hide metadata. The subject line of an encrypted email, the sender and recipient addresses, timestamps, and message sizes are all visible. For metadata protection, consider using PGP in combination with anonymous communication channels or through Tor-based services.

Forgetting to encrypt: In fast-paced communication, it is easy to accidentally send a plaintext message that should have been encrypted. Some mail clients offer an option to encrypt all outgoing mail by default, which is a useful safeguard against this mistake.

PGP is a powerful tool, but it requires discipline and knowledge to use effectively. The GnuPG project maintains comprehensive documentation at gnupg.org/documentation, and the Privacy Guides community provides additional practical guidance at privacyguides.org. By understanding both the capabilities and the limitations of PGP, you can make it a reliable cornerstone of your privacy and security practices.