GPG is een van die tools die iedereen ooit wil leren en nooit doet. De docs zijn een muur van tekst, de terminologie is een eigen dialect, en de error messages zijn cryptisch in beide betekenissen van het woord. Ik heb het zelf jaren uitgesteld.

Het punt is: je blijft er tegenaan lopen. GPG zit onder pass, onder signed git commits, onder versleutelde email, onder het verifiëren dat de binary die je net downloadde echt is wat de maintainer heeft uitgebracht. Als je je eigen security wilt bezitten in plaats van vertrouwen op een vendor die het voor je regelt, kom je hier vroeg of laat uit.

Dus dit is de gids die ik zelf had willen hebben. We beginnen met het absolute minimum dat iets nuttigs doet, en voegen één laag per keer toe. Je mag stoppen met lezen zodra je genoeg hebt.

Wat is GPG eigenlijk?

GPG (GNU Privacy Guard) is een implementatie van het OpenPGP protocol. Haal de jargon eraf en het doet twee klussen:

  1. Encryptie: een bestand versleutelen zodat alleen de bedoelde ontvanger het kan lezen
  2. Signing: iets stempelen zodat anderen kunnen verifiëren dat het van jou komt

Beide klussen draaien op asymmetrische cryptografie. Je hebt een public key die je vrij uitdeelt, en een private key die nooit uit je handen komt.

  • Iemand wil jou een geheim sturen → ze versleutelen met jouw public key → alleen jij kunt het ontsleutelen met je private key
  • Jij wilt bewijzen dat iets van jou komt → je ondertekent met je private key → iedereen verifieert met je public key

Dat is het hele mentale model. Alles hieronder is gewoon flags en bestandsformaten bovenop die twee ideeën, dus als de rest verwarrend wordt, kom hier terug en het valt weer op zijn plek.

In 5 minuten je eerste keypair

Dit is de simpelste versie die echt iets doet. Eén commando, een handvol vragen, en je hebt werkende crypto. Geen subkeys, geen hardware, geen theorie. Krijg dit werkend en de rest is optioneel.

Installatie

# macOS
brew install gnupg

# Debian/Ubuntu
sudo apt install gnupg

# Arch
sudo pacman -S gnupg

Keypair genereren

gpg --full-generate-key

Hij stelt je een paar dingen:

Please select what kind of key you want:
   (1) RSA and RSA
   (9) ECC (sign and encrypt)

Kies (1) RSA and RSA als je de breedste compatibiliteit wilt, of (9) ECC als je moderne, kortere keys wilt. Bij twijfel: RSA. Alles snapt het.

What keysize do you want? (3072)

Kies 4096 voor RSA. Groter is hier prima, binnen de rede.

Key is valid for? (0)

Kies 2y (2 jaar). Je kunt ’m altijd later verlengen. Een key zonder expiry voelt handig tot de dag dat hij lekt, want dan blijft hij voor altijd geldig en is er geen klok die afloopt om de schade te beperken. Een expiry-datum is een ingebouwde failsafe.

Real name: Tom Meurs
Email address: tom@example.com
Comment:

Vul je naam en email in. Laat comment leeg.

Enter passphrase:

Kies hier een sterke passphrase. Als iemand ooit je private key-bestand te pakken krijgt, is deze passphrase het enige wat tussen die persoon en jouw identiteit staat. Behandel ’m dienovereenkomstig.

Klaar. Je hebt een werkend GPG keypair. Dat was het lastige deel van starten, en dat ligt al achter je.

Keys bekijken

# Lijst je public keys
gpg --list-keys

# Lijst je private keys
gpg --list-secret-keys

Output ziet er zo uit:

pub   rsa4096 2026-01-26 [SC] [expires: 2028-01-26]
      ABC123DEF456GHI789JKL012MNO345PQR678STU9
uid           [ultimate] Tom Meurs <tom@example.com>
sub   rsa4096 2026-01-26 [E] [expires: 2028-01-26]

