OpenPGP
OpenPGP is a standard for encrypting and signing data. GnuPG, usually called GPG, is the free and open source implementation of that standard that lives on your desktop. Together they give you the ability to encrypt files and messages so that only the intended recipient can read them, sign things so that recipients can verify they came from you, and authenticate to remote systems using your GPG key rather than a separate SSH key.
It is also, frankly, one of the more conceptually dense parts of this setup. The web of trust model, the distinction between primary keys and subkeys, the question of key servers versus direct key exchange, the relationship between GPG and SSH agent, all of it requires a bit of sitting with before it clicks. This introduction is about giving you the map before handing you the territory.
A brief history worth knowing
PGP, Pretty Good Privacy, was created by Phil Zimmermann in 1991. The idea was straightforward: give ordinary people access to the same kind of encryption that governments and intelligence agencies used, and make it freely available. This caused enough concern in the right quarters that Zimmermann faced a criminal investigation for several years. He was eventually cleared, but the episode is a useful reminder of what strong encryption actually represents.
OpenPGP is the open standard that emerged from PGP. GnuPG is the most widely used implementation of that standard, and the one this series uses. It has been in continuous development since 1997 and is installed by default on Kubuntu.
The version shipped with Kubuntu 24.04 LTS is GnuPG 2.4.x. The source material this series draws on was written for GnuPG 2.2.x. There are meaningful differences between the two, particularly around key generation defaults and agent behaviour, and this series reflects the current version throughout rather than the older one.
What GPG is used for in this setup
GPG touches several parts of this network build:
Email encryption and signing. When your mail client is connected to your self-hosted mail server, GPG allows you to sign outgoing messages so recipients can verify they came from you, and encrypt messages to recipients whose public keys you have. This is covered in the mail client section.
SSH authentication. GPG can act as an SSH agent, using your GPG authentication subkey to authenticate SSH connections. This is particularly useful in combination with a Yubikey, which stores the private key on hardware and requires physical presence to use it.
File encryption. Encrypting files at rest or for secure transfer to another person. A GPG-encrypted file can only be decrypted by someone with the corresponding private key.
Package verification. Many software repositories and release tarballs are signed with GPG. Verifying those signatures before running software is good practice and requires understanding how GPG key verification works.
Backups. Encrypted backups using GPG ensure that backup media, even if lost or stolen, cannot be read without the private key.
The key structure
GPG keys are more complex than SSH keys, and understanding the structure upfront saves confusion later.
A GPG key is not a single key. It is a primary key with one or more subkeys attached to it. Each key has a defined capability: certify (C), sign (S), encrypt (E), or authenticate (A). The primary key holds the certify capability, which means it is the one that signs other keys and subkeys. Subkeys handle the day-to-day operations.
The reason for this structure is sensible once you understand it. The primary key is your identity. Losing it means losing your place in the web of trust and having to start over. Subkeys are operational. If a subkey is compromised, you can revoke it and generate a new one without affecting your identity or your trust relationships. This is why the recommended practice is to keep the primary key offline, stored securely, and do day-to-day work with subkeys only.
In this setup, that means:
- Primary key: generated and stored offline, used only to certify subkeys and other people’s keys
- Signing subkey: used for signing emails and files
- Encryption subkey: used for encrypting emails and files
- Authentication subkey: used for SSH authentication, particularly via Yubikey
The web of trust
Unlike TLS certificates, which rely on a hierarchy of Certificate Authorities, OpenPGP uses a web of trust model. There is no central authority. Instead, trust is established by people signing each other’s keys, asserting that they have verified the key belongs to the person it claims to belong to.
In practice, for a personal setup like this one, the web of trust matters less than it might in a larger organisation. The primary benefit of GPG in this context is end-to-end encryption and signing rather than publicly verifiable identity. That said, publishing your public key and having it signed by people who know you is still worth doing, and the distributing keys section covers how.
What this section covers
- GPG setup and configuration — Installing, configuring, and understanding GnuPG 2.4.x on Kubuntu
- Managing OpenPGP keys — Generating your primary key and subkeys, setting expiry dates, revocation certificates
- Distributing OpenPGP keys — Key servers, WKD, and direct key exchange
- SSH authentication with OpenPGP — Using your GPG authentication subkey for SSH connections
- Using OpenPGP on remote systems — Agent forwarding and working with GPG on servers
- OpenPGP applications and tools — Kleopatra, the KDE-native GPG frontend, and other useful tooling
GPG has a reputation for being difficult. That reputation is not entirely undeserved, but most of the difficulty comes from approaching it without understanding the underlying model first. Read this introduction once, then the rest of the section will make considerably more sense.