Encrypt Online
Theme

Protect & Encrypt

PGP Encryption Guide With OpenPGP Keys and Signatures

Learn to verify OpenPGP key fingerprints, encrypt and decrypt messages with GnuPG, and validate signatures.

Encrypt Online Editorial Team7 min read
Encrypt Online guide cover on a sage background with the headline "PGP encryption". A simple envelope contains PGP in its clear lower half. The fold indicates a message; the name identifies the protocol.

RFC 9580 specifies the OpenPGP message format. PGP is often used informally for OpenPGP. Confirm that the public key belongs to the intended recipient before encrypting.

Encrypting to the wrong key can produce a perfectly valid OpenPGP message that only the wrong person can open.

Worth knowing: Compare the full recipient fingerprint through a trusted channel to establish ownership; the OpenPGP Message tool provides the key details for that comparison.

In brief

OpenPGP uses hybrid encryption. A fresh symmetric session key encrypts the message, the recipient's public key protects that session key, and the recipient's private key recovers it.

Encryption and signatures answer different questions. Encryption hides content. A signature lets a recipient check which key signed the content and whether it changed.

RFC 9580 is the current OpenPGP specification and obsoletes RFC 4880.

Learn the four objects that matter

  • Public key or certificate: Share this with people who need to encrypt to you or verify your signatures.
  • Private key: Keep this secret. It enables decryption and signing.
  • Fingerprint: A longer identifier derived from the public key. Use it instead of relying on a short Key ID.
  • Revocation certificate: Publish this when a key should no longer be trusted after loss, compromise, or retirement.

OpenPGP keys often include separate subkeys for encryption and signing. GnuPG can select a suitable subkey when you identify the recipient by the verified primary-key fingerprint.

Create and save the recipient's key pair

The person who will decrypt the messages is the recipient. That person creates the key pair, keeps the private key and its passphrase secret, and shares only the public key.

For a focused browser workflow, use the OpenPGP Key Pair Generator:

  1. Enter a name, optional email, private-key passphrase, and expiration period.
  2. Generate the key pair, then save the public key, encrypted private key, and revocation certificate.
  3. Keep the private key, passphrase, and revocation certificate protected. Share the public key and its full fingerprint.

The generator keeps its output separate from the message tool. Download the required files, then paste a key when you are ready to use it.

For a managed command-line workflow, GnuPG can create a signing primary key plus a separate encryption subkey:

Shell
gpg --quick-generate-key 'Recipient Name <recipient@example.com>' ed25519 cert,sign 2y
gpg --list-secret-keys --with-subkey-fingerprint 'recipient@example.com'
gpg --quick-add-key '<PRIMARY_FINGERPRINT>' cv25519 encrypt 2y

gpg --armor --export '<PRIMARY_FINGERPRINT>' > recipient-public-key.asc
gpg --armor --export-secret-keys '<PRIMARY_FINGERPRINT>' > recipient-private-key-backup.asc

Store the private-key backup separately from its passphrase. GnuPG also creates revocation material for a new key; protect it so you can retire the public key if the private key is lost or compromised.

Verify the recipient before encrypting

Import the public key, then inspect its fingerprint:

Shell
gpg --import recipient-public-key.asc
gpg --fingerprint 'recipient@example.com'

Compare the fingerprint through a trusted channel. Prefer a mechanical transfer or comparison method when one is available; long hexadecimal fingerprints are easy for people to misread. Use the full fingerprint as the ownership check, with an email address or short Key ID serving only as a lookup hint.

An unexpected key change is a stop signal. Confirm the new fingerprint before sending sensitive material.

Encrypt and decrypt a small test

After verifying the recipient fingerprint, encrypt a file with ASCII-armored output:

Shell
printf '%s' 'hello' > message.txt
gpg --armor --encrypt --recipient '<VERIFIED_RECIPIENT_FINGERPRINT>' \
  --output message.asc message.txt

gpg --decrypt --output message.dec.txt message.asc
cmp -s message.txt message.dec.txt && echo 'exact match'

ASCII armor makes binary OpenPGP data easier to move through text systems. It adds the familiar BEGIN PGP MESSAGE boundary, but it does not add another encryption layer.

Run the test with harmless content first. For a real recipient, the decrypt step must happen in an environment that has the matching private key.

Complete the sender-to-recipient workflow

The OpenPGP Message tool provides a focused browser workflow for ASCII-armored text. The complete exchange is:

  1. The recipient creates a key pair and safely stores the private key, passphrase, and revocation certificate.
  2. The recipient shares the complete armored public key and full fingerprint with the sender.
  3. The sender chooses Encrypt, pastes the plaintext and public key, and compares the displayed fingerprint through a trusted channel.
  4. The sender encrypts and shares the complete BEGIN PGP MESSAGE block.
  5. The recipient chooses Decrypt, pastes the armored message and matching private key, and enters the private-key passphrase when required.
  6. The recipient decrypts and checks the restored plaintext before relying on the workflow.

Start with harmless test text. Paste the recipient key into the message tool and confirm its full fingerprint with the recipient. Use GnuPG or another key-management tool for keyserver or WKD lookups, signing, signature verification, hardware keys and organization-managed keys.

Add a signature when the sender matters

Create a detached signature when the recipient needs to check the content against the sender's signing key:

Shell
gpg --armor --detach-sign --local-user '<SIGNER_FINGERPRINT>' message.txt
gpg --verify message.txt.asc message.txt

A successful cryptographic verification means the signature matches a public key in the verifier's keyring. Trust in the sender still depends on verifying that key's fingerprint and status.

GnuPG can also sign and encrypt in one operation. Keep the concepts separate while debugging: first identify the recipient encryption key, then identify the sender signing key.

Plan for the key lifecycle

  • Protect the private key with an appropriate passphrase and maintain a tested encrypted backup.
  • Keep revocation material somewhere you can reach if the private key is lost or compromised.
  • Set and review expiration dates instead of assuming a key should remain active indefinitely.
  • Refresh a contact's certificate before important exchanges so revocations, expiration changes, and replacement subkeys are visible.
  • Remember that losing the only private-key copy makes retained ciphertext unrecoverable. Compromise can expose messages encrypted to that key that an attacker obtains.

Current GnuPG creates a revocation certificate when it generates a new key. Locate it in the GnuPG home directory and protect it separately from everyday key use.

Choose OpenPGP for the right exchange

OpenPGP fits ongoing communication where participants can exchange keys, verify fingerprints, and manage revocation. A shared-passphrase workflow may be simpler for a one-time low-risk message, but then the passphrase needs its own secure handoff.

TLS and OpenPGP also protect different layers. TLS protects a connection to a service. OpenPGP can keep the content encrypted after it is stored or forwarded.

Questions new users usually ask

Does OpenPGP encrypt the whole message with RSA or an elliptic-curve key?

Normally, no. OpenPGP generates a random symmetric session key for the message, encrypts the content with symmetric cryptography, and then protects the session key for each recipient.

Can I send my public key in the same email as the fingerprint?

You can, but that does not independently verify it. An attacker who can replace the key in that channel may also replace the fingerprint. Confirm the fingerprint through a separate trusted or mechanically authenticated path.

Does a valid signature mean I trust the signer?

It proves that the matching private key signed the bytes and that those signed bytes did not change. You still need to decide whether the public key belongs to the person or system you intend to trust.

References