Die lange string is je key ID (fingerprint). Mensen gebruiken vaak de korte versie, de laatste 16 karakters: MNO345PQR678STU9.

Direct bruikbaar: bestanden versleutelen

Eerste laag echt gebruik. Je hebt een key, laten we er nu daadwerkelijk iets mee doen. Encryptie is het meest direct bevredigende deel, dus daar beginnen we.

Versleutelen voor jezelf

# Versleutel een bestand
gpg --encrypt --recipient tom@example.com secret.txt
# Maakt secret.txt.gpg

# Ontsleutel
gpg --decrypt secret.txt.gpg > secret.txt

Versleutelen voor iemand anders

Eerst heb je hun public key nodig:

# Importeer een public key
gpg --import colleague-key.asc

# Of haal op van een keyserver
gpg --keyserver keyserver.ubuntu.com --recv-keys THEIR_KEY_ID

Dan versleutelen:

gpg --encrypt --recipient colleague@example.com secret.txt

Nu kunnen alleen zij het openen. Je hoefde geen gedeeld wachtwoord af te spreken via een of ander zijkanaal, en dat is precies het hele punt van public key crypto.

Symmetrische encryptie (wachtwoord)

Soms wil je helemaal niet met keys bezig zijn, alleen een wachtwoord:

gpg --symmetric secret.txt
# Vraagt om wachtwoord, maakt secret.txt.gpg

Handig voor een snelle eenmalige encryptie. Het is zwakker dan de asymmetrische route omdat het hele ding rust op één wachtwoord dat je moet onthouden en op de een of andere manier delen, dus ik pak het alleen als keys overkill zouden zijn.

Signing: bewijzen dat iets van jou komt

Een bestand ondertekenen

# Maak een losse signature
gpg --detach-sign document.pdf
# Maakt document.pdf.sig

# Of embed de signature
gpg --sign document.pdf
# Maakt document.pdf.gpg (signed + compressed)

# Of clearsign (leesbaar met signature erin)
gpg --clearsign message.txt
# Maakt message.txt.asc

Signature verifiëren

gpg --verify document.pdf.sig document.pdf

Output:

gpg: Signature made Mon Jan 26 12:00:00 2026 CET
gpg: using RSA key ABC123...
gpg: Good signature from "Tom Meurs <tom@example.com>"

Zie je ooit “BAD signature”, dan is het bestand na het signen aangepast of hoort de signature niet bij die key. Hoe dan ook: niet vertrouwen.

Git commits signen

Als je GPG maar voor één ding gebruikt, is dit waarschijnlijk dat ding. Het is het stukje GPG dat ik elke dag aanraak zonder erover na te denken.

Git configureren

# Vertel git welke key te gebruiken
git config --global user.signingkey YOUR_KEY_ID

# Automatisch alle commits signen
git config --global commit.gpgsign true

# Automatisch alle tags signen
git config --global tag.gpgsign true

Signed commit maken

git commit -S -m "This commit is signed"

GitHub en GitLab zetten een “Verified” badge naast signed commits. Die badge doet echt werk: hij vertelt reviewers dat de commit daadwerkelijk van jou kwam en niet vervalst is door iemand die user.email op jouw adres zette.

Je public key aan GitHub toevoegen

# Exporteer je public key
gpg --armor --export tom@example.com

Kopieer de output, inclusief de -----BEGIN PGP PUBLIC KEY BLOCK----- regel, en plak het in GitHub onder Settings, dan SSH and GPG keys, dan New GPG key.

Je public key delen

Een signature is nutteloos voor iedereen die je public key niet heeft, dus laten we ’m de wereld in krijgen. Er zijn een paar manieren, van “mail ’m” tot “zet ’m op een keyserver”.

Exporteren

# Als ASCII (voor email, websites)
gpg --armor --export tom@example.com > tom-public.asc

