S/MIME vs. OpenPGP — End-to-End-Verschlüsselung jenseits von DKIM
DKIM signiert E-Mails kryptografisch und beweist Integrität — aber DKIM verschlüsselt nicht. Für End-to-End-Vertraulichkeit zwischen Absender und Empfänger braucht es S/MIME (RFC 8551 v4.0, April 2019) oder OpenPGP (RFC 4880, November 2007, ersetzt 2024 durch RFC 9580). Beide Verfahren liefern Verschlüsselung und digitale Signaturen, unterscheiden sich aber im Vertrauensmodell: S/MIME nutzt die klassische CA-PKI (browser-native Zertifikats-Hierarchie), OpenPGP das Web of Trust (dezentrale Schlüssel-Signierung). Dieser Deep-Dive erklärt beide Verfahren, vergleicht sie strukturiert und zeigt die typischen DACH-Anwendungsfälle.
Warum DKIM nicht für Vertraulichkeit ausreicht
DKIM (DomainKeys Identified Mail, RFC 6376) ist eine kryptografische Signatur — sie beweist, dass die Mail nicht verändert wurde und vom angegebenen Absender stammt. DKIM verschlüsselt aber NICHT den Inhalt. Mailserver auf dem Versand-Weg, Cloud-Mail-Provider, Mail-Hoster und potenziell Behörden mit Zugriff können den Klartext-Inhalt lesen. Für echte End-to-End-Vertraulichkeit zwischen Absender und Empfänger braucht es eine zusätzliche Verschlüsselungs-Schicht: S/MIME oder OpenPGP.
Diese Lücke ist 2026 zunehmend relevant: DSGVO Art. 9 (besondere personenbezogene Daten), Berufsgeheimnisse (§203 StGB DE, §54 öStrG AT, Art. 321 StGB CH), Anwaltskommunikation und Geschäftsleitungs-Korrespondenz verlangen Schutz auch vor dem eigenen Cloud-Mail-Provider. NIS2 Art. 21 Abs. 2 lit. h fordert „Konzepte und Verfahren für den Einsatz von Kryptografie und Verschlüsselung“ — End-to-End-Verschlüsselung ist die höchste verfügbare Stufe. BSI TR-03145 liefert die DACH-Referenz für S/MIME-Konfiguration.
Verschlüsselungs-Stufen im Email-Stack
- Transport-Verschlüsselung (TLS/STARTTLS): Schützt die Verbindung zwischen Mailservern. Nicht End-to-End — Mailserver lesen den Klartext.
- MTA-STS + DANE: Erzwingen TLS und verhindern Downgrade. Stärken Transport-Schutz, ändern aber nicht die End-to-End-Lücke.
- DKIM-Signierung: Beweist Integrität und Authentizität. Verschlüsselt NICHT den Inhalt.
- S/MIME oder OpenPGP (E2E): Verschlüsselt den Mail-Inhalt zwischen Absender und Empfänger. Auch der Mail-Provider sieht nur verschlüsselten Inhalt. Die einzige echte End-to-End-Verschlüsselung im Email-Stack.
S/MIME — Secure/Multipurpose Internet Mail Extensions
S/MIME (Secure/Multipurpose Internet Mail Extensions) ist seit Version 4.0 in RFC 8551 (April 2019) standardisiert — ersetzt die alte Version 3.2 aus RFC 5751 (2010). S/MIME nutzt die klassische CA-PKI (Certificate Authority Public Key Infrastructure): Zertifikate werden von vertrauenswürdigen CAs ausgestellt, das Vertrauen ist hierarchisch und browser-nativ. Im Enterprise-Umfeld ist S/MIME über Active Directory + interne CA gut skalierbar — die Standard-Wahl in Microsoft-Tenants.
Vertrauensmodell: CA-PKI
Zertifikate werden von vertrauenswürdigen CAs ausgestellt — die CA-Liste ist im Betriebssystem oder Browser hinterlegt (Apple, Microsoft, Mozilla pflegen die Root-Stores). Trust ist hierarchisch: Root-CA → Intermediate-CA → End-Entity-Zertifikat. Jeder, der einer der Root-CAs vertraut, vertraut automatisch allen darunter ausgestellten Zertifikaten. Konsequenz: Vertrauen funktioniert ohne direkte Bekanntschaft, aber die CAs werden zum Single Point of Trust.
- Standard-CAs für S/MIME-Zertifikate: DigiCert, Sectigo, GlobalSign, Entrust, Actalis (kostenlose Class-1-Zertifikate)
- Class 1: Identitäts-Verifikation per Email — günstig, niedrigste Stufe
- Class 2: Identitäts-Verifikation per Personalausweis/Reisepass
- Class 3: Identitäts-Verifikation durch persönliches Erscheinen oder Notarisierung
Algorithmen (RFC 8551 v4.0)
RFC 8551 modernisierte die Algorithmen erheblich gegenüber 5751. Mandatorische Verschlüsselung: AES-128 GCM und AES-256 GCM (MUSS). Mandatorische Signaturen: ECDSA P-256 mit SHA-256 oder EdDSA Curve25519 (MUSS). Mandatorischer Schlüsselaustausch: ECDH für P-256 und X25519 (MUSS).
- Neu in v4: AuthEnvelopedData (Vertraulichkeit + Integrität in einem Container)
- Neu in v4: AES-256 GCM und ChaCha20-Poly1305 als moderne AEAD-Modi
- Neu in v4: EdDSA und ECDSA als Signatur-Standards
- Neu in v4: SHA-512 als zusätzlicher Hash-Algorithmus
- Veraltet: TripleDES und SHA-1 sind als deprecated markiert
- RSA-Empfehlung: 3072-Bit minimum (NIST SP 800-131A)
Native Mail-Client-Integration
S/MIME ist in Outlook (Windows, Mac), Apple Mail (iOS, macOS) und Mozilla Thunderbird nativ integriert. Zertifikat-Installation via Windows-Zertifikatsspeicher / macOS Schlüsselbund. Bei signierten Mails wird das Absender-Zertifikat automatisch im Adressbuch des Empfängers gespeichert — danach kann verschlüsselt werden.
- Outlook: Datei → Optionen → Trust Center → Email-Sicherheit → Standardeinstellung „Signieren“ oder „Verschlüsseln“
- Apple Mail: Schlüsselbund-Konfiguration, automatische Anzeige im Hauptbildschirm-Mail-Header
- Mozilla Thunderbird: Einstellungen → Konten-Einstellungen → End-to-End-Verschlüsselung
- Microsoft 365 Enterprise: zentrale Zertifikats-Verwaltung über Azure AD / Intune
OpenPGP — Pretty Good Privacy als offener Standard
OpenPGP (Pretty Good Privacy, RFC 4880, November 2007) ist die formalisierte Variante des originalen PGP von Phil Zimmermann (1991). RFC 4880 wurde 2024 durch RFC 9580 (Crypto Refresh) ersetzt. OpenPGP nutzt das Web of Trust: Nutzer signieren gegenseitig die Schlüssel anderer Nutzer, das Vertrauen ist dezentral und community-basiert. Implementierungen: GnuPG (Referenz, gnupg.org), OpenPGPjs (Browser, openpgpjs.org), Sequoia-PGP (Rust, sequoia-pgp.org).
Vertrauensmodell: Web of Trust
Nutzer signieren gegenseitig die Schlüssel anderer Nutzer — eine Signatur bestätigt: „Ich habe verifiziert, dass dieser öffentliche Schlüssel zu dieser Identität gehört.“ Vertrauen ist dezentral und transitiv: Wenn Sie Alice vertrauen und Alice Bobs Schlüssel signiert hat, können Sie indirekt auch Bobs Schlüssel vertrauen. Die OpenPGP-Spezifikation beschreibt vier Zertifizierungs-Stufen (0x10 bis 0x13) — von „generisch“ bis „positive Zertifizierung mit ID-Prüfung“.
- Keyserver wie keys.openpgp.org (modern, datenschutzfreundlich) als zentrale Schlüssel-Verteilung
- Web of Trust funktioniert dezentral — keine CA als Single Point of Trust
- Risiko: Vertrauenskette kann manipuliert werden, wenn Schlüssel-Verifikation fahrlässig ist
- Best Practice: Schlüssel-Fingerprint persönlich oder über sichere Out-of-Band-Kanäle verifizieren
Algorithmen (RFC 4880 + RFC 9580)
RFC 4880 unterstützt asymmetrische Verfahren (RSA, DSA, ElGamal), symmetrische Verschlüsselung (IDEA, CAST5, TripleDES, AES, Twofish, Camellia) und Hash-Verfahren (MD5, RIPEMD-160, SHA-Familie). Der Nachfolger RFC 9580 (Juli 2024, „crypto refresh“) modernisiert: Ed25519 und X25519 als neue Standards, AES-OCB als AEAD-Mode, ChaCha20-Poly1305. MD5 und SHA-1 sind als deprecated markiert.
- Asymmetrisch: RSA (klassisch), Ed25519 (modern, RFC 9580)
- Symmetrisch: AES-256 (Standard), ChaCha20-Poly1305 (modern)
- Hash: SHA-256 / SHA-512 (Standard)
- Kompression: ZIP, ZLIB, BZIP2 (kann Side-Channel-Angriffe ermöglichen, deshalb optional)
Mail-Client-Integration
OpenPGP ist in Thunderbird seit Version 78 (2020) nativ integriert — kein Enigmail-Plugin mehr nötig. Outlook benötigt Plugins wie GpgOL (Teil der Gpg4win-Suite, kostenlos). Apple Mail benötigt GPGTools-Suite (kommerziell). Proton Mail nutzt OpenPGPjs nativ im Browser — kein Setup nötig, alle Proton-zu-Proton-Mails sind automatisch verschlüsselt.
- Thunderbird 78+: native OpenPGP-Unterstützung (Einstellungen → Konten → End-to-End-Verschlüsselung)
- Outlook (Windows): Gpg4win + GpgOL-Plugin (gpg4win.org, kostenlos)
- Apple Mail (macOS): GPGTools (gpgtools.org, kommerziell)
- Proton Mail: OpenPGPjs nativ, automatische Verschlüsselung zwischen Proton-Nutzern
- Mobile: K-9 Mail (Android) mit OpenKeychain, Canary Mail (iOS/macOS)
S/MIME vs. OpenPGP — direkter Vergleich
| Aspekt | S/MIME | OpenPGP |
|---|---|---|
| Standard | RFC 8551 v4.0 (April 2019) | RFC 4880 (Nov 2007), RFC 9580 (Juli 2024) |
| Vertrauensmodell | CA-PKI (hierarchisch, browser-nativ) | Web of Trust (dezentral, community-basiert) |
| Standard-Verschlüsselung | AES-128 GCM / AES-256 GCM | AES-256, ChaCha20-Poly1305 (RFC 9580) |
| Standard-Signatur | ECDSA P-256 + SHA-256, EdDSA Curve25519 | RSA, Ed25519 (RFC 9580) |
| Zertifikat-Quelle | Kostenpflichtige CAs (DigiCert, Sectigo, GlobalSign) oder Actalis Free | Eigener Schlüsselpaar mit GnuPG erzeugt, gegenseitige Web-of-Trust-Signaturen |
| Kosten | Kostenpflichtig pro Jahr/Person (Class 2), Actalis Free kostenlos (Class 1) | Kostenlos (Open-Source-Stack) |
| Outlook-Support | Nativ | Über Plugin (Gpg4win + GpgOL) |
| Thunderbird-Support | Nativ | Nativ seit v78 |
| Apple Mail-Support | Nativ | Über GPGTools (kommerziell) |
| Browser-Support | Begrenzt (Outlook Web App mit Add-In) | Über OpenPGPjs (Proton Mail, Mailfence) |
| Enterprise-Skalierung | Sehr gut (AD + interne CA + GPO) | Schwieriger (dezentrale Schlüssel-Verteilung) |
| DACH-Verbreitung | Standard im Enterprise (Banken, Behörden) | Standard bei Tech-Community, NGOs, Journalisten |
Warum E2E-Mail-Verschlüsselung im DACH-Raum unterrepräsentiert ist
Trotz starker Standards (S/MIME v4 von 2019, OpenPGP von 2007/2024) bleibt die DACH-Adoption deutlich unter 5 % der Email-Volumen. Vier strukturelle Hindernisse erklären diesen Stand: Schlüsselverwaltung, Adressbuch-Pflege, Mail-Client-Heterogenität und Recovery-Risiko. Wer E2E erfolgreich einführt, muss diese Hindernisse explizit adressieren.
Schlüsselverwaltung-Komplexität
Nutzer müssen private Schlüssel sicher aufbewahren und Backup verwalten. Bei Hardware-Defekt oder Passwort-Verlust sind verschlüsselte Inhalte verloren — bei S/MIME-CA-PKI gibt es Key-Escrow-Optionen, bei OpenPGP nicht. Mitigation: Smart-Cards (YubiKey OpenPGP-Smartcard, Nitrokey), HSM-Integration im Enterprise, Backup-Subkeys.
Adressbuch-Pflege
Die öffentlichen Schlüssel aller Kommunikationspartner müssen verfügbar sein. Bei S/MIME: Empfang einer signierten Mail liefert das Zertifikat automatisch ins Adressbuch. Bei OpenPGP: Keyservers (keys.openpgp.org) als zentrale Verteilung, aber Schlüssel-Fingerprint-Verifikation Pflicht für Vertrauen. Mitigation: zentrale Adressbuch-Pflege im Enterprise via Active Directory / LDAP-Integration.
Mail-Client-Heterogenität
Nicht jeder Empfänger nutzt einen E2E-fähigen Client. Mobile-Apps haben oft eingeschränkte Unterstützung. Bei Webmail-Empfang (Gmail Web, Outlook Web App ohne Add-In) kann der Empfänger verschlüsselte Mails gar nicht öffnen. Mitigation: explizite Liste der unterstützten Client-Konfigurationen pro Empfänger-Gruppe, ggf. „Fallback auf TLS-Transport“ für inkompatible Empfänger.
Recovery-Risiko
Bei Passwort- oder Schlüssel-Verlust sind verschlüsselte Mails endgültig verloren. Im Enterprise-Umfeld ein Compliance-Risiko (Archivierungs-Pflichten, eDiscovery). Mitigation: Key-Escrow-Verfahren bei S/MIME (Master-Key beim Compliance-Officer), für OpenPGP eigene Backup-Strategien, sichere Recovery-Codes.
Welcher Pfad für welche Organisation?
Microsoft-Tenant (M365) — S/MIME zentral
Standard-Pfad für Enterprise-DACH-Organisationen mit Microsoft 365. Zentrale CA via Active Directory Certificate Services oder Microsoft 365 + Azure AD-Zertifikate. GPO-Rollout für alle Nutzer-Konten, automatische S/MIME-Aktivierung in Outlook. Bei BYOD-Geräten Intune-Integration. Zertifikat-Lifecycle (Rotation, Revocation) zentral verwaltbar.
Cross-Organisation — OpenPGP über Thunderbird
Standard-Pfad für Open-Source-Projekte, NGOs, Journalisten ohne gemeinsame CA-Hierarchie. Thunderbird mit nativem OpenPGP-Support (seit v78), GnuPG-Backend für Schlüsselverwaltung. Schlüssel auf Keyservers (keys.openpgp.org) veröffentlichen, Web-of-Trust-Signaturen bei Konferenzen und Treffen aufbauen. YubiKey OpenPGP-Smartcards für sichere Schlüssel-Aufbewahrung.
Schweizer Privacy-Anspruch — Proton Mail
Standard-Pfad für Anwaltskanzleien, Notare, medizinische Praxen mit höchstem Privacy-Anspruch. Proton Mail (Proton AG, Genf — siehe Proton Mail Deep-Dive) nutzt OpenPGPjs nativ im Browser, alle Proton-zu-Proton-Mails sind automatisch verschlüsselt. Externe Empfänger erhalten verschlüsselte Mails über Web-Link mit Passwort. Custom-Domain ab Mail Plus.
Heterogene Umgebung — beide Mechanismen parallel
Organisationen mit gemischten Empfänger-Gruppen (interne Mitarbeiter mit S/MIME, externe Partner mit OpenPGP) müssen beide Mechanismen parallel betreiben. Outlook + GpgOL-Plugin unterstützt beide. Thunderbird (S/MIME + OpenPGP) ist die offenste Wahl. Mailfence (Belgien) unterstützt beide cloud-seitig.
DACH-Toolkit: Konkrete Mail-Client- und CA-Empfehlungen
Wer S/MIME oder OpenPGP in DACH-Organisationen einführen will, scheitert oft an der Tool-Auswahl. Die folgende Übersicht listet die in der DACH-Praxis bewährten Mail-Client-Konfigurationen und CA-/Schlüssel-Tools — mit Aktualitätsstand 2026 und konkreten Versions-Empfehlungen.
Outlook (Windows) — Gpg4win 5.0.2
Die einzige DACH-relevante OpenPGP-Lösung für Outlook ist Gpg4win (kostenlos, Free Software). Aktuelle Version 5.0.2 (Stand Januar 2026) enthält Kleopatra (Schlüssel-Verwaltung), GnuPG (Krypto-Backend) und GpgOL (Outlook-Plugin). Installation per Klick, Schlüssel-Generation per Kleopatra-Wizard. Bundesamt für Sicherheit in der Informationstechnik (BSI) hat Gpg4win-Entwicklung historisch mitfinanziert — der deutsche Bundesstandard für E-Mail-Verschlüsselung.
- OpenPGP-Schlüssel als YubiKey-Smart-Card-Variante möglich (PIV / OpenPGP-Card-Spec 2.1)
- S/MIME-Support ist in Outlook nativ — Gpg4win deckt OpenPGP-Lücke
- Quelle: gpg4win.org (Abruf 19. Mai 2026)
Thunderbird — nativ ab v78
Mozilla Thunderbird hat seit Version 78 (2020) nativen OpenPGP-Support — kein Enigmail-Plugin mehr nötig. Schlüssel-Erzeugung über Einstellungen → Konten-Einstellungen → End-to-End-Verschlüsselung. S/MIME ist ebenfalls nativ integriert. Damit ist Thunderbird der einzige Mainstream-Mail-Client mit beiden E2E-Verfahren ohne externe Plugins — ideal für gemischte Empfänger-Gruppen (S/MIME-Partner + OpenPGP-Partner).
- Schlüssel-Backup als ASCII-Armored-Datei plus Passphrase getrennt aufbewahrt
- Web-of-Trust-Signaturen via Trust-Override-Funktion
- Mobile-Pendant: K-9 Mail (Android) mit OpenKeychain — gleiche Schlüssel-Datenbasis möglich
S/MIME-Zertifikat-Bezug
Kommerzielle CAs für S/MIME-Klasse-2/3-Zertifikate (Identitäts-Verifikation per Ausweis/persönliches Erscheinen): DigiCert (kostenpflichtig pro Jahr/Person), Sectigo (analog), GlobalSign, Entrust. Klasse-1 (nur E-Mail-Verifikation) kostenlos bei Actalis (Italien) — wird teilweise als „Free S/MIME Certificate“ beworben, ist für DACH-Behörden-Kommunikation aber zu schwach (keine offizielle Identitäts-Bindung). Für Enterprise-Tenant: eigene Microsoft Active Directory Certificate Services (AD CS) oder Microsoft 365 Cloud-CA.
- BSI TR-03145 dokumentiert empfohlene Schlüssel-Mindestlängen und Algorithmus-Wahl
- Rotation der Zertifikate alle 1-2 Jahre (typische CA-Laufzeit)
- Revocation-Pfad: CRL oder OCSP — bei Schlüssel-Kompromiss sofort widerrufen
Proton Mail — Browser-natives OpenPGP
Wer keine eigene Schlüsselverwaltung betreiben will, nutzt Proton Mail mit Custom-Domain. OpenPGPjs läuft im Browser, alle Proton-zu-Proton-Mails sind automatisch verschlüsselt. Externe Empfänger erhalten verschlüsselte Mails als Web-Link mit zusätzlichem Passwort. Trade-off: kein S/MIME-Support, eingeschränkte Office-Suite, lokale Verschlüsselung nur im Proton-Browser-Client oder via Proton Mail Bridge (ab Mail Plus, kostenpflichtig).
DACH-Adoption-Reality-Check 2026
- S/MIME im Enterprise: dominant in Banken, Versicherungen, öffentlichem Sektor, regulierten Branchen (Healthcare, Pharma). Microsoft-zentrische Stack über Active Directory + interne CA + Group-Policy-Rollout. Empfänger-Erfahrung: signierte Mail zeigt Siegel-Icon, Klick zeigt Zertifikats-Details.
- OpenPGP im DACH-KMU + Tech: Open-Source-Projekte (Linux-Distributionen, KDE/GNOME-Maintainer), NGOs (Heinrich-Böll-Stiftung, AlgorithmWatch), Journalisten-Netzwerke (Reporters Without Borders), Quellen-Schutz (Investigativ-Recherche). Adoption bei DACH-Mittelstand < 5 %.
- Beide Verfahren parallel: typisch in heterogenen Umgebungen mit gemischten Empfänger-Gruppen (Outlook-Enterprise-Mitarbeiter + externe OpenPGP-Partner). Thunderbird oder Outlook + Gpg4win lösen das technisch.
- Mobile-Hindernis: S/MIME funktioniert in iOS Mail nativ, aber Andoid-Konfiguration ist heterogen. OpenPGP-Mobile via K-9 Mail (Android) oder Canary Mail (iOS) — aber kein Mainstream.
- Recovery-Strategie: bei Enterprise S/MIME-Rollout Key-Escrow durch Compliance-Office (Verschlüsselungs-Schlüssel separat archiviert, Signier-Schlüssel pro Nutzer). Bei OpenPGP-Privatpersonen Backup-Subkeys + Recovery-Passphrase getrennt aufbewahrt.
E2E-Verschlüsselung als Compliance-Beleg
Wolf-Agents Email Security Check fokussiert auf die DNS-basierte Authentifizierungs- und Transport-Schicht (SPF, DKIM, DMARC, MTA-STS, DNSSEC, DANE, BIMI). End-to-End-Verschlüsselung (S/MIME, OpenPGP) ist eine zusätzliche Schicht im Mail-Body, die outside-in nicht sichtbar ist — sie wird über Konfigurations-Audits dokumentiert. Wolf-Agents kann die Voraussetzungen prüfen (DKIM für Signatur-Verifikation, MTA-STS für Transport-Schutz), die E2E-Konfiguration selbst muss per Mail-Client-Audit erfasst werden.
- DKIM-Bewertung mit Schlüssellängen-Prüfung — 2048-Bit-RSA oder Ed25519 als Mindest-Empfehlung. DKIM ergänzt E2E-Verschlüsselung um Sender-Authentifizierung.
- MTA-STS-Monitoring — Mode enforce verhindert STARTTLS-Downgrade. E2E-verschlüsselte Mails sollten zusätzlich über erzwungene TLS-Verbindungen übertragen werden.
- DNSSEC + DANE TLSA — kryptografische Validierung der TLS-Zertifikate. Höchste Stufe der Transport-Sicherheit, komplementär zu E2E-Mail-Inhalt-Verschlüsselung.
- Compliance-Dokumentation (geplant) — NIS2-Audit-Vorbereitung mit Mapping auf Art. 21 Abs. 2 lit. h. E2E-Verschlüsselung als „überdurchschnittlicher Kryptografie-Einsatz“ dokumentierbar.
Compliance-Konsequenz: NIS2 lit. h + DSGVO Art. 32/9 + Berufsgeheimnisse
NIS2 Art. 21 Abs. 2 lit. h (Kryptografie)
E2E-Verschlüsselung erfüllt die NIS2-Anforderung „Konzepte und Verfahren für den Einsatz von Kryptografie und Verschlüsselung“ auf höchster Stufe. Bei Audit ist die Implementierung von S/MIME oder OpenPGP für sensible Kommunikations-Klassen ein dokumentierbar überdurchschnittlicher Schutz.
DSGVO Art. 9 (besondere Datenkategorien)
Für Gesundheitsdaten, Religion, politische Meinung verlangt DSGVO Art. 9 strengere Schutzmaßnahmen. E2E-Verschlüsselung ist hier dokumentierbar „angemessen“ — selbst wenn der Cloud-Mail-Provider kompromittiert würde, sind die Inhalte geschützt.
Berufsgeheimnisse + BSI TR-03145 (S/MIME)
§203 StGB DE, §54 öStrG AT, Art. 321 StGB CH verlangen höchste Vertraulichkeit. BSI TR-03145 liefert DACH-Referenz für S/MIME-Konfiguration. Beide Mechanismen werden bei rechtlich-strittiger Email-Korrespondenz zunehmend zur Pflicht.
Vertiefen Sie weiter
Hauptkapitel + Provider
Verwandte Deep-Dives
Bedrohungen + Verifikation
Wie steht Ihre Domain bei S/MIME vs. OpenPGP?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 165 Prüfpunkte.
Häufig gestellte Fragen
Was ist der Unterschied zwischen S/MIME und OpenPGP?
Beide Verfahren liefern End-to-End-Verschlüsselung und digitale Signaturen für E-Mails — aber mit unterschiedlichen Vertrauensmodellen. S/MIME (Secure/Multipurpose Internet Mail Extensions, RFC 8551 v4.0, April 2019) nutzt die klassische CA-PKI (Certificate Authority Public Key Infrastructure): Zertifikate werden von vertrauenswürdigen CAs ausgestellt, das Vertrauen ist hierarchisch und browser-nativ. OpenPGP (RFC 4880, November 2007, ersetzt 2024 durch RFC 9580) nutzt das Web of Trust: Nutzer signieren gegenseitig die Schlüssel anderer Nutzer, das Vertrauen ist dezentral und community-basiert. S/MIME ist in Outlook und Apple Mail nativ integriert, OpenPGP braucht Add-ons (Enigmail in Thunderbird, GpgOL in Outlook) oder nativ in Proton Mail (OpenPGPjs).
Wann ist S/MIME die richtige Wahl?
S/MIME ist die Standard-Wahl im Enterprise-Umfeld: Outlook + Active Directory + interne CA. Konfiguration über Gruppenrichtlinien skalierbar. Wenn alle Mitarbeiter dieselbe Microsoft-Tenant-CA nutzen, ist Zertifikats-Verteilung trivial. Externe Kommunikation: Zertifikat-Austausch erfolgt durch signierte Mails (S/MIME-Zertifikat ist im Header der signierten Mail enthalten). Voraussetzungen: Mail-Client mit S/MIME-Support (Outlook, Apple Mail, Mozilla Thunderbird), gültiges S/MIME-Zertifikat (Class 2 oder 3, kostenpflichtig pro Jahr/Person bei kommerziellen CAs, kostenlos bei Actalis Free).
Wann ist OpenPGP die richtige Wahl?
OpenPGP ist die Standard-Wahl bei: (1) Cross-Organisation-Kommunikation ohne gemeinsame CA-Hierarchie (Open-Source-Projekte, Journalisten, NGOs). (2) Schweizer Cloud-Mail (Proton Mail nutzt OpenPGPjs nativ). (3) Hochsensible Kommunikation, bei der CA-Vertrauen problematisch ist (z.B. wenn die CA selbst als kompromittierbar gilt). (4) Self-Hosted-Mail mit voller Kontrolle. Voraussetzungen: Mail-Client mit OpenPGP-Plugin (Thunderbird + Enigmail integriert seit v78, Outlook + GpgOL, Proton Mail nativ), GnuPG-Installation (gpg). Web of Trust kann durch zentrale Keyservers ergänzt werden (keys.openpgp.org).
Warum ist die Adoption von E2E-Mail-Verschlüsselung im DACH-Raum niedrig?
Vier strukturelle Hindernisse: (1) Schlüsselverwaltung — Nutzer müssen private Keys sicher aufbewahren und Backup managen, was technisches Verständnis voraussetzt. (2) Adressbuch-Pflege — die öffentlichen Schlüssel aller Kommunikationspartner müssen verfügbar sein (Web of Trust + Keyservers für OpenPGP, S/MIME-Header bei signierten Mails). (3) Mail-Client-Heterogenität — nicht jeder Empfänger nutzt einen E2E-fähigen Client. (4) Recovery-Risiko — bei Passwort-/Key-Verlust sind verschlüsselte Mails nicht wiederherstellbar. Cloud-Mail-Plattformen (M365, Workspace) machen S/MIME einfacher durch zentrale CA und automatische Schlüssel-Verteilung — aber nur im Enterprise-Bereich.
Welche kryptografischen Algorithmen werden bei S/MIME v4 unterstützt?
RFC 8551 v4.0 (April 2019) modernisierte die Algorithmen erheblich. Mandatorisch: AES-128 GCM und AES-256 GCM (Verschlüsselung), ECDSA P-256 mit SHA-256 oder EdDSA Curve25519 (Signaturen), ECDH P-256 und X25519 (Schlüsselaustausch). Neuerungen v4.0: AuthEnvelopedData (Vertraulichkeit + Integrität in einem Container), ChaCha20-Poly1305, SHA-512. Als veraltet markiert: TripleDES, SHA-1. RFC 8551 ersetzt die alte Version 3.2 (RFC 5751 aus 2010). Schlüssel-Mindestgrößen: RSA 3072-Bit (NIST SP 800-131A Empfehlung), EC 256-Bit minimum.
Welche Algorithmen unterstützt OpenPGP?
OpenPGP (RFC 4880, November 2007) unterstützt asymmetrische Verfahren (RSA, DSA, ElGamal), symmetrische Verschlüsselung (IDEA, CAST5, TripleDES, AES-128/192/256, Twofish, Camellia) und Hash-Verfahren (MD5, RIPEMD-160, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512). Der Nachfolger RFC 9580 (Juli 2024, „crypto refresh“) modernisiert: Ed25519 und X25519 als Standards, AES-OCB als AEAD-Mode, ChaCha20-Poly1305. Veraltete Verfahren wie MD5 und SHA-1 sind als deprecated markiert. GnuPG ist die Referenz-Implementierung (gnupg.org), OpenPGPjs (openpgpjs.org) für Browser-Anwendungen, Sequoia-PGP (sequoia-pgp.org) als moderne Rust-Implementierung.
Können S/MIME und OpenPGP interoperieren?
Nein — beide Verfahren sind nicht direkt interoperabel. S/MIME-verschlüsselte Mails können nicht von OpenPGP-Clients entschlüsselt werden und umgekehrt. Wer beide Empfänger-Gruppen bedient, muss beide Mechanismen parallel betreiben — typisch in heterogenen Enterprise-Umgebungen mit Outlook-Mitarbeitern (S/MIME) und externen Partnern (OpenPGP via Thunderbird oder Proton Mail). Manche Mail-Plattformen unterstützen beide (Outlook + GpgOL-Plugin, Thunderbird mit Enigmail + S/MIME). Proton Mail unterstützt nur OpenPGP — kein S/MIME. Mailfence (Belgien) unterstützt beide.