---
{
  "title": "PGP and GnuPG",
  "summary": "Understand encryption, signing, and public-key trust as separate operations.",
  "topic": "foundations",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "units": [
    7
  ],
  "aliases": [],
  "sources": [
    {
      "title": "GnuPG documentation",
      "url": "https://www.gnupg.org/documentation/"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## The idea

PGP-style tools support message or file encryption and digital signatures. GnuPG is a commonly used implementation. Users must verify public-key identity, protect private keys, and understand which operation is being performed. File encryption does not automatically authenticate the source, and signing does not hide the content. Key distribution, revocation, and backups require planning. Follow current tool documentation for supported formats and algorithms.

## In practice

A user verifies an official release signature with the correct publisher key obtained through a trusted channel.

## A common misunderstanding

Importing a public key is not the same as independently establishing whom it belongs to.

## Check your understanding

What should you check before trusting a signature?

**Think it through:** The authentic signer key, validation result, intended artifact, and relevant key status.

## A public key needs an identity decision

A fictional learner downloads a software release and its detached signature. Importing a key makes it available to the verification tool, but the learner still needs a trusted reason to associate that key with the publisher. A signature verified under an arbitrary downloaded key proves a different claim from a signature verified under an independently established publisher key.

Keep signing and encryption purposes distinct. Signing can help detect modification and support a claim about the signer under the key's trust relationship. Encryption protects content for the intended decryption capability. A file may use one, both, or neither, and the tool's output should be interpreted accordingly.

Key lifecycle affects long-term use. Expiry, revocation, replacement, backups, and private-key protection require planning. Archived signatures can need contextual interpretation, while losing a decryption key can make required content unavailable. Consult the current implementation's documentation for supported formats and behavior.

## Verify a synthetic release workflow

For a training exercise, create a dummy publisher and artifact. Record how the public key is established, which artifact is signed, and what a modified copy should produce during verification. Do not publish a real private key or reuse an organizational signing credential.

Then describe an authorized key rollover and how users learn that the replacement is genuine. Avoid relying on a key identifier alone without understanding its strength and intended verification process. The useful skill is not merely obtaining a successful command result, but explaining exactly whose key was trusted, which content was verified, and what the result permits you to conclude about the artifact.

## Keep exploring

- [[digital-signatures]]
- [[asymmetric-encryption]]
- [[key-management]]