Auf dieser Seite sind meine Empfehlungen für die Softwarekonfiguration und Schlüsselerzeugung – sofern sie nicht mit meinem Script erfolgt – sowie (Verweise auf) die Begründungen gesammelt.
Ich will nicht verschweigen, dass sich auch die Experten nicht einig sind, wie die Technik (vom "Standardanwender") optimal zu verwenden ist. Und nicht immer stehe ich mit meiner Meinung auf der Seite der Mehrheit. Anlass für die Erstellung dieser Seite war, dass ich bemerkt habe, dass die Free Software Foundation in ihrer E-Mail-Verschlüsselungsanleitung in den meisten Punkten (ohne relevante Begründung / Betrachtung) das Gegenteil dessen empfiehlt, was ich empfehle.
Das zeigt, dass es sehr wichtig ist zu verstehen, was man tut, wenn man Kryptografie-Tools benutzt, und dass die Festlegung, was am besten ist, von den Umständen des Einzelfalls abhängt. Und dass besonders gut
meist nicht dasselbe wie besonders weit verbreitet
ist; auch bei Kryptografie nicht.
Komponentenauswahl
Empfehlung: GPA mit installieren
Gpg4win fragt während der Installation ab, welche Komponenten man installieren möchte. Die lassen sich leider nicht einzeln de- oder nachinstallieren.
Gpg4win enthält zwei Programme zur Schlüsselverwaltung: GPA (Gnu Privacy Assistant; das ältere Programm) und Kleopatra. Beide Programme sind nicht gerade der direkte Weg zur Glückseligkeit; beide haben gegenüber dem anderen Vor- und Nachteile. Es bietet sich an, beide zu installieren, auszuprobieren und dann dasjenige zu verwenden, mit dem man besser zurechtkommt.
Wenn man Thunderbird und Enigmail verwendet, kann man das meiste auch mit Enigmails eigener Schlüsselverwaltung machen. Im Gegensatz zu GPA und Kleopatra kann man damit aber (bisher) nicht die GnuPG-Konfigurationsdatei bearbeiten.
Wenn man Outlook nicht (für OpenPGP) benutzen will (Glückwunsch dazu), kann man auf die Installation des Outlook-Plugins (GpgOL ) verzichten.
nicht den Assistenten benutzen
Aus unerklärlichen Gründen bietet der Dialog zur Schlüsselerzeugung weniger Optionen, wenn er über den Assistenten aufgerufen wird anstatt über die Schlüsselverwaltung. Deshalb sollte man nach der Enigmail-Installation den automatisch startenden Assistenten abbrechen, die Schlüsselverwaltung starten, von dort aus die Schlüsselerzeugung und anschließend den Assistenten manuell starten.
Schlüssellänge
Empfehlung: 2048 Bit
Es hat keinen Sinn, für die Nutzung mit normaler E-Mail Schlüssel zu erzeugen, die länger als 2048 Bit sind.
Widerrufszertifikat
Empfehlung: kein Widerrufszertifikat erzeugen
Ob es sinnvoll ist, schon bei der Schlüsselerzeugung ein Widerrufszertifikat zu erzeugen, hängt von den Umständen ab und davon, wovor man sich schützen will. Man kann es auch später noch erzeugen, aber ein nicht sicher verwahrtes Widerrufszertifikat kann man nicht mehr aus der Welt schaffen. Deshalb sollte man erst mal keins erzeugen, bis man diesen Aspekt durchdacht hat.
Gültigkeitsdauer
Empfehlung: 2 Jahre
Es gibt keinen guten Grund, Schlüssel ohne Ablaufdatum zu erzeugen. Das sorgt nur dafür, dass die Masse der Schlüssel auf den Keyservern nicht als Schlüsselleichen zu erkennen ist.
Man muss Schlüssel nicht ersetzen, wenn ihr Ablaufdatum erreicht ist, sondern kann ihn verlängern – natürlich nur, wenn man noch Zugriff auf den privaten (Haupt-)Schlüssel hat.
Die optimale Schlüssellänge ist ein Kompromiss zwischen den beiden Zielen,
wenig Gültigkeitsdauer übrig zu haben, wenn der Schlüssel unbrauchbar wird
nicht zu oft die Gültigkeitsdauer verlängern zu müssen (was auch heißt, dass die Kommunikationspartner ihre Kopie des Zertifikats nicht zu oft aktualisieren müssen, obwohl häufige Aktualisierungen wünschenswert wären)
Passphrase
Empfehlung: lieber leicht zu merken als sicher
Die Schutzwirkung der Passphrase wird leicht überschätzt. Was sie bringt, hängt sehr von dem Rechner ab, auf dem die Schlüssel verwendet werden.
Standardeinstellung Verschlüsselung
Empfehlung: nicht standardmäßig verschlüsseln
Der Nutzen, belanglose Informationen zu verschlüsseln, ist zweifelhaft. Auf der anderen Seite hat massenhafte Verschlüsselung auch Nachteile.
Standardeinstellung Schlüsselauswahl
Empfehlung: nur verifizierte / signierte ("gültige") Schlüssel verwenden
Die bequeme Verschlüsselung
zu verwenden, ist zwar bequem, aber auch heikel, weil sie den Blick dafür verstellt, was die Sicherheit asymmetrischer Kryptografie ausmacht.
Natürlich ist es bei schützenswerten Informationen besser, sie unsicher zu verschlüsseln, als sie gar nicht zu verschlüsseln, aber durch die Deaktivierung bequemer Verschlüsselung
wird man wenigstens daran erinnert, dass man die Prüfung des jeweiligen Schlüssels nachholen muss und die Sicherheit der Kommunikation begrenzt ist.
Man muss bei dieser Konfiguration allerdings (derzeit, d.h. bei Enigmail 1.7.x) darauf achten, dass in den Enigmail-Einstellungen auf der ersten Seite die Experten-Optionen und -Menüs aktiviert sind; nur dann kann man nämlich im Fenster der Mailerstellung die Option temporär den Schlüsseln aller Empfänger vertrauen auswählen, die nötig ist, um für nichtgültige Zertifikate zu verschlüsseln.
ausführliche Begründung (siehe auch die Nutzungsszenarien)
Standardeinstellung Signierung
Empfehlung: standardmäßig signieren
(Fast) Alle Mails zu signieren ist die einzige Möglichkeit, irgendwann mal den Spammern und einer großen Gruppe Computerkrimineller das Handwerk zu legen. Das einzige Argument gegen die Signierung einer Mails ist, dass man abstreiten können möchte, die Mail verfasst zu haben. Ob das eine förderungswürdige Einstellung ist, sei mal dahingestellt. Das sollte nur selten ein Thema sein, und dann kann man die Voreinstellung, die Mail zu signieren, im Einzelfall immer noch zurücknehmen.
Für abstreitbare Kommunikation (plausible deniability) ist E-Mail wohl insgesamt nicht das geeignete Medium. Es gibt eine Reihe von Chatsystemen, die dieses Feature trotz Verschlüsselung und Authentifizierung bieten, etwa Off the Record (OTR).
PGP/MIME vs. PGP/Inline
Empfehlung: PGP/MIME
PGP/MIME ist das "richtige" E-Mail-Format für OpenPGP (das dem Format entspricht, das für S/MIME verwendet wird); PGP/Inline ist nur das Kompatibilitätsformat.
Zertifikat an alle Mails hängen
Empfehlung: Downloadlink in jede Mail, aber nicht das Zertifikat
Es erscheint schon prinzipiell etwas albern, nur noch Mails mit Attachment zu verschicken. Das erleichtert auch die Suche nach einer Mail mit einem bestimmten Attachment nicht gerade.
Es ist auch normalerweise nicht nötig, um dem Empfänger bequemen Zugriff auf das Zertifikat des Absenders zu ermöglichen. Von wenigen Ausnahmen abgesehen sind alle Zertifikate auf Keyservern (oder Webservern) zu finden. Wenn man eine Mail signiert, kann das zugehörige Zertifikat über die Signatur bestimmt und mit einem Klick importiert werden. Manche Mailclients importieren die Signaturschlüssel sogar automatisch.
Insbesondere aber ist es kein Sicherheitsgewinn gegenüber der Alternative, einen Downloadlink (auf eine normale Website oder einen Keyserver) und den Fingerprint (am besten mit "Warnung") in die Textsignatur der E-Mails zu packen. Wer den Fingerprint fälschen kann, kann auch das Attachment fälschen.
Hinzu kommt, dass ein angehängtes Zertifikat jemandem, der OpenPGP nicht nutzt, nichts bringt (er typischerweise nicht einmal verstehen wird was das ist); aber mit einer geeigneten Textsignatur kann man die Nichtnutzer brauchbar auf das Thema hinweisen.
Die Unsitte, das Zertifikat an alle Mails zu hängen, kommt aus der S/MIME-Welt, die damit eins ihrer technischen Defizite kompensieren will.
Schlüsselsignaturen / Zertifizierungen
Empfehlung: nur lokale Signaturen für Anfänger
Lokale Signaturen wirken sich nicht auf das Web of Trust aus. Deshalb sollten OpenPGP-Anfänger sich darauf beschränken, lokale Signaturen für anderer Leute Schlüssel zu erzeugen, solange sie das Web of Trust (insbesondere seine Probleme) nicht umfassend verstanden haben.
Web of Trust (WoT)
Empfehlung: Anfänger sollten die Finger vom Web of Trust lassen
Das Web of Trust ist ein mächtiger, komplexer Mechanismus. Deshalb ist einiges an Sachkenntnis erforderlich, um zu verstehen, was genau dort passiert. Für Anfänger ist das Web of Trust meist nicht wichtig; deshalb ist es sinnvoll, dass sie sich davon erst mal fernhalten.
Ein Teil dieser Problematik ist, dass auch so manche erfahrene Anwender (und sogar Schlüsselverwaltungssoftware...) munter Schlüsselgültigkeit und Zertifizierungsvertrauen verwechseln.
dazulernen
Die Sicherheit, die Sie am Ende bekommen, ergibt sich so in etwa
zu 10% aus der verwendeten Technik
zu 60% daraus, dass Sie wissen, was sie tun – jederzeit!
zu 30% aus der Disziplin, das, wovon Sie wissen, dass Sie es machen sollten, auch wirklich zu machen.
Deshalb ist es wichtig, dass Sie sich nach und nach einiges an Sachkenntnis aneignen, wenn Sie die Technik irgendwann mal auf hohem Niveau nutzen (können) wollen.
Kryptografie verbreiten
Empfehlung: "Werbung" für die Technik in Ihrer Mailsignatur
Die Verbreitung von Kryptografie wird nur dann stark zunehmen, wenn die Nutzer (und sonstigen Unterstützer) dafür sorgen, dass das Thema im Alltag des normalen Bürgers sichtbar wird.
Flexibilität: jeweils das passende Tool
Empfehlung: sich mehrere Schlüssel, Kommunikationssysteme und Rechner(umgebungen) zulegen
Unterschiedliche Informationen erfordern ganz unterschiedlich viel Sicherheit und unterschiedliche Kategorien von Schutz:
Vertraulichkeit (Verschlüsselung)
Integrität / Authentizität (Signaturen)
Anonymität (keine Spezialität von OpenPGP)
Es ist deshalb offensichtlich, dass man nicht mit einem einzigen technischen Konstellation alle Fälle brauchbar handhaben kann. Erstrebenswert ist deshalb, dass sich jeder folgendes zulegt:
mehrere Schlüssel, um unterschiedliche Sicherheitsniveaus (siehe auch die Nutzungsszenarien) abzudecken
unterschiedliche Systeme (OpenPGP für ein hohes Sicherheitsniveau und Nichtabstreitbarkeit; XMPP-OTR für plausible Abstreitbarkeit trotz Authentifizierung)
unterschiedlich sichere Rechner oder unterschiedlich sichere Betriebssystem-Installationen auf demselben Rechner
Tor (siehe auch Tails) für die Anonymisierung von IP-Traffic (und speziellen Diensten); es gibt auch eine Reihe exotischer Kommunikationssysteme mit integrierter Anonymisierung (oder Tor als Anonymisierungsebene)