Eine E-Mail gleicht sicherheitstechnisch einer Postkarte: Jeder Interessierte kann den Inhalt lesen. Dabei lassen sich die elektronischen Nachrichten relativ problemlos mit frei zugänglichen Verfahren verschlüsseln.

Bildlich gesprochen macht E-Mail-Verschlüsselung aus einer für jedermann lesbaren Ansichtskarte einen versiegelten Brief mit Umschlag, wobei der Umschlag den Inhalt verbirgt und das Siegel die Authentizität des Absenders garantiert. Seltsamerweise verschlüsseln bislang nur wenige PC-Nutzer ihre E-Mails – obwohl es nirgends Fälscher, Schnüffler und Datendiebe leichter haben als im Internet.

Das Gewährleisten der Authentizität steht in der Bedeutung dem Verschlüsseln um nichts nach: Möchte ein bösartiger Zeitgenosse elektronische Post unter falschen Namen verschicken, genügt dazu schon ein manipulierter Eintrag im From-Header der Mail völlig. Daher sollte jeder E-Mail-Nutzer seine Nachrichten signieren – der Folgeschritt zur Verschlüsselung ist dann nur konsequent. Wer möchte schon, dass neugierige Zeitgenossen die private Post mitlesen? Das Signieren und Verschlüsseln gehören also untrennbar zusammen und stehen durch die im folgenden vorgestellten Verfahren in jedem Mailclient zur Verfügung.

Warum also macht kaum ein E-Mail-Nutzer von diesen Verfahren Gebrauch? Dass beispielsweise die populäre Software GnuPG kommandozeilenorientiert arbeitet, sollte gerade Linux-Nutzer nicht abschrecken. Zudem bieten populäre E-Mails-Clients und Browser grafische Schnittstellen zu GnuPG (GPG) und S/MIME. Vielleicht liegt es daran, dass sich der unbedarften Nutzer rund um das Thema E-Mail-Verschlüsselung mit einer Vielzahl an Fachbegriffen, Programmnamen und Standards konfrontiert sieht.

PGP versus S/MIME

Tatsächlich stellt das Signieren und Verschlüsseln von E-Mails mit den aktuell verfügbaren Mailclients arbeitstechnisch kein Problem dar, sofern sich der Nutzer im Dickicht der Verfahren, Programme und Bezeichnungen zu orientieren weiß. Derzeit gibt es drei Standards zum Signieren und Verschlüsseln von E-Mails: PGP, OpenPGP und S/MIME. Da die ersten beiden kompatibel sind, erscheinen sie im Folgenden bei allen prinzipiellen Erläuterungen synonym.

PGP und S/MIME jedoch verhalten sich zwar hinsichtlich Funktion und Arbeitsweise ähnlich und nutzen auch zum Teil identische Verschlüsselungsalgorithmen (IDEA und RSA). Die beiden gleichermaßen zu den hybriden Verschlüsselungsverfahren zählende Techniken sind aber weder kompatibel, noch lassen sich zwischen ihnen signierte oder verschlüsselte Nachrichten austauschen, da sich das Nachrichtenformat und die PKI-Struktur unterscheiden. Beide Verfahren stehen sowohl unter Linux (Abbildung 1) als auch unter Windows zur Verfügung, wobei S/MIME eher aus der Windows-Welt und PGP mehr aus dem Unix-Umfeld stammt.

Abbildung 1: Auch Thunderbird enthält von Haus aus Unterstützung für S/MIME, sodass Sie hierzu keine Erweiterung installieren müssen.

Während der S/MIME-Standard ab 1995 von einem Herstellerkonsortium entwickelt wurde, fußt PGP ursprünglich auf dem Engagement seines Erfinders Phil Zimmermann. Er legte von Anfang an die Quellen offen – mit der Konsequenz, dass die von PGP verwendete PKI heute weiter verbreitet und einfacher zugänglich ist. Andererseits enthalten die meisten heute erhältlichen E-Mail-Clients bereits native S/MIME-Unterstützung, während man PGP oft nachrüsten muss.

S/MIME ist als MIME-Erweiterung konzipiert und definiert dazu zwei zusätzliche Content-Typen: Multipart/Signed zum Signieren einer Mail und Multipart/Encrypted zum Verschlüsseln. Im Gegensatz zu (Open)PGP benötigt S/MIME auf dem X.509-Standard basierende Zertifikate.

