PGP und S/MIME

Das Problem: Mail-Inhalte beim Provider

Wie im Artikel e-mail-sicherheit-grundlagen gezeigt: deine Mail liegt beim Anbieter im Klartext, auch wenn TLS für den Transport sorgt. Wer den Anbieter kompromittiert (technisch, rechtlich, durch Insider), sieht alles.

Für viele Anwendungen ist das akzeptabel — du vertraust deinem Provider, die Inhalte sind nicht sensitiv. Für andere Anwendungen reicht das nicht:

• Anwalts-Mandanten-Korrespondenz (Mandantengeheimnis).
• Gesundheits-Daten zwischen Ärzt:innen, Patient:innen, Apotheke.
• Journalistische Quellen-Kommunikation.
• Geschäfts-Strategien, M&A-Vorbereitungen in Konzernen.
• Whistleblowing-Korrespondenz.

Die Antwort: Ende-zu-Ende-Verschlüsselung. Der Mail-Inhalt wird auf dem Sender-Gerät verschlüsselt, durchläuft alle Zwischen-Server unentschlüsselbar, wird erst auf dem Empfänger-Gerät entschlüsselt.

Zwei Verfahren haben das produktive geschafft:

• OpenPGP (auch „PGP" oder „GPG"-Implementierung) — vor allem im Open-Source- und Aktivismus-Umfeld.
• S/MIME — vor allem in Unternehmen und Behörden mit zentral verwaltetem Zertifikats-Management.

PGP/OpenPGP: das Web-of-Trust-Modell

PGP (Pretty Good Privacy) wurde 1991 von Phil Zimmermann veröffentlicht. Die Open-Standard-Variante heißt OpenPGP (RFC 4880, 2007; modernisiert in RFC 9580, 2024); die wichtigste freie Implementierung ist GnuPG (GPG).

Grundprinzip:

• Jede:r Nutzer:in erzeugt ein Schlüsselpaar: einen privaten Schlüssel (bleibt auf dem Gerät, mit Passwort geschützt) und einen öffentlichen Schlüssel (wird verteilt).
• Wenn Alice an Bob schreiben will: sie holt sich Bobs Public Key und verschlüsselt die Mail damit. Nur Bob mit seinem Private Key kann sie entschlüsseln.
• Wenn Alice signieren will: sie nutzt ihren Private Key, Empfänger:innen können mit ihrem Public Key prüfen, dass sie wirklich von Alice kommt.

Web of Trust ist das Vertrauens-Modell:

• Keine zentrale Autorität verbürgt sich für Schlüssel.
• Stattdessen signieren Nutzer:innen gegenseitig ihre Schlüssel, wenn sie die Identität persönlich verifiziert haben.
• Daraus entsteht ein Netz von Vertrauens-Verbindungen: wenn ich Carol vertraue und Carol Bob signiert hat, vertraue ich Bobs Schlüssel mit hoher Wahrscheinlichkeit.

In der Praxis funktioniert das Web of Trust nur in engen Communities (Linux-Distros-Maintainer, NGO-Netzwerke, Kryptographie-Communities). Für die breite Mainstream-Nutzung ist es zu umständlich.

Schlüssel-Verteilung:

• Keyserver (keys.openpgp.org, ehemals SKS-Pool) — du lädst deinen Public Key hoch, Empfänger:innen suchen ihn dort.
• WKD (Web Key Directory) — Anbieter wie Mailbox.org, Posteo, Proton publishen Public Keys über eigene HTTPS-Endpoints. Moderner Mechanismus, breitere Adoption seit 2018.
• Direkter Austausch — Public Key als Datei oder Text in einer ersten unverschlüsselten Mail mitschicken.

S/MIME: das CA-basierte Modell

S/MIME (Secure/Multipurpose Internet Mail Extensions) ist die Alternative — das gleiche Grundprinzip (Public/Private Key, Verschlüsselung, Signaturen), aber mit anderem Vertrauens-Modell.

CA-basiertes Vertrauen:

• Eine Certificate Authority (CA) verbürgt sich für die Identität des Schlüssel-Inhabers.
• Die CA stellt ein X.509-Zertifikat aus, das den Public Key mit der Mail-Adresse und Identitäts-Informationen verknüpft.
• Empfänger:innen vertrauen, weil sie der CA vertrauen — analog zum TLS-Modell im Web.

Vorteile:

• Einfacher zu skalieren in Unternehmen — IT-Abteilung managt CAs zentral, gibt Zertifikate an Mitarbeitende aus.
• In Outlook und vielen Mail-Clients eingebaut, oft mit besserer UX als PGP.
• Strukturell ähnlich zu TLS-Zertifikaten, was die Verwaltung erleichtert.

Nachteile:

• Du vertraust der CA. Wenn die CA kompromittiert oder gerichtlich gezwungen wird, kann sie potenziell auch falsche Zertifikate ausstellen.
• Kommerziell — die meisten S/MIME-Zertifikate kosten Geld; kostenlose Optionen sind selten und oft beschränkt.
• Weniger Open-Source-Verbreitung als PGP.

Wo S/MIME besonders verbreitet ist:

• Unternehmen mit internem Microsoft Active Directory + Active Directory Certificate Services.
• Behörden in mehreren EU-Ländern (Deutschland: V-PKI, S-MIME-Zertifikate im Behörden-Verkehr).
• Branchen mit Compliance-Anforderungen (Anwaltskanzleien, Banken, Gesundheitswesen).

In gemischten Umgebungen treffen PGP und S/MIME oft aufeinander. Mail-Clients wie Thunderbird unterstützen beide; Outlook hat S/MIME nativ und PGP über Add-Ons.

Der praktische PGP-Workflow

So sieht ein realistisches PGP-Setup mit Thunderbird (Stand 2026) aus:

1. Schlüssel-Erstellung (10 Minuten):

• Thunderbird → Account-Einstellungen → Ende-zu-Ende-Verschlüsselung → „OpenPGP-Schlüssel hinzufügen" → „Schlüssel erstellen".
• Schlüssel-Typ: RSA 4096 oder Ed25519/Curve25519 (modern, schneller, kleinere Schlüssel).
• Gültigkeitsdauer: 2–5 Jahre ist sinnvoll. Schlüssel mit Verfallsdatum sind besser als „nie ablaufend".
• Passphrase: sehr lang und einmalig (Diceware-Wörter). Schützt den privaten Schlüssel im Dateisystem.

2. Schlüssel veröffentlichen:

• Public Key bei keys.openpgp.org hochladen.
• Optional: Public Key auf deiner Webseite veröffentlichen.
• Optional: bei Proton, Mailbox.org, Posteo — der Anbieter kann Public Keys via WKD automatisch ausliefern.

3. Schlüssel-Backup:

• Privater Schlüssel + Passphrase auf einem separaten verschlüsselten USB-Stick sichern — Verlust = alle verschlüsselten Mails dauerhaft unlesbar.
• Revocation Certificate (Widerrufs-Zertifikat) ebenfalls speichern — damit kannst du deinen Schlüssel später als ungültig markieren, falls er kompromittiert wird.

4. Empfänger-Public-Keys importieren:

• Empfänger:in schickt dir den Public Key (als .asc-Datei oder Block) → in Thunderbird importieren.
• Oder Thunderbird sucht automatisch über Keyserver / WKD.
• Vor erstem Verschlüsseln: Fingerprint mit Empfänger:in über einen zweiten Kanal verifizieren (Telefon, persönlich, Signal). Verhindert Man-in-the-Middle.

5. Verschlüsselt schreiben:

• Mail wie gewohnt verfassen.
• Im Schreiben-Fenster: „Verschlüsseln" aktivieren. Thunderbird zeigt, ob alle Empfänger-Schlüssel verfügbar sind.
• Versand — die Mail geht E2E-verschlüsselt raus.

6. Verschlüsselt empfangen:

• Mail erscheint in der Inbox.
• Thunderbird fragt nach deiner Passphrase, entschlüsselt, zeigt den Inhalt.

Das klingt umständlich — und ist es im Vergleich zu Signal/iMessage. Wer PGP einmal eingerichtet hat, hat aber eine sehr starke Krypto-Schicht über alle Mail-Kommunikation, die er/sie damit führt.

Mail-Clients und Tools

Die wichtigsten Setup-Pfade:

Empfehlungen pro Profil:

• Anfänger:in mit Mainstream-Mail-Setup → ProtonMail. E2E zwischen Proton-Konten ist transparent; an externe Empfänger:innen funktioniert PGP eingebaut.
• Profi mit Mehrgeräte-Setup → Thunderbird + GnuPG + K-9 Mail (Android) + iPGMail (iOS) + Schlüssel-Sync über eigene Methode (USB-Stick, eigene Cloud).
• Unternehmens-Setup → S/MIME mit Active-Directory-PKI, Outlook integriert.
• Whistleblowing-Empfänger (Redaktion) → SecureDrop, nicht klassisches PGP.

Was PGP / S/MIME nicht löst

Realistische Grenzen:

• Metadaten bleiben sichtbar. Wer wem wann eine Mail schickt — sehen Provider, Mail-Server, oft Empfänger-Geräte-Logs. Subject-Zeile ist klassischerweise nicht verschlüsselt; einige PGP-Implementierungen verschlüsseln sie seit OpenPGP 4.0/2024, viele alte Setups nicht.
• Forward Secrecy fehlt. Wenn ein Angreifer später den privaten Schlüssel bekommt (Geräte-Beschlagnahme, Schlüssel-Diebstahl), kann er alle gespeicherten verschlüsselten Mails rückwirkend entschlüsseln. Moderne Messenger (Signal) haben Forward Secrecy — jede Nachricht hat ihren eigenen Sitzungs-Schlüssel.
• Mobile-Erfahrung ist schwach. Schlüssel-Verwaltung auf iOS und Android ist umständlich, viele PGP-Setups funktionieren nur auf Desktop wirklich gut.
• Kompromittiertes Endgerät umgeht alles. Wer Malware auf deinem Computer hat, sieht den Klartext nach der Entschlüsselung. PGP schützt nur den Transport-Weg, nicht das Endgerät.
• Schlüssel-Recovery ist schwer. Wenn du den privaten Schlüssel oder die Passphrase verlierst, sind alle empfangenen verschlüsselten Mails dauerhaft unlesbar. Es gibt keine Backdoor, kein „Passwort vergessen". Das ist Feature, kein Bug — aber operativ unangenehm.
• Soziale Adoptions-Hürde. Du brauchst Empfänger:innen, die PGP/S-MIME auch nutzen. Wenn dein Mandant oder deine Quelle keine Verschlüsselung kann, bringt dein Setup nichts.
• „Efail"-Klasse von Schwachstellen. 2018 zeigte das EFAIL-Paper (Münster, Bochum) mehrere PGP-Implementierungs-Bugs, die unter Umständen Klartext-Leaks ermöglichten. Patches kamen schnell, aber das illustriert: auch geprüfte Krypto kann implementierungs-seitig Lücken haben.

Diese Grenzen erklären, warum E-Mail-E2E nie Mainstream geworden ist. Für anspruchsvolle Anwendungen ist Signal oft das passendere Werkzeug — siehe sichere-messenger.

Wann PGP / S/MIME die richtige Wahl ist

Eine Übersicht nach Use-Case:

Faustregel: PGP/S-MIME ist asynchrone Mail-Sicherheit für Inhalte, die langfristig vertraulich sein müssen. Für Echtzeit-Kommunikation sind moderne Messenger besser.

Weiterführende Ressourcen

Externe Quellen

• GnuPG (GPG)
• OpenPGP – RFC 9580 (2024)
• Mailvelope (Browser-Extension)
• Thunderbird – End-to-End-Encryption Setup
• GPGTools (macOS)
• Gpg4win (Windows)
• keys.openpgp.org – Modern Keyserver
• Web Key Directory (WKD)
• EFAIL-Forschungs-Paper
• BSI – S/MIME und PGP

Verwandte Artikel

• E-Mail-Sicherheit Grundlagen
• Mail-Aliase und Wegwerfadressen
• Mail-Header und Spoofing
• Sichere Messenger
• Crypto-Grundregeln (Entwickler-Sicht)
• Tails und Whonix

Hinweis zu Inhalten: Die Informationen in diesem Artikel dienen der Aufklärung und Bildung über Ende-zu-Ende-Verschlüsselung und legitime Datenschutz-Werkzeuge. PGP, S/MIME und GnuPG werden weltweit von Anwält:innen, Ärzt:innen, Journalist:innen, Behörden und Privatpersonen mit berechtigtem Vertraulichkeits-Bedarf eingesetzt. Diese Doku ist nicht als Anleitung für rechtswidrige Handlungen gedacht. Strafrechtliche Vorgaben — insbesondere im Telekommunikations- und Strafrecht — sind in jeder Nutzung zu beachten. Im Zweifel: qualifizierte Rechtsberatung oder spezialisierte Anlaufstellen wie EFF Surveillance Self-Defense und Reporter ohne Grenzen konsultieren.