OpenPGP: optimales Vorgehen

This guide is deprecated, you only need to use the defaults because GnuPG is doing sane things. Just keep your software up-to-date. That is it, you are done!

If you had previously tweaked your configurations, you should consider starting over with a base configuration, so you do not have outdated recommendations that are less secure than the defaults.

Über diese Anleitung

Wir haben hier eine Menge Informationen zur Konfiguration von OpenPGP zusammengetragen. Zu jeder Konfigurationsempfehlung gibt es ausführliche Erläuterungen. Für viele dieser Empfehlungen sind Änderungen an der Konfigurationsdatei von gnupg auf Deinem Rechner erforderlich, die sich in ~/.gnupg/gpg.conf befindet. Der Einfachheit halber haben wir alle empfohlenen Änderungen an der Datei gpg.conf an einem Ort nahe dem Ende dieser Seite zusammengetragen. Wir empfehlen Dir nachdrücklich, die Datei nicht nur blind zu kopieren, sondern zuerst dieses Dokument durchzulesen, um zu verstehen, was die Einstellungen bewirken.

Diese Anleitung wurde für eine ältere Version von GnuPG (1.4) geschrieben, einige Empfehlungen können daher redundant mit aktuellen Standardeinstellungen von neueren Versionen von GnuPG (2.1 und darüber) sein. Eine Überarbeitung findet gerade statt, um die Aktualität der Anleitung zu überprüfen. Du kannst dabei helfen durch Einsenden von Änderungsvorschlägen.

Freie Software verwenden und auf dem neusten Stand halten

Informationssicherheit is zu wichtig, um sie kommerzieller Software zu überlassen. Du solltest eine freie OpenPGP-Implementierung verwenden und auf dem neuesten Stand halten. Die Standardlösung für freies OpenPGP ist GnuPG und es ist für alle gängigen, modernen Betriebssyteme verfügbar. Es reicht aber nicht GnuPG einfach zu installieren und dann nie wieder darüber nachzudenken. Du musst die Software auch aktuell halten, damit kritische Sicherheitslücken behoben werden können. Jede Software hat Fehler und GnuPG ist keine Ausnahme. Je nach Betriebssystem gibt es dies zu beachten:

• GNU/Linux (Debian, Ubuntu, Mint, Fedora, usw.): Dein Betriebssystem installiert GnuPG automatisch und hält es auch auf dem neuesten Stand.
• Windows: Du kannst Gpg4win installieren und die gpg4win-announce Mailingliste (englisch) abonnieren, um herauszufinden wann es Zeit ist ein Update zu installieren.
• Mac OS: Du kannst die GPG Suite von GPGTools installieren.
• Wenn Du den Quellcode selbst übersetzt (z.B. für andere Betriebssysteme), solltest du die gnupg-announce Mailingliste abonnieren, um herauszufinden wann es Zeit ist ein Update zu installieren.

Einen Schlüsselserver auswählen und den eigenen Rechner so konfigurieren, dass der Schlüsselbund aktualisiert wird.

Wenn Du Deine öffentlichen Schlüssel nicht regelmäßig aktualisierst, wirst Du nicht rechtzeitig über abgelaufene oder zurückgezogene Schlüssel informiert, die Dir unbedingt bekannt sein sollten! Beim Aktualisieren von Schlüsseln sind zwei Aspekte zu berücksichtigen: Schlüsselupdates werden oft auf Schlüsselservern gespeichert. Also musst Du zunächst sicherstellen, dass Du einen Schlüsselserver verwendest, der richtig funktioniert. Dann musst Du Deinen Rechner so konfigurieren, dass er regelmäßig Schlüsselupdates bekommt.

Benutze den sks-Schlüsselserververbund statt eines einzelnen Servers und sichere Verbindungen

Die meisten OpenPGP-Clients werden mit einem einzelnen, spezifischen Schlüsselserver vorkonfiguriert. Das ist alles andere als ideal, denn falls der Server ausfällt oder – schlimmer noch – zu funktionieren scheint aber fehlerhaft ist, könnte es geschehen, dass Dir kritische Schlüsselupdates nicht zugestellt werden.

Deshalb empfehlen wir die Nutzung des sks-Schlüsselserververbundes. Die Rechner in diesem Verbund werden regelmäßigen Sicherheitschecks unterzogen um sicherzustellen, dass sie fehlerfrei funktionieren. Funktioniert ein Server nicht gut, wird er automatisch aus dem Verbund entfernt.

Du solltest auch sicherstellen, dass Du mit dem Schlüsselserververbund verschlüsselt kommunizierst, mit einem Protokoll namens hkps. Um hkps nutzen zu können, musst Du zunächst gnupg-curl installieren:

sudo apt-get install gnupg-curl

Um nun den Schlüsselserververbund nutzen zu können, musst Du das Sicherheitszertifikat von sks-keyservers.net herunterladen und an einem geeigneten Ort auf Deinem Rechner speichern. Bitte merke Dir, unter welchem Pfad Du die Datei ablegst! Nun solltest Du den Fingerabdruck des Zertifikats verifizieren.

Wenn das geschehen ist, solltest Du die folgenden Parameter in ~/.gnupg/gpg.conf eintragen und dabei den vollständigen Pfad angeben, unter dem Du die .pem-Datei oben abgelegt hast:

keyserver hkps://hkps.pool.sks-keyservers.net
keyserver-options ca-cert-file=/pfad/zur/Datei/sks-keyservers.netCA.pem

Von jetzt an werden Deine Interaktionen mit dem Schlüsselserver über hkps verschlüsselt, so dass Deine Sozialprofil jedem verborgen bleibt, der vielleicht Deinen Datenverkehr abhört. Wenn Du beispielsweise gpg --refresh-keys eingibst und einen Schlüsselserver benutzt, der nur hkp unterstützt, dann wird jemand, der Deine Daten abfängt, jeden einzelnen Schlüssel in Deinem Schlüsselbund zu sehen bekommen, während Du die Schlüsselupdates anforderst. Das sind ziemlich interessante Informationen.

Anmerkung: hkps://keys.indymedia.org, hkps://keys.mayfirst.org und hkps://keys.riseup.net bieten auch alle hkps (allerdings ist es ratsam, stattdessen einen Schlüsselserververbund zu verwenden).

Dies ist das Standardverhalten seit GnuPG 2.1.18.

Sicherstellen, dass alle Schlüssel über den Schlüsselserver aktualisiert werden, den Du angegeben hast

Bei der Schlüsselerzeugung können die Besitzer*innen einen bestimmten Schlüsselserver angeben, von dem ihr Schlüssel zu beziehen ist. Es ist ratsam, die folgende Option in ~/.gnupg/gpg.conf einzutragen, um solche Zuordnungen zu ignorieren:

keyserver-options no-honor-keyserver-url

Das ist sinnvoll, weil es 1.) verhindert, dass jemand eine unsichere Methode angibt, um ihren Schlüssel herunterzuladen und 2.) weil die Aktualisierung von einem Server, der hkps verwendet, scheitern wird, da das Sicherheitszertifikat nicht mit dem des Servers übereinstimmt, so dass die Schlüssel niemals aktualisiert werden.

Verwende parcimonie um Deine Schlüssel zu aktualisieren.

Nun, da Du einen guten Schlüsselserver konfiguriert hast, solltest Du sicherstellen, dass Deine Schlüssel regelmäßig aktualisiert werden. Der beste Weg, dies unter Debian und Ubuntu zu erreichen, ist die Verwendung von parcimonie:

sudo apt-get install parcimonie

Parcimonie ist ein Daemon, der Deinen Schlüsselbund nach und nach über TOR aktualisiert. Dazu verwendet es eine zufällige Wartezeit und neue TOR-Verbindungen (Circuit) für jeden Schlüssel. Dadurch wird es Angreifer*innen erschwert, die Schlüssel-Updates mit Deinem Schlüsselbund in Verbindung zu bringen.

Du solltest nicht gpg --refresh-keys oder den Aktualisierungsbefehl Deines Mailclients verwenden, da Du sonst jedem, der Deine Verbindung belauscht und der Serverbetreiber*in den kompletten Schlüsselsatz offenbarst, den Du aktualisieren möchtest.

Schlüsseln von Schlüsselservern nicht blind vertrauen

Jede*r kann Schlüssel auf einen Schlüsselserver hochladen und es gibt keinen Grund anzunehmen, dass der Schlüssel, den Du herunterlädst, tatsächlich der Person gehört, die im Schlüssel angegeben wird. Deshalb solltest Du den vollständigen Fingerabdruck des Schlüssels mit der Eigentümer*in des Schlüssels verifizieren und zwar bei einem persönlichen Treffen oder am Telefon.

Sobald Du den gesuchten Fingerabdruck mit der Eigentümer*in verifiziert hast, kannst Du den Schlüssel über den Fingerabdruck vom Schlüsselserververbund herunterladen:

gpg --recv-key '<fingerprint>'

Beachte die einfachen Anführungsstriche oben (’), welche vor und hinter dem vollständigen Fingerabdruck stehen sollten und notwendig sind, damit dieser Befehl funktioniert. Doppelte Anführungszeichen oben (") gehen auch.

Der nächste Schritt ist, sicherzustellen, dass du tatsächlich den richtigen Schlüssel bekommen hast. Der Schlüsselserver könnte dir einen anderen geschickt haben, als den den du wolltest. Wenn Du gpg mit einer Version kleiner als 2.1 benutzt, musst du den Fingerabdruck manuell nach dem Herunterladen überprüfen (Version 2.1 und neuer lehnen Schlüssel vom Schlüsselserver mit falschem Fingerabdruck ab).

Es gibt zwei Möglichkeiten, den Fingerabdruck zu überprüfen:

Option 1. Überprüfe, dass der Fingerabdruck jetzt in deinem Schlüsselbund vorhanden ist:

gpg --fingerprint '<fingerprint>'

Option 2. Versuche (lokal) einen Schlüssel mit diesem Fingerabdruck zu signieren:

gpg --lsign-key '<fingerprint>'

Wenn du sicher bist, dass du den richtigen Fingerabdruck von der Person hast, welcher der Schlüssel gehört, ist die bevorzugte Methode, den Schlüssel lokal zu signieren.
Wenn du öffentlich deine Beziehung zu dieser Person bewerben willst, kannst du auch das öffentlich exportierbare --sign-key verwenden.

Verlasse Dich nicht auf die Schlüssel-ID (keyid).

Kurze OpenPGP Schlüssel-IDs, beispielsweise 0×2861A790, sind 32 bit lang. Es ist bekannt, dass es leicht ist einen neuen, gefälschten Schlüssel mit der selben Schlüssel-ID zu erstellen. Lange OpenPGP Schlüssel-IDs (wie z.B. 0xA1E6148633874A3D) sind 64 bit lang. ID-Kollisionen herbeizuführen ist trivial, was ebenfalls ein potentiell ernsthaftes Problem darstellt.

Wenn Du wirklich eine kryptographisch starke Identifikation für einen Schlüssel haben willst, solltest Du den vollen Fingerabdruck verwenden. Du solltest Dich nie auf die Schlüssel-ID verlassen, weder die kurze, noch die lange.

Du solltest wahrscheinlich mindestens die GnuPG-Optionen keyid-format 0xlong und with-fingerprint verwenden (trage sie in ~/.gnupg/gpg.conf ein) um die Anzeigenlänge der Schlüssel-ID auf 64 bit zu verlängern und immer den Fingerabdruck anzuzeigen.

Anmerkung: Es gab einen Bug in Enigmail, der seit Version 1.7.0 behoben ist: Wenn Du die Option ‘with-fingerprint’ einsetzt, um bei der Anzeige der Schlüssel immer den vollständigen Fingerabdruck mit auszugeben, wird im Schlüsselverwaltungsfenster von Enigmail der Fingerabdruck eines Unterschlüssels (subkey) angezeigt und nicht der des primären Schlüssels. Du kannst immer den Fingerabdruck Deines primären Schlüssels finden (z.B. wenn Du jemandem auf einer Keysigning-Party Deinen Fingerabdruck zur Verifikation geben möchtest), indem Du die Fingerabdrücke all Deiner geheimen Schlüssel mit dem folgenden Kommando anzeigen lässt:

gpg --with-fingerprint --list-secret-key

Schlüsselkonfiguration.

Nun da Du weisst, wie Du reguläre Schlüsselaktualisierungen von einem gut gewarteten Schlüsselserver abrufen kannst, solltest Du Dich vergewissern, dass Dein OpenPGP-Schlüssel optimal konfiguriert ist. Viele dieser Änderungen werden das Generieren eines neuen Schlüssels erforderlich machen.

Verwende einen starken primären Schlüssel

Manche Leute benutzen noch 1024-bit DSA-Schlüssel. Du solltest wirklich zu einer höheren Bitstärke und einem besseren Hashing-Algorithmus wechseln. 2011 hat die US-Regierungsinstitution NIST DSA-1024 für hinfällig erklärt, seit 2013 ist er sogar verboten.

Wir empfehlen, einen 3072-bit langen RSA-Schlüssel mit sha512 als Hash-Algorithmus zu erstellen und eine Erklärung zum Wechsel der Schlüssel (transition statement) zu veröffentlichen, die mit beiden Schlüsseln signiert ist. Dieses Dokument erklärt die notwendigen Schritte zum Erstellen eines solchen Schlüssels genau und gut, so dass sichergestellt ist, dass Du den richtigen Hash-Algorithmus verwendest (wenn Du eine GnuPG-Version vor 1.4.10 verwendest, kann der Vorgang etwas kompliziert sein).

Das Wechseln des Schlüssels kann schmerzhaft sein, aber es lohnt sich – und ist außerdem eine gute Gelegenheit, den Umgang mit den Werkzeugen zu üben!

Verwende ein Ablaufdatum von unter zwei Jahren

Die meisten Leute denken, dass sie ihre Schlüssel nicht ablaufen lassen wollen, tatsächlich solltest Du aber genau das wollen. Weshalb? Weil Du das Ablaufdatum immer verlängern kannst, sogar nachdem der Schlüssel bereits abgelaufen ist! Das “Ablaufdatum” ist nämlich in Wahrheit eher eine Art Sicherheitsventil oder “Totmannschalter”, der zum angegebenen Zeitpunkt automatisch ausgelöst wird. Wenn Du Zugang zum geheimen Schlüssel hast, kannst Du den Schalter zurückstellen. Der Sinn der Übung besteht darin, eine Einstellung vorzunehmen, die den Schlüssel deaktiviert, falls er für Dich nicht mehr zugänglich ist (und Du kein Widerrufszertifikat besitzt).

Wenn Du ein Ablaufdatum vergibst, wirst Du den Ablaufzeitraum in der Zukunft erweitern müssen. Das ist eine kleine Aufgabe, an die Du denken musst (siehe den nächsten Punkt zum Erstellen eines Erinnerungstermins).

Du denkst vielleicht, dass das lästig ist und Du Dich damit nicht auseinandersetzen willst, aber es ist wirklich sinnvoll dies regelmäßig zu tun, um Deine OpenPGP-Fertigkeiten aufzufrischen. Es zeigt anderen Benutzer*innen, dass der Schlüssel weiterhin aktiv ist und benutzt wird, und gibt Dir die Gelegenheit, den aktuellen Zustand Deiner Verschlüsselungswerkzeuge und dieses Dokuments zu überprüfen. Außerdem sind viele Leute nicht bereit, einen Schlüssel zu signieren, der kein Ablaufdatum hat!

Wenn Du bereits einen Schlüssel ohne Ablaufdatum erzeugt hast, kannst Du nachträglich ein Ablaufdatum für Deinen Schlüssel erstellen, indem Du folgendes eingibst:

gpg --edit-key '<fingerabdruck>'

Wähle nun den Unterschlüssel (subkey) aus, für den Du ein Ablaufdatum vergeben möchtest (z.B. den ersten) oder keinen falls Du das Ablaufdatum für Deinen primären Schlüssel vergeben möchtest und gib dann den Befehl ‘expire’ ein:

gpg> key 1
gpg> expire

Stelle nun ein vernünftiges Datum ein (z.B. 2 Jahre), speichere den Schlüssel ab und verlasse das Interface:

Key is valid for? (0) 2y
gpg> save

Danach kannst Du Deinen Schlüssel an den Schlüsselserver versenden, um die Änderung zu veröffentlichen:

gpg --send-key '<fingerabdruck>'

Erstelle einen Erinnerungstermin, der Dich an das Ablaufdatum erinnert

Du wirst nicht daran denken, also ist es am besten, wenn Du Dich von etwas daran erinnern lässt. Lege den Erinnerungstermin einen Monat oder mehr vor dem Ablaufdatum, damit Du die Änderungen in Ruhe vornehmen kannst. Du solltest nicht unter Stress stehen, wenn es um Deine Schlüssel geht.

Denk daran: Du kannst das Ablaufdatum jederzeit verlängern (sogar wenn es bereits abgelaufen ist!), so dass Du keinen brandneuen Schlüssel erstellen musst; Du musst lediglich das Ablaufdatum auf einen späteren Zeitpunkt versetzen. Es trainiert Deine OpenPGP-Muskeln wenn Du dies regelmäßig tust – sonst wirst Du anfangen, zu vergessen, wie die Dinge funktionieren.

Erstelle ein Widerrufszertifikat

Wenn Du Dein Passwort vergisst oder wenn Dein privater Schlüssel kompromittiert wird oder Du ihn verlierst, kannst Du entweder darauf warten, dass Dein Schlüssel abläuft (das ist keine gute Lösung) oder Dein Widerrufszertifikat aktivieren, indem Du es auf den Schlüsselservern veröffentlichst. Wenn Du dies tust, werden andere darüber informiert, dass Du den Schlüssel widerrufen hast und er nicht mehr gültig ist.

Ein widerrufener Schlüssel kann immer noch verwendet werden um alte Unterschriften zu verifizieren oder Daten zu entschlüsseln (wenn Du noch Zugang zum geheimen Schlüssel hast), aber er kann nicht mehr benutzt werden, um Nachrichten an Dich zu verschlüsseln.

gpg --output widerruf.asc --gen-revoke '<fingerabdruck>'

Damit erstellst Du eine Datei namens widerruf.asc. Du könntest einen Ausdruck von diesem Zertifikat vornehmen und an einem sicheren Ort ablegen (gib ihn Deiner Mutter oder bewahre ihn bei Deinen Backups an einem anderen Ort auf). Wenn jemand Zugang dazu erhält, kann sie Deinen Schlüssel widerrufen, was sehr lästig ist; wenn sie allerdings auch Zugang zu Deinem privaten Schlüssel haben, solltest Du genau das wollen – Deinen Schlüssel widerrufen.

Das ist Standard seit GnuPG 2.1.

Nutze den primären Schlüssel nur zur Zertifizierung (und evtl. zum Signieren). Nutze einen separaten Unterschlüssel zum Verschlüsseln.

Zum Verschlüsseln solltest Du Dir einen separaten Unterschlüssel (subkey) erstellen.

Das ist der Standard ab GnuPG 1.4.18 (und eventuell früher). Wenn Dein Schlüssel mit einer älteren Version von OpenPGP erstellt wurde, solltest du neue Unterschlüssel erstellen, wie zum Signieren (weiter unten).

Benutze einen separaten Unterschlüssel zum Signieren

Standardmäßig benutzt GnuPG den gleichen Unterschlüssel zum Signieren (z.B. Signieren von E-Mailnachrichten) und Zertifizieren (signieren einen anderen Schlüssels). Es macht Sinn, diese beiden Ziele zu trennen, weil das eine wichtiger als das andere ist.

In diesem Szenario wird Dein primärer Schlüssel nur für Zertifizierungen benutzt, die selten stattfinden.

Erstelle einen Unterschlüssel im Menü --edit-key, mit dem Befehl addkey. In diesem Dialog kann die “Fähigkeit” des Schlüssels ausgewählt werden…

Benutze den primären Schlüssel ausschließlich offline

Das ist schwierig, ermöglicht aber, den äußerst wichtigen primären Schlüssel zu schützen. Wenn er gestohlen wird, kann ein Angreifer neue Identitäten erstellen, bestehende widerrufen und sich vollständig als Du selbst ausgeben. Schlüssel “offline” zu speichern ist eine sichere Möglichkeit, sich gegen solche Angriffe zu schützen.

Erstelle vorher einen eignen Schlüssel zum Signieren, sonst ist es nicht möglich, E-Mails ohne den Offline-Schlüssel zu signieren.

Den primären Schlüssel zu extrahieren ist schwierig, aber damit sollte es klappen:

# primären Schlüssel extrahieren
gpg -a --export-secret-key john.doe@example.com > secret_key
# Unterschlüssel extrahieren, die später re-importiert werden
gpg -a --export-secret-subkeys john.doe@example.com > secret_subkeys.gpg
# *lösche* die geheimen Schlüssel aus deinem Schlüsselbund, sodass nur Unterschlüssel übrig bleiben
$ gpg --delete-secret-keys john.doe@example.com
Delete this key from the keyring? (y/N) y
This is a secret key! - really delete? (y/N) y
# Unterschlüssel reimportieren
$ gpg --import secret_subkeys.gpg
# Überprüfe, dass alles in Ordnung ist
$ gpg --list-secret-keys
# Entferne die Unterschlüssel von der Festplatte
$ rm secret_subkeys.gpg

Danach sollte der geheime Schlüssel offline gelagert werden, z.B. auf einem Stick, den Du immer bei dir trägst, oder in einem geschützten Safe. Andere benutzen Smartcards, um ihn zu speichern und an einem physischen Schlüsselbund bei sich zu tragen.

Stelle sicher, dass Widerrufszertifikate erstellt wurden.

Überprüfe, dass der geheime Schlüssel fehlt mit --list-secret-keys – es sollte sec# anstatt sec anzeigen.

In manchen ungewöhnlichen Situationen kommt es vor, dass --delete-secret-keys das geheime Schlüsselmaterial nicht vollständig entfernt und --list-secret-keys immer noch sec anstatt von sec# anzeigt. In diesem Fall sollte das Verzeichnis .gnupg entfernt werden, anstatt --delete-secret-keys zu benutzen. Dann ist es nötig, trustdb und öffentliche Schlüssel wieder zu importieren, etwa so:

anstatt von gpg --delete-secret-keys john.doe@example.com, gehe so vor:
$ mv .gnupg .gnupg.bak
# Unterschlüssel reimportieren
$ gpg --import secret_subkeys.gpg
# Überprüfe, dass alles in Ordnung ist
$ gpg --list-secret-keys
# Entferne die Unterschlüssel
$ rm secret_subkeys.gpg
# Öffentlichen Schlüsselbund reimportieren
$ gpg --homedir .gnupg.bak --export | gpg --import
# trustdb reimportieren
$ gpg --homedir .gnupg.bak --export-ownertrust | gpg --import-ownertrust
# entferne das Backupverzeichnis von GPG (*alle* geheimen Schlüssel werden gelöscht
$ rm -rf .gnupg.bak

Bei diesen Vorgängen ist der Schlüssel im Klartext auf der Festplatte gespeichert. Es ist empfehlenswert, die Dateien sicher zu löschen (z.B. mit nwipe) anstelle mit rm. Moderne Speichermedien wie SSDs benutzen fortgeschrittene Firmware, die solche Befehle nicht tatsächlich ausführen und Spuren von privaten Schlüsseln übrig lassen können. Der beste Schutz davor ist Komplettverschlüsselung.

Beachte, dass sich dieses Verfahren von Version zu Version ändern kann. Lies diese Diskussion oder diesen Artikel, oder diese Anleitung für GnuPG 2.x und neuer.

OpenPGP Schlüssel überprüfen

Es gibt ein nützliches Tool, welches die folgenden Überprüfungen für Dich vornimmt. Du kannst es aus den Quellen kompilieren oder das Paket direkt installieren, wenn Du Debian oder Ubuntu verwendest, indem Du folgendes eingibst:

sudo apt-get install hopenpgp-tools

Beachte: hopenpgp-tools funktioniert aktuell nicht mit GnuPG 2.1 und darüber, weil öffentliche und private Schlüssel nun in ~/.gnupg/pubring.kbx gespeichert werden. hkt erwartet diese aber in ~/.gnupg/pubring.gpg und gibt seit GnuPG 2.1 eine Fehlermeldung aus.

Die Befehlszeile, um diese Tests ausführen, lautet:

hkt export-pubkeys '<fingerabdruck>' | hokey lint

In der Ausgabe werden eventuelle Probleme im Zusammenhang mit Deinem Schlüssel in rotem Text angezeigt. Wenn die komplette Ausgabe grün ist, hat Dein Schlüssel die nachfolgenden Tests alle bestanden. Wenn etwas rot ist, hat Dein Schlüssel einen der Tests nicht bestanden und Du solltest ihn reparieren oder einen neuen generieren, nachdem Du Dich vergewissert hast, dass Deine gpg.conf wie empfohlen eingerichtet ist.

Vergewissere Dich, dass Dein Schlüssel OpenPGPv4 ist

In RFC4880 heißt es: “V3 Schlüssel sind veraltet. Sie enthalten drei Schwächen. Erstens ist es relativ einfach einen V3 Schlüssel zu erzeugen, der die selbe Schlüssel-ID wie ein beliebiger anderer Schlüssel hat, weil die Schlüssel-ID lediglich aus den letzten 64 bit des öffentlichen Moduls besteht. Zweitens, weil der Fingerabdruck eines V3 Schlüssels zwar das Schlüsselmaterial in die Prüfsumme einbezieht, nicht aber dessen Länge, gibt es eine erhöhte die Wahrscheinlichkeit von Fingerabdruckkollisionen. Drittens gibt es Schwächen im MD5 Hashalgorithmus, die dazu geführt haben, dass Entwickler andere Algorithmen bevorzugen. Siehe unten für eine ausführlichere Diskussion von Schlüssel-IDs und Fingerabdrücken.”

Um festzustellen, ob Dein Schlüssel ein V3-Schlüssel ist, kannst Du folgendes eingeben:

gpg --export-options export-minimal --export '<fingerabdruck>' | gpg --list-packets | grep version

Primäre Schlüssel sollten mit RSA, ideal 3072 Bit, erstellt werden.

Um zu überprüfen, ob Du RSA benutzt, verwende folgenden Befehl:

gpg --export-options export-minimal --export '<fingerabdruck>' | gpg --list-packets | grep -A2 '^:public key packet:$' | grep algo

Wenn als Algorithmus 1 ausgegeben wird, verwendest Du RSA. Wird 17 ausgegeben, dann handelt es sich um DSA und Du wirst überprüfen müssen, ob die Schlüsselgröße, die im nächsten Test ermittelt wird, eine größere Bitlänge als 1024 ausgibt – andernfalls verwendest Du nicht DSA-2.

Wenn der ausgegebene Algorithmus 19 ist, verwendest Du ECDSA, bei 18 handelt es sich um ECC. Die Schlüsselbitlängen-Überprüfung unten ist kein angemessenens Kriterium für diese Schlüsseltypen, da die Schlüsselgrößen beträchtlich kleiner sind.

Die Bitlänge des primären Schlüssels kannst Du folgendermaßen ermitteln:

gpg --export-options export-minimal --export '<fingerabdruck>' | gpg --list-packets | grep -A2 'public key' | grep 'pkey\[0\]:'

Eigensignaturen sollten nicht nur MD5 verwenden

Das kannst Du folgendermaßen überprüfen:

gpg --export-options export-minimal --export '<fingerabdruck>' | gpg --list-packets | grep -A 2 signature | grep 'digest algo'

Wenn die Ausgabe ‘digest algo 1’ enthält, dann enthält Dein Schlüssel Eigensignaturen, die MD5 verwenden, denn MD5 ist Hashalgorithmus 1. Siehe das OpenPGP RFC 4880, Abschnitt 9.4 für eine Übersichtstabelle der Hashalgorithmen und Nummern.

Um dieses Problem zu beheben, solltest Du zuerst folgende Änderung an Deiner ~/.gnupg/gpg.conf vornehmen:

cert-digest-algo SHA512

Dann solltest Du eine neue Eigensignatur auf Deinem Schlüssel erstellen (z.B. indem Du das Ablaufdatum des Schlüssels änderst).

Eigensignaturen sollten nicht nur SHA1 verwenden

Überprüfe dies mit dieser Befehlszeile:

gpg --export-options export-minimal --export '<fingerabdruck>' | gpg --list-packets | grep -A 2 signature | grep 'digest algo'

Wenn die Ausgabe ‘digest algo 2’ enthält, dann enthält Dein Schlüssel Eigensignaturen, die SHA1 verwenden, denn SHA1 ist Hashalgorithmus 2. Siehe das OpenPGP RFC 4880, Abschnitt 9.4 für eine Übersichtstabelle, der Hashalgorithmen und Nummern.

Um dieses Problem zu beheben, solltest Du zuerst folgende Änderung an Deiner ~/.gnupg/gpg.conf vornehmen:

cert-digest-algo SHA512

Dann solltest Du eine neue Eigensignatur auf Deinem Schlüssel erstellen (z.B. indem Du das Ablaufdatum des Schlüssels änderst).

Angaben zu bevorzugten Digest-Algorithmen müssen mindestens ein Mitglied der SHA-2 Familie mit einer höheren Priorität als MD5 und SHA1 enthalten

Dies kannst Du überprüfen indem Du das Folgende in Deine Befehlszeile eingibst:

gpg --export-options export-minimal --export '<fingerabdruck>' | gpg --list-packets | grep 'pref-hash-algos'

und Dir die Ergebnisse ansiehst. Die Reihenfolge der bevorzugten Algorithmen wird als Liste von Zahlen ausgegeben. Vorrang hat was weiter links steht. Wenn eine der Zahlen ‘3’, ‘2’, oder ‘1’ in der Liste vor der ersten ‘11’, ‘10’, ‘9’ oder ‘8’ kommt, dann wird in Deinen Präferenzen ein schächerer Algorithmus bevorzugt.

Um dies zu beheben, nimmst Du zuerst die folgende Änderung in Deiner ~/.gnupg/gpg.conf vor:

default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed

und setzt dann die neuen Präferenzen in Deinem Schlüssel:

$ gpg --edit-key '<fingerabdruck>'
gpg> setpref
...
gpg> save

Primärschlüssel sollten ein vernünftiges Ablaufdatum haben (nicht mehr als 2 Jahre in der Zukunft)

Du kannst Dein Ablaufdatum mit dieser Befehlszeile überprüfen:

gpg --export-options export-minimal --export '<fingerabdruck>' | gpg --list-packets | grep 'key expires after'

Schau Dir das Ergebnis an um zu überprüfen wann der Schlüssel abläuft — beachte aber, dass die angegebene Zeit von der Schlüsselerzeugung ab gerechnet wird, was bei der Interpretation des Ablaufdatums für Verwirrung sorgen kann,

Eine weitere Möglichkeit, das Ablaufdatum zu überprüfen ist dies:

gpg --list-keys '<fingerabdruck>'

dabei sollten Erzeugungs- und Ablaufdatum des primären Schlüssels und aller assoziierten Unterschlüssel (subkeys) angezeigt werden. Wenn Du nirgends das Wort “expires” oder “verfällt” siehst, dann hast Du kein Ablaufdatum eingestellt.

Das kannst Du folgendermaßen beheben:

$ gpg --edit-key '<fingerabdruck>'
gpg> expire
...
gpg> save

Zusammenfassung aller Empfehlungen.

Alle empfohlenen Einstellungen, die in dieser Anleitung diskutiert wurden, sind in einer Konfigurationsdatei in Jacob Appelbaum’s duraconf “Sammlung gehärteter Konfigurationsdateien” kombiniert. Du kannst die Datei gpg.conf herunterladen und unter ~/.gnupg/gpg.conf speichern. Windows-Benutzer sollten die Datei gpg.conf im Verzeichnis Anwendungsdaten\GnuPG\ oder AppData\GnuPG\ speichern.

Du solltest die folgenden Einstellungen einkommentieren und/oder an deine lokalen Präferenzen anpassen: default-key, keyserver-options ca-cert-file und keyserver-options http-proxy.

Zusätzliche Vorschläge.

Hast Du ein verschlüsseltes Backup Deines geheimen Schlüsselmaterials?

Vergewissere Dich, dass es wirklich so ist.

Verwende keinen “Kommentar” in Deiner Benutzer-ID

Wenn Du der Ansicht bist, dass Du einen “Kommentar” in Deiner OpenPGP Benutzer-ID benötigst, denke bitte lange und tief darüber nach, ob das wirklich nötig ist. Wahrscheinlich brauchst und willst Du das gar nicht und ein Kommentar erschwert es anderen Leuten, festzustellen, was sie eigentlich zertifizieren.