# Als binary
gpg --export tom@example.com > tom-public.gpg

Naar een keyserver uploaden

gpg --keyserver keyserver.ubuntu.com --send-keys YOUR_KEY_ID

Nu kan iedereen je key vinden met:

gpg --keyserver keyserver.ubuntu.com --search-keys tom@example.com

Op je website zetten

Veel mensen hosten hun public key op example.com/.well-known/openpgpkey/ of gewoon example.com/pgp.asc. Zelf hosten betekent dat mensen ’m ophalen van infrastructuur die jij beheert, in plaats van een keyserver van een derde die je niet beheert.

Verder de diepte in: subkeys

Alles tot hier werkt met het ene keypair dat je aan het begin genereerde. Dat is prima om te starten. Maar als je GPG voor langere tijd gaat gebruiken, is dit de laag die het houdbaar maakt, dus de moeite waard om te snappen, ook als je ’m vandaag nog niet opzet.

GPG ondersteunt subkeys: aparte keys die onder je master key hangen.

Waarom moeite doen voor subkeys?

Je master key is je identiteit. Als die gecompromitteerd raakt, ben je het ding kwijt dat bewijst dat jij jij bent, en er is geen schone manier om te herstellen. Subkeys laten je dat kroonjuweel uit de vuurlinie houden:

  • Je master key staat offline, in cold storage
  • Subkeys doen het dagelijkse werk
  • Als een subkey lekt, revoke je alleen die subkey en ga je door
  • Je identiteit, de master key, blijft onaangeroerd

Het principe hier is hetzelfde als achter backups offline houden of de rechten van een service account beperken: maak de blast radius kleiner zodat één misstap niet alles meeneemt.

Subkey structuur

Typische setup:

Master key [C] (certify) - offline bewaren
├── Subkey [S] (signing) - dagelijks gebruik
├── Subkey [E] (encryption) - dagelijks gebruik
└── Subkey [A] (authentication) - SSH login

Subkeys aanmaken

gpg --edit-key tom@example.com

In de GPG prompt:

gpg> addkey
Please select what kind of key you want:
   (4) RSA (sign only)
   (6) RSA (encrypt only)

# Maak een sign-only subkey
# Maak een encrypt-only subkey

gpg> save

Master key offline halen

Dit is de stap die wat lef vraagt, want je staat op het punt om bewust secret key-materiaal van je dagelijkse machine te verwijderen:

# Exporteer alles (backup!)
gpg --armor --export-secret-keys tom@example.com > master-backup.asc

# Exporteer alleen subkeys
gpg --armor --export-secret-subkeys tom@example.com > subkeys.asc

# Verwijder secret keys van je machine
gpg --delete-secret-keys tom@example.com

# Importeer alleen de subkeys
gpg --import subkeys.asc

Nu draagt je dagelijkse machine alleen subkeys. De master key zit op een USB stick in een la, of waar je ’m ook vertrouwt. Wordt je laptop gestolen of overgenomen, dan krijgt de aanvaller subkeys die je kunt revoken, niet de key die jou definieert.

gpg --list-secret-keys
# sec#  rsa4096 ...  ← die # betekent dat de master key niet aanwezig is

Hardware keys: YubiKey

Dit is de diepste laag, en eerlijk gezegd heeft de meeste mensen het nooit nodig. Maar als je wilt dat je private keys fysiek weigeren het apparaat te verlaten waarop ze leven, is een hardware token hoe je daar komt.

Waarom?

  • De keys verlaten nooit de hardware, punt
  • Malware op je laptop kan niet kopiëren wat het niet kan lezen
  • Een aanvaller heeft de fysieke YubiKey nodig, niet alleen remote toegang

Keys naar YubiKey verplaatsen

gpg --edit-key tom@example.com

gpg> key 1  # selecteer subkey
gpg> keytocard
Please select where to store the key:
   (1) Signature key
   (3) Authentication key

