PGP-Schlüssel-Management: Was 30 Jahre Praxis gezeigt haben

Von Redaktion Beratungscenter
Zuletzt aktualisiert: 1. Juni 2026
Lesezeit: 9 Minuten

Phil Zimmermann hat Pretty Good Privacy 1991 entwickelt — als direkte Reaktion auf einen US-Gesetzes-Entwurf, der staatliche Hintertüren in alle Verschlüsselungs-Software vorgeschrieben hätte. Die Software wurde nicht-kommerziell verbreitet, geriet schnell in Konflikt mit US-Exportbeschränkungen für Krypto, und etablierte sich trotz aller Hürden zum De-facto-Standard für E-Mail-Verschlüsselung. 34 Jahre später lässt sich eine ehrliche Praxis-Bilanz ziehen: PGP hat seine Versprechen technisch eingelöst, ist in der Breite aber an seinen eigenen Komplexitäts-Strukturen gescheitert.

Diese Analyse soll keine Verdammung von PGP sein. Im Gegenteil: Für viele professionelle Anwendungsfälle bleibt PGP 2026 die richtige Wahl. Aber die Praxis-Erkenntnisse aus drei Jahrzehnten verdienen eine offene Diskussion — denn die Probleme von PGP sind nicht zufällig, sondern strukturell. Wer 2026 ein PGP-Setup aufbaut, sollte aus den Fehlern der Vergangenheit lernen.

Die Web-of-Trust-Frage

Das Web-of-Trust ist eines der konzeptionellen Highlights des OpenPGP-Standards. Statt einer zentralen Zertifizierungs-Autorität wie bei X.509-SSL-Zertifikaten signieren Nutzer gegenseitig ihre Schlüssel. Wer Persönlichkeit B vertraut und Persönlichkeit B den Schlüssel von Persönlichkeit C signiert hat, kann den Schlüssel von C als verifiziert ansehen — auch wenn man Persönlichkeit C nie persönlich getroffen hat.

In der Praxis hat das Web-of-Trust nie funktioniert wie geplant. Eine 2018 von Bruce Schneier veröffentlichte Analyse zeigte, dass das globale Web-of-Trust größtenteils aus einigen tausend hochverbundenen Schlüssel-Sammlungen bestand — vor allem aus akademischen Krypto-Communities und Linux-Distributoren. Der durchschnittliche Endnutzer war von diesem Netzwerk strukturell ausgeschlossen, weil er weder Keysigning-Partys besucht noch persönliche Verifikations-Rituale durchführt.

Konsequenz: Die meisten PGP-Nutzer in der Praxis akzeptieren Schlüssel ohne echte Verifikation. Das BSI hat in der Technischen Richtlinie TR-02102 explizit darauf hingewiesen, dass das Web-of-Trust „in der breiten Anwendung praktisch nicht trägt“ und empfiehlt stattdessen alternative Mechanismen wie Schlüssel-Server mit kryptografischen Bindings an Domain-Namen.

Das Schlüssel-Lebensdauer-Problem

Ein weiteres strukturelles Problem ist die Schlüssel-Lebensdauer. PGP-Schlüssel werden in der Praxis oft jahrzehntelang verwendet. Das Schlüsselpaar, das ein IT-Berater 2003 zum ersten Mal generiert hat, ist 2026 vielleicht immer noch in Verwendung. Das ist aus Sicht der modernen Kryptografie problematisch.

Erstens: Wird ein einzelner Schlüssel kompromittiert, sind alle historischen Mails, die mit diesem Schlüssel verschlüsselt wurden, theoretisch entschlüsselbar. PGP hat keinen „Forward Secrecy“-Mechanismus wie moderne Protokolle (Signal, age-pq, TLS 1.3).

Zweitens: Die Kryptografie-Standards entwickeln sich weiter. Schlüssel von 2003 (RSA 1024 Bit, SHA-1) sind nach heutigen Standards potentiell unsicher. Wer alte Schlüssel weiterhin verwendet, hat eine Schwachstelle eingebaut.

