Protect & Encrypt · Field note
PGP Encryption Guide: OpenPGP Keys, Encryption, and Signatures
Learn the practical OpenPGP workflow with GnuPG: verify a key fingerprint, encrypt and decrypt a message, and check signatures correctly.
Before you start
Run the workflow once with a disposable value, then do a decrypt or restore check before you share anything real.
PGP is often used as a general name for OpenPGP, the standard format now defined by RFC 9580. The commands are straightforward. The important decision happens before encryption: confirming that the public key really belongs to the intended recipient.
Encrypting to the wrong key can produce a perfectly valid OpenPGP message that only the wrong person can open.
In brief
OpenPGP uses a public key for sending encrypted data to a recipient and a private key for decryption. In practice, it uses hybrid encryption: a fresh symmetric session key protects the message, and the recipient's public key protects that session key.
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.
Verify the recipient before encrypting
Import the public key, then inspect its fingerprint:
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. Do not treat a matching email address or short Key ID as sufficient evidence.
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:
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.
Add a signature when the sender matters
Encryption alone does not prove who wrote the message. Create a detached signature when the recipient needs to verify both the content and the signing key:
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.