gpg> key 2  # selecteer volgende subkey
gpg> keytocard

gpg> save

Vanaf nu betekent signen of decrypten dat je de YubiKey insteekt en aantikt. Een beetje frictie in ruil voor keys die niet stiekem weggesluisd kunnen worden.

GPG + SSH met YubiKey

Hier is een mooie bonus: je GPG authentication subkey kan dubbel dienstdoen als je SSH key.

# In ~/.bashrc of ~/.zshrc
export SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket)

# Enable SSH support in gpg-agent
echo "enable-ssh-support" >> ~/.gnupg/gpg-agent.conf
gpgconf --kill gpg-agent

Nu authenticeert ssh via je YubiKey. Eén hardware token dat zowel GPG als SSH dekt, precies het soort consolidatie waar ik van hou.

De eerlijke nadelen van GPG

Ik zou je iets verkopen als ik hier stopte en deed alsof GPG een plezier is om te gebruiken. Dat is het niet. Het is een krachtige tool met echte, bekende problemen, en je hoort ze te kennen voordat je instapt.

De UX is oprecht slecht

GPG is ontworpen in de jaren ‘90 en dat zie je. De command-line interface is inconsistent, de error messages zijn cryptisch, en routinetaken zitten verstopt achter flags die je elke keer moet opzoeken.

gpg: decryption failed: No secret key
# Wat betekent dit? Key verlopen? Verkeerde key? Geen idee.

Er zijn GUI’s zoals Kleopatra en GPG Keychain, en die helpen een beetje, maar ze repareren de onderliggende rariteit niet.

Key management is complex

  • Hoe backup je keys veilig?
  • Hoe roteer je keys zonder alles te breken?
  • Hoe revoke je een gecompromitteerde key zodat iedereen het weet?
  • Hoe deel je keys met mensen die GPG niet snappen?

Op al deze vragen is een antwoord, maar de antwoorden zijn niet vanzelfsprekend, en je vindt ze door op het slechtst denkbare moment docs te lezen, bijvoorbeeld als een key bijna verloopt.

Web of Trust is effectief dood

Het originele PGP idee was dat mensen elkaars keys signen, en zo een netwerk van vertrouwen bouwen dat je kon nalopen. In de praktijk doet bijna niemand dit nog. De meeste mensen importeren een key en vertrouwen ’m omdat de fingerprint er ongeveer goed uitzag, wat niet echt een trust-model is.

Keyservers zijn een rommeltje

De klassieke keyservers zijn vaak traag of offline, kunnen niet verifiëren of een upload echt hoort bij de persoon die het claimt, en hebben een geschiedenis van spam en abuse. Het oude SKS keyserver network is inmiddels grotendeels kapot.

De betere optie is keys.openpgp.org, dat in elk geval verifieert dat je het email adres op de key beheert voordat het ’m uitserveert.

Metadata lekt

GPG versleutelt de inhoud en verder niets. De encrypted blob verraadt nog steeds wie de ontvanger is, de originele bestandsnaam en grootte, en wanneer het versleuteld is. Zit je in een situatie waar het bestaan van een gesprek net zo gevoelig is als de inhoud, dan weegt dat gat zwaar.

Email encryptie kwam nooit van de grond

PGP email, via tools als Enigmail, bereikte normale mensen nooit. De setup is te priegelig, de UX te ruw, en losse messengers als Signal losten hetzelfde probleem op met een fractie van de frictie. Ik ga niet doen alsof ik mijn email dagelijks versleutel, want dat doe ik niet.

Alternatieven bestaan, en dat is prima

  • age: moderne, doodsimpele file encryptie zonder key management-ceremonie
  • Signal: voor messaging speelt de UX in een andere divisie
  • Keybase: een eerlijke poging om PGP vriendelijk te maken, nu in handen van Zoom

Wanneer GPG wél het juiste gereedschap is