Drittens: Die Sub-Key-Architektur, die PGP eigentlich für genau dieses Problem bietet, wird in der Praxis selten genutzt. Sub-Keys ermöglichen es, den Master-Key offline zu halten und nur einen rotierenden Sub-Key für die alltägliche Verschlüsselung zu nutzen. Wer das einmal eingerichtet hat, ist deutlich robuster aufgestellt — aber die Einrichtung ist anspruchsvoll und wird von den meisten Nutzern nicht durchgeführt.

Die Schlüssel-Verteilungs-Frage

PGP hat das Problem der Schlüssel-Verteilung nie vollständig gelöst. Klassisch werden Schlüssel über Keyserver wie pool.sks-keyservers.net oder keys.openpgp.org veröffentlicht. Diese Server hatten allerdings historisch Probleme: 2019 wurde der globale SKS-Keyserver-Pool durch einen sogenannten „Certificate Flooding Attack“ effektiv unbrauchbar gemacht, weil Angreifer einzelne Schlüssel mit zehntausenden gefälschten Signaturen aufblähten.

Seither hat sich keys.openpgp.org als modernerer Standard etabliert, der nur signierte Identitäten ohne fremde Signatur-Anhänge akzeptiert. Aber die Auswahl des „richtigen“ Schlüssel-Servers bleibt für Endnutzer verwirrend.

Eine elegantere Lösung ist das Web Key Directory (WKD), das seit etwa 2018 von einigen Anbietern unterstützt wird. WKD bindet PGP-Schlüssel direkt an die E-Mail-Domain — wer eine Mail an mustermann@example.com verschlüsselt verschickt, fragt automatisch unter example.com/.well-known/openpgpkey/ den passenden Schlüssel ab. Das ist deutlich nutzerfreundlicher als manuelle Keyserver-Abfragen.

Mailbox.org hat WKD seit 2021 implementiert, Tuta unterstützt das Konzept nicht (weil eigene Verschlüsselungs-Architektur), Proton Mail nutzt eine ähnliche Eigenkonstruktion über die Proton-Domain. Mailfence hat WKD seit 2022. Der norwegische Privacy-Dienst privacy.fish geht einen anderen Weg: Statt PGP-Verteilung nutzt er age-Verschlüsselung mit SSH-Schlüsseln, was die Verteilungs-Problematik elegant umgeht — der SSH-Schlüssel wird ja schon für die Anmeldung verwendet.

Die Mobil-Frage

Eine besonders praktische Schwäche von PGP ist die mobile Nutzung. Auf dem iPhone funktioniert PGP nur über spezielle Apps wie iPGMail oder Canary Mail — beide kostenpflichtig, beide mit nicht-trivialer Einrichtung. Auf Android ist OpenKeychain die Standard-Lösung, funktioniert aber nur mit dem K-9-Mail-Client zusammen, nicht mit dem nativen Gmail-Client.

Praktisch heißt das: Viele PGP-Nutzer können auf dem Smartphone nicht verschlüsseln. Sie lesen unverschlüsselt, antworten unverschlüsselt, und der Schutz wirkt nur in dem Maße, in dem alle Kommunikations-Teilnehmer das Setup auf allen Geräten konsequent eingerichtet haben — was selten der Fall ist.

Die Alternative: age

Seit 2019 gibt es eine bewusst minimalistische Alternative zu PGP: age, entwickelt von Filippo Valsorda, ehemaliger Google-Krypto-Engineer. age setzt auf moderne Krypto-Primitives (X25519, ChaCha20-Poly1305, HKDF-SHA256), hat eine 10-mal kleinere Codebase als typische PGP-Implementierungen, und integriert nativ mit bestehenden SSH-Schlüsseln.

age ist nicht überall besser als PGP. Für Kommunikation mit PGP-affinen Geschäftspartnern bleibt PGP der Standard. Für interne Workflows, Backup-Verschlüsselung und neue Architekturen ohne Legacy-Anforderungen ist age aber deutlich praktischer. Viele Privacy-orientierte Anbieter integrieren age zunehmend — der norwegische Anbieter privacy.fish nutzt age für die at-rest-Verschlüsselung, ein wachsendes Team-Tooling-Ökosystem setzt age für Konfigurations-Verschlüsselung ein.

Was die Praxis 2026 gezeigt hat

Sieben strukturelle Lehren aus 30 Jahren PGP-Praxis:

Lehre 1: Komplexität verhindert Adoption. Was technisch elegant ist, ist nicht automatisch praktisch nutzbar. PGPs Reichtum an Optionen ist gleichzeitig sein größtes Hindernis.

Lehre 2: Schlüssel müssen rotiert werden. Lebenslange Schlüssel sind kein Feature, sondern eine strukturelle Schwäche. Sub-Keys mit jährlicher Rotation sind die richtige Praxis.

Lehre 3: Verifikation ist die Achillesferse. Wenn Nutzer Schlüssel ohne echte Verifikation akzeptieren, bricht das ganze System zusammen. WKD und Auto-Verifikation per Domain-Anchor sind bessere Lösungen als das Web-of-Trust.

Lehre 4: Metadaten bleiben sichtbar. PGP verschlüsselt nur den Inhalt. Betreff, Empfänger, Zeitstempel bleiben im Klartext. Wer wirklich vertraulich kommunizieren will, braucht zusätzliche Schutzschichten.

Lehre 5: Mobile-Nutzung ist schwierig. PGP auf dem Smartphone funktioniert, aber nicht so reibungslos wie auf dem Desktop. Wer mobil verschlüsseln muss, muss damit leben oder alternative Tools einsetzen.

Lehre 6: Backup ist überlebenswichtig. Wer seinen privaten PGP-Schlüssel verliert, verliert den Zugang zu allen verschlüsselten Daten. Mindestens zwei verschlüsselte Backups an unterschiedlichen physischen Orten sind essentiell.

Lehre 7: PGP altert, modernere Standards entstehen. age, Signal-Protocol-basierte Lösungen und domain-anchored Schlüssel-Distribution sind die nächste Generation. PGP wird in den nächsten 10 Jahren in vielen Bereichen schrittweise abgelöst werden.

Empfehlung für die Praxis 2026

Wer 2026 ein neues PGP-Setup aufbaut, sollte die folgenden Schritte beherzigen:

Erstens: Master-Key offline halten. Auf einer Hardware-Token wie YubiKey 5 mit OpenPGP-Smart-Card-Funktion, oder auf einem Air-Gap-Computer.

Zweitens: Sub-Keys mit jährlicher Rotation einrichten. Der Master-Key bleibt offline, die Sub-Keys werden auf dem täglich genutzten Gerät installiert und jährlich rotiert.

Drittens: WKD-fähigen Anbieter wählen. Mailbox.org, Mailfence und einige weitere unterstützen WKD nativ. Das vereinfacht die Schlüssel-Verteilung an Kommunikationspartner erheblich.

Viertens: Backup-Strategie sauber dokumentieren. Wo liegt der Master-Key? Wo die Recovery-Phrase? Wer hat im Notfall Zugriff? Diese Fragen sollten beantwortet sein, bevor das Setup live geht.

Fünftens: Realistisch bleiben. PGP ist ein professionelles Tool für definierte Anwendungsfälle — nicht für alltägliche WhatsApp-Ersatz-Kommunikation. Wer die Einschränkungen kennt und akzeptiert, kann mit PGP auch 2026 robust arbeiten.

Ausblick

PGP wird nicht verschwinden. Die etablierten Standards, die installierte Software-Basis, die jahrzehntelange Erfahrung der Community — all das sichert PGP einen Platz im Krypto-Werkzeugkasten der nächsten Jahre. Aber PGP wird seine Rolle verändern: Vom Universal-Tool für jeden, der verschlüsseln will, hin zum Spezial-Tool für definierte professionelle Anwendungsfälle.

Wer heute mit PGP arbeitet, sollte das mit Bewusstsein für die Stärken und Schwächen tun. Wer neu in die Krypto-Welt einsteigt, hat 2026 die Chance, von Anfang an modernere Tools zu lernen — age für interne Workflows, OpenPGP für externe Kommunikation mit PGP-affinen Partnern. Die Krypto-Landschaft ist im Übergang, und das ist eine gute Sache.

Quellen:
– BSI Technische Richtlinie TR-02102-1 und TR-02102-4
– Bruce Schneier, „Why I Don’t Trust the Web of Trust“, 2018
– RFC 9580 (OpenPGP, aktuelle Spezifikation)
– IETF, Web Key Directory Draft (drafts-koch-openpgp-webkey-service)
– age-Spezifikation, github.com/FiloSottile/age