GnuPG tutorial: create keys, encrypt files for someone, and sign your own

Create a key

GnuPG 2.2 and later default to elliptic curve keys (Ed25519 for signing, Curve25519 for encryption). Use --full-generate-key to choose options, or --quick-generate-key for defaults. GnuPG creates a revocation certificate automatically in the openpgp-revocs.d directory; keep a copy offline, because it lets you announce the key is no longer valid if you lose it.

Snippet

gpg --quick-generate-key 'Lab User <lab@example.org>' ed25519 sign 1y
gpg --quick-add-key <FINGERPRINT> cv25519 encr 1y
gpg --list-keys --keyid-format long
gpg --armor --export lab@example.org > lab-public.asc
gpg --fingerprint lab@example.org

Encrypt, sign, verify

Encrypting for someone needs their public key; only their private key can decrypt. Signing uses your private key; anyone with your public key can verify. A detached signature (.sig or .asc) leaves the original file unchanged, which is how software releases are usually signed.

Snippet

gpg --import colleague-public.asc
gpg --encrypt --recipient colleague@example.org --output report.pdf.gpg report.pdf
gpg --decrypt report.pdf.gpg > report.pdf

gpg --armor --detach-sign release.tar.gz      # creates release.tar.gz.asc
gpg --verify release.tar.gz.asc release.tar.gz
gpg --clearsign note.txt                       # readable text with inline signature

Lab: two users, one exchange

Create two lab keys in separate GNUPGHOME directories to simulate two people. Exchange public keys, verify fingerprints out of band (read them aloud or compare on screen), encrypt a file from user A to user B, decrypt as B, then have B sign a reply that A verifies. Finally, revoke one key using its revocation certificate and see how verification output changes.

Snippet

export GNUPGHOME=$(mktemp -d); gpg --quick-generate-key 'Alice Lab <alice@lab.test>' default default 1y
# in another terminal with a different GNUPGHOME, create Bob, then exchange --export / --import

The trust question

GPG tells you a signature is valid for a key, but not whether the key belongs to the person. Verifying fingerprints through a separate channel, or relying on a known release key published in several places, is what connects a key to an identity. Warnings such as “This key is not certified with a trusted signature” mean exactly that.

Diagram

Encrypting versus signing

Different keys for different promises.

Encrypt for Bob

Uses. Bob’s public key

Who can undo it. Only Bob, with his private key

Promise. Confidentiality

Sign as Alice

Uses. Alice’s private key

Who can check it. Anyone with Alice’s public key

Promise. Integrity and origin

Check yourself

1. To send Bob an encrypted file, which key do you use?

2. Which signature type leaves the original file untouched?

3. How do you confirm a public key really belongs to a person?