Die Anhänger beider Lager streiten seit Jahrzehnten, welche Lösung die Bessere ist. Dass besser nicht zwangsläufig praktikabler bedeutet, ist einer der Gründe dafür, dass sich inzwischen die meisten Firmen und Anwender aufgrund der einfacheren Handhabbarkeit für OpenPGP entscheiden. Zwar garantieren beide Verfahren nach heutigen Stand gute Sicherheit, und auch die Verfügbarkeit der notwendigen Frontends kann nicht mehr als Argument für oder gegen PGP oder S/MIME herhalten. Die Flexibilität der PKI spricht aber für PGP.

PGP-PKI

Das A und O der Praktikabilität bei der E-Mail-Verschlüsselung stellt ein effizientes Verfahren zum Verteilen der Schlüssel dar. OpenPGP nutzt zum Verteilen der Schlüssel (bei PGP spricht man nicht von Zertifikaten) eine Public-Key-Infrastruktur. Der Begriff kennzeichnet in der Kryptologie ein System, das digitale Zertifikate ausstellen, verteilen und prüfen kann.

Im Gegensatz zu S/MIME verwendet OpenPGP jedoch keine X.509-Zertifikate. Seine PKI besteht aus einem öffentlich zugänglichen System zum Verteilen von Schlüsseln auf Basis von HTTP-Schlüsselservern. Ein wesentlicher Vorteil gegenüber S/MIME: Die (Open)PGP-Anwender-Gemeinde hat im Verbund Pgp.net sowie mit Servern der Anbieter von OpenPGP-Software (wie etwa Keyserver.de) über die Jahre eine recht gut synchronisierte PKI geschaffen. In der X.509-Welt ist das bis heute nicht der Fall.

Bei den Schlüsselservern der PGP-PKI handelt es sich um gewöhnliche Datenbanken mit einer HTTP-Schnittstelle, welche es Benutzern erlaubt, Schlüssel abzuliefern oder nach Schlüsseln zu suchen. Der Schlüssel-Server antwortet mit einer HTML-Seite, die der Nutzer entweder manuell oder – mit Hilfe der Verschlüsselungssoftware – automatisch auswertet. Ein HTTP-Keyserver lässt sich im Gegensatz zu einer X.509-PKI relativ einfach aufsetzen und verursacht nur wenig Wartungsaufwand – unter anderem, weil das System im Gegensatz X.509-Architektur nicht hierarchisch aufgebaut ist, was übrigens Konsequenzen für die Schlüsselbeglaubigung hat.

S/MIME-PKI

Bei X.509-Schlüsseln handelt es sich um lupenreine Zertifikate, die ausschließlich durch eine Zertifizierungstelle (Certificate Authority, CA) ausgestellt werden und die das System in einem X.500-konformen LDAP-Verzeichnisdienst speichert. Letzterer sieht eine streng hierarchische Struktur vor, die zwingend eine vertrauenswürdige Instanz als CA benötigt.

Prinzipiell stellt ein LDAP-Verzeichnisdienst tatsächlich die bessere Lösung zum Speichern von Zertifikaten dar, unter anderem, weil er sich einfacher replizieren lässt. HTTP-Keyserver, wie OpenPGP sie nutzt, benötigen dagegen einen eigenen Replikationsmechanismus, nebst zugehöriger Konzepte zum Gewährleisten der Verfügbarkeit oder für Backups. Allerdings ist es aus Sicherheitsgründen problematisch, LDAP-Verzeichnisdienste externen Partnern zugänglich zu machen: Ein LDAP-Dienst ist nämlich nicht Proxy-fähig und benötigt einen eigenen TCP-Port in der Firewall.

Ein weiteres Problem für die Verbreitung einer X.509-PKI besteht darin, dass nur von offiziellen Zertifizierungsstellen und Organisationen entsprechende Zertifikate ausgestellen können. Ein X.509-Zertifikat enthält als Nachweis der Gültigkeit einen öffentlichen Schlüssel, eine User-ID und eine Unterschrift. Daneben vergibt die CA für jedes X.509-Zertifikat außer der Unterschrift noch weitere Teile, wie einen Distinguished Name und eine Seriennummer. Die in der Regel kommerziellen CAs lassen sich den Aufwand für die Infrastruktur und Verwaltung beim Ausstellen eines Zertifikats in der Regel gut bezahlen.