Met dat alles op tafel blijft GPG de beste optie voor een handvol klussen:

  • Git commit signing: er is geen echte concurrent
  • Password managers (pass): GPG is simpelweg de standaard waar het op gebouwd is
  • Software signing: package managers verwachten GPG signatures, dus je komt ze tegemoet
  • Encrypted backups: oud, saai, overal ondersteund, precies wat je voor backups wilt
  • Interoperabiliteit: iedereen met GPG kan lezen wat je stuurt, zonder account of app

Mijn setup

# ~/.gnupg/gpg.conf
default-key ABC123...
keyserver hkps://keys.openpgp.org
auto-key-retrieve

# Moderne crypto voorkeuren
personal-cipher-preferences AES256 AES192 AES
personal-digest-preferences SHA512 SHA384 SHA256
personal-compress-preferences ZLIB BZIP2 ZIP Uncompressed

Mijn master key zit op een air-gapped machine. De subkeys zitten op een YubiKey. In de praktijk gebruik ik GPG voor drie dingen:

  • Git commit signing
  • Pass, mijn password manager
  • Af en toe een bestand versleutelen

Voor chatten gebruik ik Signal, en voor snelle wegwerp-encryptie pak ik soms age. GPG hoeft niet alles te doen om de moeite waard te zijn.

Praktische tips

1. Backup je keys

# Nu. Voordat je het vergeet.
gpg --armor --export-secret-keys > ~/backup/gpg-secret-keys.asc
gpg --armor --export > ~/backup/gpg-public-keys.asc
gpg --export-ownertrust > ~/backup/gpg-ownertrust.txt

Zet dit op een encrypted USB stick, ergens veilig, en doe het nu. Verlies je je enige kopie van een private key, dan is er geen helpdesk om te bellen. De wiskunde trekt zich niets aan van of het per ongeluk ging.

2. Zet een calendar reminder voor expiry

Keys verlopen, en dat is met opzet. Maar vergeet je op tijd te verlengen, dan sluit je jezelf buiten van je eigen versleutelde bestanden. Toekomstige jij zal het niet grappig vinden.

gpg --edit-key tom@example.com
gpg> expire
# Kies nieuwe datum
gpg> save

3. Gebruik een goede passphrase

Je passphrase is het slot op je private key. Maak ’m lang en onvoorspelbaar, en laat een password manager ’m onthouden zodat je niet in de verleiding komt iets te kiezen wat je uit je hoofd kunt typen.

4. Verifieer fingerprints out-of-band

Als je iemands public key importeert, bevestig de fingerprint via een apart kanaal, zoals een telefoontje of in persoon. Keyservers kunnen gecompromitteerd zijn, en een fingerprint die je zelf checkte is meer waard dan een die een server je aanreikt.

Waar je mag stoppen

Denk terug aan de simpelste versie van het begin: één commando, één keypair, werkende crypto in vijf minuten. Dat is nog steeds het hele fundament. Alles daarna, subkeys, hardware tokens, keyservers, was optionele diepte die je toevoegt als je ’m nodig hebt.

Dus is GPG de moeite waard om te leren? Ja, als je git commits wilt signen, pass wilt gebruiken, bestanden netjes wilt versleutelen, of software die je downloadt wilt verifiëren. Sla het over als je alleen veilig wilt chatten, want daar wint Signal, of triviale file encryptie wilt, want daar is age vriendelijker. En als CLI-papercuts je dag echt verpesten, stap dan met open ogen in.

Mijn advies: begin in het ondiepe. Genereer een key, zet signed git commits aan, en leef daar een tijdje mee. Subkeys en YubiKeys kunnen wachten tot de dag dat je ze echt wilt.

GPG doet me denken aan vim. De leercurve is steil en een tikje vijandig, maar zodra je eroverheen bent, merk je de frictie niet meer en doe je gewoon het werk. En het werk dat het doet, je eigen keys bezitten in plaats van vertrouwen huren van een platform, is de klim waard.

Resources: