Der GNU Privacy Guard
Exportieren
Wahrscheinlich will man seinen öffentlichen Schlüssel mal in eine Datei ausgeben (z.B. um ihn auf seine Homepage zu legen). Exportieren macht --export
, das ohne Parameter allerdings alle öffentlichen Schlüssel ausgibt (analog zu --list-keys
). Zu Anfang ist das zwar nur der eigene, trotzdem sollte man eindeutige Teile der Benutzer-ID (z.B. Name oder E-Mailadresse) oder die Schlüssel-ID (8-stellig, 16-stellig oder 40-stellig (der gesamte Fingerprint), mit und ohne vorangestelltem 0x möglich) an --export
anfügen. --export 0xFCC5040F
und --export s-beyer@gmx.net
führen immer zu dem, was ich will. In dieser Form ist es also weitestgehend eindeutig. --export Stephan
exportiert irgendwann auch die anderen Stephans, deren öffentliche Schlüssel ich mal haben werde.
Mit --output Dateiname
bzw. -o Dateiname
wird die Ausgabe in einer Datei gespeichert. (Ich hab anfangs immer eine UNIX-typische Umleitung mittels > Dateiname
gemacht und auch keine Probleme damit gehabt. Dennoch empfehle ich, lieber -o Dateiname
zu verwenden.) Beispiel:
gpg -o ~/.gnupg/sbeyer.asc --export 0xFCC5040F
Werfe ich einen Blick in die neu erstellte sbeyer.asc, so stelle ich fest, dass es sich um ziemlich hässliche 8-Bit-Ausgaben handelt, und das ist übers Netz manchmal ungeeignet zu verschicken, gerade per E-Mail. Dafür bietet gpg die Option -a
bzw. --armor
an, die man unbedingt bei allen Ausgaben nutzen sollte, um 8-Bit-Ausgaben zu unterdrücken und schöne Base64-Ausgaben zu machen (nur dann rechtfertigt sich übrigens der .asc-Dateisuffix). Es lohnt sich, armor
in die Datei ~/.gnupg/gpg.conf zu schreiben, wodurch gpg sich immer so verhält, als hätte man -a
angegeben.
Auf einigen Systemen ist statt einer ~/.gnupg/gpg.conf eine ~/.gnupg/options installiert, welches die Konfigurationsdatei älterer GnuPG-Versionen war. Ich empfehle in diesem Falle, die Datei umzubenennen. Wenn gpg.conf existiert, wird options ignoriert.
Widerrufen
Man sollte sich auch gleich am Anfang ein Widerrufszertifikat in eine Datei speichern, um später alte Schlüssel widerrufen zu können, z.B. wenn man die Passphrase vergessen hat, seinen geheimen Schlüssel gelöscht hat oder man merkt, dass er kompromittiert (geknackt) wurde. In meinem Falle lautet der Befehl:
gpg -o ~/.gnupg/revoke.asc --gen-revoke 0xFCC5040F
GnuPG gibt entsprechende Sicherheitshinweise aus.
Warum überhaupt ein Widerrufszertifikat? Ein Grund ist zum Beispiel, dass man wirklich nur als Besitzer des Schlüsselpaares das Zertifikat erstellen kann und somit kein anderer den öffentlichen Schlüssel einfach für ungültig erklären kann. Ein weiterer Grund ist das Verhalten der Keyserver: die Keyserver synchronisieren untereinander, d.h. wird auf einem Keyserver ein Schlüssel hinzugefügt, so ist er auch bald auf allen anderen zu finden. Würde man seinen Schlüssel einfach von einem Keyserver löschen, so würde dieser sich nach der nächsten Synchronisation wieder auf dem Server befinden. Also setzt man statt dem Löschen eben das Widerrufszertifikat ein. Es gilt übrigens allgemein, dass der Schlüssel durch jede Änderung größer wird.
Anmerkung: Wenn man später echt widerrufen muss, importiert man das Widerrufszertifikat und sendet es dann an den Keyserver, und zwar mit
gpg --import ~/.gnupg/revoke.asc gpg --send-keys Schlüssel-ID
Importieren
Mit gpg --import Dateiname
wird der öffentliche Schlüssel eines Kommunikationspartners aus einer exportierten Datei importiert. Ohne Angabe eines Dateinamens kann man den Schlüssel per Copy&Paste hinein kopieren oder abtippen - Viel Spaß :-) Erst mit dem Import, also dem Hinzufügen des Schlüssels zum eigenen »Schlüsselbund« (Keyring), kann man verschlüsselte Daten mit dem Benutzer austauschen, ihn signieren, etc. Anders ausgedrückt: Erst wenn er importiert ist, »kennt« GnuPG ihn.