Einige Organisationen wie CACert [1] vergeben auch kostenlose X.509-Zertifikate. Wer sich dort registriert, darf sogar mehrere Zertifikate erstellen. Allerdings beinhalten diese erst nach einer gewissen Anzahl von Identitätsnachweisen den Namen, den der Nutzer dann durch Mitglieder in einem Web of Trust verbreiten kann. Allerdings enthalten viele E-Mail-Clients und Webbrowser CACert nicht als vertrauenswürdige Zertifizierungsstelle in der Zertifikatsdatenbank. CACert wird außerdem oft nicht von einer dort eingetragenen Root-CA zertifiziert. Das äußert sich in dem Problem, dass ein Anwender, der eine Verbindung zu einem Server mit CACert-Zertifikat aufbaut, die Meldung erhält, die Herkunft des Zertifikates könne nicht überprüft werden.

Zwar gibt es heute noch eine ganze Reihe weiterer Stellen, die kostenlose Zertifikate mit reduzierter Gültigkeitsdauer vergeben. In Hinsicht auf die Einfachheit und Verbreitung der PKI ist das PGP-Netzwerk allerdings nicht zu schlagen, auch wenn S/MIME professioneller auftritt.

Verschlüsselung

Für eine verschlüsselte Datenkommunikation brauchen Sie Dreierlei: ein Nachrichtenaustauschformat, eine PKI und einen Verschlüsselungsalgorithmus. Zu den letzteren zählen beispielsweise die populären Verfahren RSA, MD5, AES, DES, DEA, IDEA oder Blowfish. Man unterscheidet dabei zwischen symmetrischen und asymmetrischen Techniken.

Die sehr schnelle symmetrische Verschlüsselung setzt voraus, das Sender und Empfänger über den gleichen geheimen Schlüssel verfügen, der sowohl zum Chiffrieren als auch zum Entziffern dient. Dies bringt den Nachteil mit, neben der verschlüsselten Information auch den (geheimen) Schlüssel übermitteln zu müssen. Einen Ausweg bietet die asymmetrische Verschlüsselung mit einer PKI: Hier chiffriert ein Sender seine Nachricht mit dem öffentlich bekannten Schlüssel (“Public Key”) des Empfängers. Wieder dechiffrieren lässt sie sich dann am Ziel ausschließlich mit dem geheimen Schlüssel (“Private Key”) des Adressaten. Ein Austausch geheimer Schlüssel entfällt, allerdings ist die asymmetrische Verschlüsselung aber äußerst rechenintensiv (siehe auch Kasten “Asymmetrische Verschlüsselung”).

Obwohl man PGP allgemein zu den asymmetrischen Verfahren zählt, kommt hier genau besehen eine hybride Technik zum Einsatz. Sie kombiniert die Vorteile symmetrischer Verschlüsselung (niedriger Rechenaufwand) mit denen der asymmetrischen Verschlüsselung (sichere Möglichkeit der Schlüsselübertragung).

Das bei PGP eingesetzte Hybridverfahren verschlüsselt die Nachricht zunächst mit einem symmetrischen Einmal-Schlüssel (Sitzungsschlüssel), den PGP nur für diese eine Verschlüsselung generiert. Den Sitzungsschlüssel wiederum verschlüsselt PGP dann mit dem Schlüssel des asymmetrischen Schlüsselpaares. Zum Entschlüsseln der Nachricht muss der Empfänger daher zunächst den symmetrischen Schlüssel mit dem Gegenpart des asymmetrischen Schlüssel dechiffrieren.

Der Performance-Gewinn gegenüber einer rein asymmetrischen Verschlüsselung ergibt sich dadurch, dass der symmetrische Schlüssel selbst im Verhältnis zur Länge der zu verschlüsselnden Daten (also der Nachricht) sehr kurz ausfällt. Die Nachricht muss nicht mehr aufwändig asymmetrisch verschlüsselt werden.

Abbildung 2: Asymmetrisches Verschlüsseln: Der Public Key lässt sich gefahrlos verbreiten – etwa einer signierten Mail anhängen.

Signieren

PGP und S/MIME zeichnen nicht nur für das eigentliche Verschlüsseln zuständig, sondern auch für die elektronische Unterschrift (Signatur). Erst durch das Signieren kann der Empfänger die Echtheit der empfangenen Nachricht einwandfrei feststellen.

Im Gegensatz zur hierarchischen Struktur der X.509-PKI mit offiziellen Zertifizierungsstellen basiert die PKI von PGP auf einem eigenen Web of Trust. Dessen Prinzip zur Gewährleistung der Echtheit fußt darauf, dass andere Schlüsselinhaber den öffentlichen Schlüssel eines Dritten signieren und so dessen Ursprung bestätigen. Bei X.509-Zertifikaten hingegen kann nur die jeweils übergeordnete Stelle Schlüssel untergeordneter Stellen signieren. Bei PGP übernimmt das gesamte Web of Trust diese Funktion: Vertraut Schlüsselinhaber A dem Teilnehmer B, kann A auch dem öffentlichen Schlüssel des (ihm unbekannten) Teilnehmers C vertrauen, sofern dessen Schlüssel bereits von B signiert wurde.

Beim Signieren erstellt die PGP-Software auf Absenderseite eine Prüfsumme der Nachricht, aus der sie mithilfe des privaten Schlüssels des Absenders die Signatur erstellt. Die Nachricht selbst wird dadurch weder verändert noch verschlüsselt. Der Empfänger kann dann mit dem öffentlichen Schlüssel des Absenders die verschlüsselte Prüfsumme wieder entschlüsseln. Dann erstellt die Signierungskomponente der Verschlüsselungssoftware auf Empfängerseite nach dem gleichen Verfahren ebenfalls eine Prüfsumme über den Inhalt der Nachricht und vergleicht diese mit der empfangenen Prüfsumme.

Sind beide identisch, gilt die Authentizität der Nachricht als erwiesen, weil außer dem Besitzer des privaten Schlüssels (also dem Absender), niemand die Prüfsumme derart verschlüsseln kann, dass diese sich vom Empfänger mit dem dazugehörigen öffentlichen Schlüssel entschlüsselt ließe. Prüfsumme und Daten sind also nicht manipuliert worden.

PGP und OpenPGP

Wer sich für das Verwenden einer PGP-basierten Verschlüsselung entscheidet, der sollte den Unterschied zwischen PGP, OpenPGP und GnuPG kennen. PGP (“Pretty Good Privacy”) meint in der Regel die ursprünglich vom MIT-Studenten Phil Zimmermann im Jahr 1991 geschriebene Freeware-Version einer Krypto-Software mit einer Schlüssellänge von 128 Bit. PGP durchlief bis heute eine wechselvolle Geschichte, in deren Verlauf die Marke PGP samt aller Rechte mehrere Male den Besitzer wechselte (siehe Kasten “Historie von PGP und OpenPGP”).

Vorrangig der undurchsichtigen Situation wegen, als sich PGP im Besitz des Herstellers McAfee befand, entstand bis zum Jahr 1998 der Standard OpenPGP, definiert in RFC2440 sowie RFC4880, einer Überarbeitung aus dem Jahr 2007. Übrigens steht das “Open” in OpenPGP ausnahmsweise nicht für Open Source, sondern dafür, dass es sich um einen offenen Standard handelt. Eine freie Software, die auf dem OpenPGP-Standard basiert, ist dagegen GNU Privacy Guard (GnuPG oder kurz GPG, [2]). Dabei handelt es sich um eine kommandozeilenorientierte Open-Source-Implementierung des OpenPGP-Standards RFC4880.

GnuPG/GPG verwendet ausschließlich patentfreie Algorithmen, unterliegt der GPLv2 und kann damit in allen Linux-Distributionen zum Einsatz kommen. Es gibt aber auch Versionen für andere unixoide Betriebssysteme sowie für Windows und Mac OS X. GnuPG 1.0.0 wurde im September 1999 freigegeben. Die aktuelle stabile Version 2.0 implementiert übrigens auch den S/MIME-Standard, das Einrichten von GnuPG bringt also auf einen Schlag beide relevanten Verschlüsselungsverfahren auf das System.

Thunderbird und Enigmail

Im Folgenden Beispiel zeigen wir, wie Sie PGP in Thunderbird verfügbar machen und verwenden. Zum Nachrüsten einer passenden Schnittstelle in Thunderbird (oder Seamonkey) dient Enigmail [3]: Es lässt sich einfach als Thunderbird-Erweiterung installieren, setzt allerdings das Vorhandensein von GnuPG voraus.

Dazu müssen Sie lediglich das passende Paket der verwendeten Distribution installieren. Unter Ubuntu ist das gnupg2, bei dessen Anwahl Synaptic beim automatischen Auflösen von Abhängigkeiten auch gleich das Paket enigmail nachzieht. Letzteres erwies sich in unserer Testkonstellation als problematisch – dazu später mehr. Ohnehin kann Thunderbird auch eigenständig nach der Erweiterung Enigmail suchen.

Enigmail enthält eine rudimentäre Schlüsselverwaltung, mit deren Hilfe Sie Schlüssel erzeugen, die Vertrauensstellung von Schlüsseln anpassen oder Schlüssel signieren. Übrigens funktioniert Enigmail unter Linux nur dann korrekt, wenn der Mailclient und das Enigmail-Plugin mit der gleichen Compiler-Version erstellt wurden (derzeit GCC 3.2). Eine ausführliche Dokumentation zu Enigmail findet sich im Mozilla-Wiki [4].

Enigmail übernimmt in Thunderbird den Part des Signierens und Verschlüsselns von Nachrichten nebst Anhängen auf Basis des OpenPGP-Standards. Die Erweiterung fügt sich nahtlos in die grafische Oberfläche von Thunderbird ein. Sämtliche kryptografischen Funktionen (Verschlüsseln, Entschlüsseln, Signieren, Verifizieren) finden sich im Hauptmenüeintrag OpenPGP.

Die Enigmail-Erweiterung führt allerdings die kryptografischen Funktionen nicht selbst aus, sondern übergibt im Hintergrund an GnuPG, das daher unbedingt installiert sein muss. Enigmail selbst stellt im Wesentlichen die grafische Schnittstelle zur Verfügung. Es gibt allerdings einige OpenPGP-Funktionen, die nicht GPG ausführt, sondern Enigmail, wie etwa die Suche nach fehlenden Schlüsseln.

OpenPGP.” width=”300″ height=”129″ /> Abbildung 3: Sämtliche kryptografischen Funktionen von Enigmail finden sich unter dem Menüeintrag OpenPGP.

Zunächst müssen Sie Enigmail mithilfe des Addon-Managers von Thunderbird aktiveren. Im Test mit Kubuntu 11.04 zeigte sich, dass die per Paketmanagement installierte Enigmail-Version 1.2 nicht kompatibel mit dem bei Ubuntu verwendeten Thunderbird 3.1.13 ist. Um diese Hürde zu umgehen, genügt es aber, die vorhandene Enigmail-Erweiterung im Plugin-Manager zu deaktivieren und anschließend Enigmail direkt aus Thunderbird über dessen Erweiterungsmanager zu installieren.

Konfiguration

Nach einen Neustart von Thunderbird stehen sämtliche Funktionen im Menü OpenPGP zur Verfügung. Aktuell ist übrigens die Enigmail-Version 1.3.2 für Thunderbird 6.0 und höher. Die meisten Linux-Distributionen installieren derzeit allerdings noch die 3er-Serie von Thunderbird, weil Thunderbird 5 und 6 noch nicht mit allen Plugins harmonieren.

Zum Erzeugen des Schlüsselpaars steht in Enigmail ein komfortabler Assistent zur Verfügung, der Sie mit ausführlichen Erläuterungen durch die weitere Konfiguration führt. Er tritt nach der Erstinstallation von Enigmail automatisch in Aktion, sobald Sie einen der Menüpunkte aus dem Menü OpenPGP aufrufen. Manuell starten Sie ihn über OpenPGP | OpenPGP-Assistent.

Der Assistent fragt beispielsweise ab, ob OpenPGP für alle vorhandenen Mail-Konten oder nur für ausgewählte zum Einsatz kommen soll und ob Sie pauschal alle Nachrichten signieren wollen oder dies im Einzelfall in Abhängigkeit vom Empfänger entscheiden möchten. Die selben Fragen stellt er im Folgeschritt auch hinsichtlich der Verschlüsselung. Hier ist es üblich und entspricht auch der Vorgabe (Abbildung 4), nicht pauschal alle Mails zu verschlüsseln, sondern Empfängerregeln festzulegen.

Abbildung 4: In der Vorgabe-Einstellung verschlüsselt Enigmail nur Nachrichten für bestimmte Empfänger.

Verschlüsseln Sie Ihre Mails bereits und möchten Thunderbird lediglich neu installieren oder Ihre GnuPG-Einstellungen auf einen anderen PC übertragen, gibt es dazu mehrere Möglichkeiten. Findet Thunderbird beim Installieren auf dem lokalen System Keyrings, importiert er diese automatisch. Außerdem können Sie jederzeit vorhandene Keyrings im Dialog OpenPGP | Schlüssel verwalten importieren, indem Sie dort auf Datei | Importieren klicken (Abbildung 5). Die Schlüssel finden sich im versteckten Verzeichnis $HOME/.gnupg, das Sie zum Übertragen auch insgesamt kopieren können. Anschließend starten Sie Thunderbird dann neu.

Abbildung 5: Die Schlüsselverwaltung ermöglicht den Import bereits bestehender Keyrings.

Die übrigen Einstellungen für OpenPGP nehmen Sie im Menü OpenPGP | Einstellungen sowie in den jeweiligen Konto-Einstellungen unter Bearbeiten | Konto-Einstellungen im Bereich OpenPGP-Sicherheit vor. Hier stellen Sie etwa für jedes Konto ein, dass Enigmail entgegen der Vorgabe aus dem Assistenten Mails per Default signiert. Außerdem lässt sich hier die OpenPGP-Unterstützung für jede Identität grundsätzlich aktivieren oder deaktivieren.

Abbildung 6: Enigmail respektive GnuPG lassen sich für jede Mail-Identität getrennt konfigurieren.

Weitere Einstellungen zu OpenPGP finden Sie ebenfalls im erwähnten Dialog OpenPGP | Einstellungen. Im zunächst einzigen Reiter Allgemein lässt sich lediglich der Pfad zu GnuPG vorgeben, falls dieser von den Vorgabe-Einstellungen abweicht. Erst nach Anwahl der Schaltfläche Experten-Optionen anzeigen macht Enigmail weitere Einstellungen zugänglich. So legen Sie beispielsweise im Reiter Schlüsselauswahl fest, dass Enigmail hierzu Empfängerregeln E-Mail-Adressen heranzieht. Im Reiter Schlüsselserver tragen Sie zusätzliche Schlüsselserver ein. Die meisten der hier möglichen Optionen erfragt allerdings auch der Assistent.

Senden und Empfangen

Beim Verfassen einer Nachricht haben Sie die Möglichkeit, im Menü OpenPGP Nachrichten wahlweise zu signieren oder zu verschlüsseln. Außerdem hängen Sie hier den eigenen öffentlichen Schlüssel an eine signierte Nachricht an. Der Thunderbird Mail-Editor kennzeichnet das Signieren und Verschlüsseln einer Nachricht durch entsprechende Symbole unten rechts. Bei Dateianhängen fragt Enigmail nach, ob es jeden Anhang einzeln signieren, verschlüsseln und via Inline-PGP senden soll oder ob es nur den Nachrichtenkörper verschlüsselt und signiert und die Anhänge darin unangetastet lässt. Das gilt auch für einen angehängten öffentlichen Schlüssel, den Sie an der Endung .asc erkennen. Beim Signieren einer Nachricht müssen Sie vor dem Senden Ihre Passphrase eingeben, um den für das Signieren erforderlichen privaten Schlüssel zu entsperren (Abbildung 7).

Abbildung 7: Beim Signieren einer E-Mail fordert Enigmail die entsprechende Passphrase an.

Wählen Sie bei einer zu verschlüsselnden Nachricht einen Empfänger, dessen öffentlichen Schlüssel Enigmail noch nicht kennt, öffnet sich automatisch den Dialog OpenPGP-Schlüssel auswählen. Hier stoßen Sie die Suche des öffentlichen Schlüssel auf einem Keyserver an, indem Sie auf Fehlende Schlüssel herunterladen klicken (Abbildung 8). Findet sich dabei kein öffentlicher Schlüssel, schicken Sie die Nachricht entweder unverschlüsselt (Nachricht nicht verschlüsseln) oder brechen den Vorgang ganz ab.

Abbildung 8: Die Public Keys Ihrer Kommunikationspartner finden Sie in aller Regel auf einem der konfigurierten Schlüsselserver.

Empfangen Sie Ihrerseits eine verschlüsselte Nachricht, geben Sie einfach das Passwort Ihres geheimen Schlüssels (Private Key) ein, um an den Klartext der Nachricht zu kommen (Abbildung 9).

Abbildung 9: Beim Entschlüsseln empfangener Nachrichten fragt Enigmail nach der Passphrase für Ihren Private Key.

Fazit

Wie Sie sehen, gehen das Ver- und Entschlüsseln sowie Signieren von E-Mails in Thunderbird dank GnuPG und Enigmail schnell und unkompliziert von der Hand. Es gibt heute also keinen triftigen Grund mehr, die elektronischen Nachrichten ungeschützt zu lassen – es sei denn, Sie zählen Bequemlichkeit als solchen.