Dieser Artikel beschreibt die Nutzung von GNU Privacy Guard (GnuPG), einem freien OpenPGP-kompatiblen Verschlüsselungssystem.

Von Stephan Beyer

1. Persönliches Vorwort

GnuPG-Logo

Aus Neugier, um nicht immer »nur mal davon gehört zu haben«, beschäftigte ich mich 2001 mit GnuPG, dem GNU Privacy Guard. Allerdings verlor ich meinen Private Key wegen eines Versehens und hatte kein Backup. Nun wollte ich mich wieder einmal dazu aufraffen und mir GnuPG einrichten, surfte dazu auf »eine der größten deutschsprachigen Seiten zum Thema Linux und Open Source«... und war entsetzt! Es wurde kein Artikel zu GnuPG auf pro-linux.de gefunden. Also: Selber schreiben. Schließlich will ich auch beim nächsten Datenverlust schnell wieder mit GnuPG zurechtkommen. Natürlich gibt es neben diesem Artikel auch ausreichend andere Dokumentation zu GnuPG (Kurzanleitungen, Mini-HOWTO, Manuals, ...).

Bevor ich mich damit beschäftigte, war ich der Ansicht, dass ich keine verschlüsselten E-Mails brauche: Selbst wenn wirklich die Mail-Dienstanbieter, Werbeforscher, Geheimdienste, andere staatliche Institutionen oder gar die Illuminaten meine E-Mails lesen, immerhin liest jemand meine Mails :-) Trotzdem kann man sich gerade bei heiklen Themen eine sichere Privatsphäre im E-Mailverkehr gönnen und man wird immer eindeutig identifiziert - mit digitalen Unterschriften ist es sogar möglich, auf elektronischem Wege Verträge zu schließen. GnuPG bietet also schon Vorteile und deswegen sollte ein kleiner Artikel wie dieser hier auch auf pro-linux.de zu finden sein.

Da ich mit mir allerdings nicht ganz zufrieden war, habe ich den Artikel (im Februar 2005) einmal überarbeitet, und hoffe, dass er nicht nur länger (die Größe hat sich verdoppelt!), sondern auch besser als die alte Version geworden ist. :-) Wem es zu viel Text ist: überfliegen ist die Lösung. Feedback erwünscht.

2. Wozu GnuPG?

Der GNU Privacy Guard (»Privacy« im Sinne von »Datenschutz«, »Privatsphäre« oder »Briefgeheimnis«; »Guard« entspricht »Schutz«, »Wache« oder »Wächter«) kann, wie der Name vermuten lässt, Informationen und Daten vor Fremden durch Verschlüsselung schützen. Ebenso lassen sich damit Daten signieren (unterschreiben), wodurch man sie später auf Integrität und Urheberschaft prüfen kann, also schauen, ob diese Daten verändert wurden und ob sie wirklich von der Person sind, von der sie zu sein scheinen. Sehr oft wird es für E-Mails benutzt, daher beziehe ich mich im Folgenden auch oftmals auf E-Mails.

2.1. Warum verschlüsseln?

In vielen Unternehmen spielt Verschlüsselung schon lange eine Rolle zur Wahrung von Geschäftsgeheimnissen oder zum Datenschutz der Mitarbeiter. Dagegen soll es in so manchem Unternehmen auch vorkommen, dass für das Unternehmen überlebensnotwendige Daten oder eine Kunden- oder Personaldatenbank (mit Adressen, Gehältern, etc.) unverschlüsselt per E-Mail übertragen werden. Vielleicht ein Grund, warum das deutsche Bundeswirtschaftsministerium GnuPG im Jahr 2001 sogar finanziell gefördert hat.

Auch im privaten Leben hat man Geheimnisse, die man wahren will. Sei es die PIN der EC-Karte oder die liebevolle E-Mail der aktuellen Affäre. Viele Menschen meinen, dass sie nichts zu verbergen haben und es ihnen nichts ausmacht, wenn z.B. ihre E-Mails von Fremden oder Bekannten mitgelesen werden. Ich sehe das anders. Nicht umsonst wurde das Briefgeheimnis im Grundgesetz der BRD als unverletzlich verankert (...auch wenn diese Unverletzbarkeit im Abschnitt 2 des Artikels wieder beschränkt wird). Viele sind sich auch einfach nicht bewusst, dass ihre E-Mails oft über mehrere Server wandern, bevor sie am Ziel sind, und man somit diesen vielen Serverbetreibern indirekt blind vertraut. Im Grunde entspricht eine E-Mail einer Postkarte: der Postbote kann sie lesen, und auch jemand, der mit etwas Geschick in Ihren Briefkasten schaut.

2.2. Warum signieren?

Schon mal Spam erhalten, worin Sie selbst angeblich der Absender waren? In den From:-Header einer E-Mail lässt sich alles schreiben, d.h. jeder könnte sich als Sie ausgeben. Das ist in der Regel nicht zu verhindern, aber man kann solche E-Mails entkräften, indem man seine echten E-Mails konsequent signiert. Diese Signatur nachzuahmen, ist ohne Ihren Private Key geradezu unmöglich.

Als Autor von Software möchte man sich auch nichts Schlechtes nachsagen lassen. Was aber, wenn die neue Version von FooXY Daten aus dem Home-Verzeichnis löscht, einen ausspioniert, oder Ähnliches? Da könnte ein Cracker am Werk gewesen sein und FooXY entsprechend verändert haben. Dazu bedarf es nicht mal eines Crackers: Gerade Open-Source-Software wird ziemlich vielfältig auf Mirrors im Internet verteilt. So gibt sich jemand böswillig als inoffizieller Mirror aus, bietet aber eine fehlerhafte Version des Programms zum Download an. Verhindern lässt sich das nicht unbedingt, aber wenn der Autor seine herunterladbaren Dateien signiert, kann jeder überprüfen, ob die Dateien in dieser Form wirklich von diesem Autor sind. Auch bei nicht-freier Software spielt das eine Rolle, denn auch hier besteht die Möglichkeit, dass die Programmdateien von Zweitanbietern mit Viren verseucht werden.

Es ist nicht nur möglich, seine Dateien und E-Mails zu signieren, sondern auch Schlüssel zu signieren. Hiermit bestätigt man die reale Existenz und die korrekte Identität einer Person. So ist es geradezu sinnvoll, dies zu tun, denn man verhindert Man-in-the-Middle-Attacken, bei der sich ein Angreifer mit seinem öffentlichem Schlüssel als Kommunikationspartner ausgibt. Auf dieser Basis entsteht ein Vertrauensnetz, englisch: »Web of Trust«. Dazu später mehr.

3. Grundlagen

Dieses Kapitel soll ein wenig oberflächliches Hintergrundwissen vermitteln.

3.1. PGP, OpenPGP, GnuPG?

Philip Zimmermann programmierte 1991 »Pretty Good Privacy« und postete es im Usenet, wodurch es zum meistbenutzten E-Mail-Verschlüsselungsprogramm der Welt wurde und er sich strafbar machte, da die USA das Exportieren von Verschlüsselungssoftware strengstens untersagt - mittlerweile sind die Bestimmungen etwas aufgelockert. Er nutzte übrigens den patentierten RSA-Algorithmus, ohne eine Lizenz davon zu besitzen (ein Problem, das sich mit legalen Softwarepatenten in Europa zu einem Problem für alle ausweiten wird). PGP löste riesigen Wirbel weltweit aus, aber ich gehe darauf jetzt nicht weiter ein. Später gründete er PGP Inc., welche 1997 von Network Associates Inc. (NAI) übernommen wurde. 2002 verkaufte NAI die PGP-Software an die PGP Corp., welche es heute noch kommerziell vertreibt. Die Lizenzpolitik ist meines Erachtens etwas wirr: Der Quellcode für Teile der PGP-Produktserie ist einsehbar (wahrscheinlich, um zu zeigen, dass PGP nicht ausspioniert), allerdings ist PGP selbst keine freie Software, bis auf den unter der GNU GPL stehenden »PGP Universal«-Quellcode. Wer sich dafür interessiert, soll die PGP-Website konsultieren.

OpenPGP ist seit November 1998 ein Internetstandard, der die Formate (Schlüssel, Signaturen, etc.) und Methoden von PGP 5.x beschreibt.

Ein anderer derartiger Standard von 1999 ist im übrigen S/MIME (»Secure/Multipurpose Internet Mail Extension«), welcher hierarchisch und zertifikatbasiert ist. Daher eignet es sich eigentlich nur innerhalb großer Unternehmen und nicht im privaten Bereich. S/MIME und OpenPGP basieren auf MIME, sind aber nicht zueinander kompatibel.

Werner Koch ist der Autor von GnuPG, dem freien PGP-Ersatz, der ja in diesem Artikel besprochen wird. Die Erstveröffentlichung war am 20.12.1997, bis zur Version 1.0 vergingen nahezu zwei Jahre. GnuPG ist OpenPGP-kompatibel und somit ist der Austausch von Informationen mit Nutzern der PGP-Software fast kein Problem. Es unterliegt vollständig der GNU GPL und benutzt (ohne den herunterladbaren Zusatzquellcode) keine patentierten Algorithmen (RSA-Patent ist am 20.9.2000 in den USA abgelaufen; das Diffie-Hellmann-Patent, das angeblich ElGamal mit abdeckte, lief am 29.4.1997 ab; IDEA ist allerdings in den USA noch bis 25.5.2010 und in Europa sogar bis 16.5.2011 patentiert), wodurch es - wo es nationales Recht nicht verbietet - ohne Einschränkungen genutzt werden kann. GnuPG beherrscht in der jetzt stabilen 1.4-Serie kein S/MIME; GnuPG 2.0 (bis jetzt 1.9.x) soll damit umgehen können.

3.2. Verschlüsselungsverfahren

Oft ist von »symmetrischer« oder »asymmetrischer« Verschlüsselung die Rede. Doch was ist das?

Ein Verschlüsselungsverfahren ist symmetrisch, wenn es zur Ver- und Entschlüsselung ein und denselben Schlüssel verwendet. Das Problem dabei ist, dass der Empfänger diesen Schlüssel selbst erst einmal erhalten muss, um die verschlüsselte Nachricht entschlüsseln zu können. Ich muss wohl nicht erwähnen, dass dieser Schlüssel auch abgefangen werden kann und somit die ganze Verschlüsselung zwecklos wäre. Natürlich ist es möglich, den Schlüssel in verschiedene Summanden zu zerteilen und diese über unterschiedliche Kanäle (Post, E-Mail, Telefon) dem Empfänger zu übermitteln, aber das wäre auch viel zu aufwändig.

Bei asymmetrischen Verschlüsselungsverfahren, auch »Public-Key-Verfahren« genannt, gibt es dieses Problem nicht. Jeder Kommunikationspartner hat ein Schlüsselpaar, bestehend aus einem geheimen Schlüssel (»private key« oder »secret key«) und einem öffentlichen Schlüssel (»public key«). Den geheimen Schlüssel kann man selbstverständlich nicht ohne weiteres aus dem öffentlichen Schlüssel ableiten, sonst wäre das System sinnlos. Zur Verschlüsselung wird der öffentliche Schlüssel des Empfängers genutzt. Zur Entschlüsselung braucht man den geheimen Schlüssel des Empfängers - da den nur der Empfänger hat, ist es auch nur ihm möglich, die Nachricht entschlüsseln.

Wie der Name schon sagt, sollte der geheime Schlüssel unbedingt geheim gehalten werden. Aus eigener Erfahrung empfehle ich dennoch eine Sicherung. Der öffentliche Schlüssel sollte hingegen an Kommunikationspartner geschickt werden, auf der eigenen Homepage stehen, und von einem PGP-Keyserver (siehe unten) abrufbar sein. Eine möglichst weite Verbreitung des öffentlichen Schlüssels ist wünschenswert.

GnuPG (sowie PGP) benutzen eine »Kreuzung« aus beiden Verfahren, die hybride Verschlüsselung: die zu verschlüsselnde Nachricht wird mit einem (bei jeder Nachricht zufällig erstellten) symmetrischen Sitzungsschlüssel verschlüsselt, und dieser Schlüssel selbst mit dem öffentlichen Schlüssel des Empfängers. Ebenso wird bei der Entschlüsselung erst der Sitzungsschlüssel mit dem geheimen Schlüssel entschlüsselt und damit dann die eigentliche Nachricht.

3.3. Digitale Signatur

Mit der Möglichkeit, eine Nachricht zu unterschreiben, garantiert man ihre Echtheit bzw. Gültigkeit - man spricht von der »Integrität« bzw. »Authentizität« einer Nachricht (und des korrekten Absenders), die durch die digitale Unterschrift gewährleistet wird. Um es anders auszudrücken: die digitale Unterschrift erfüllt den gleichen Zweck, wie eine normale Unterschrift. Sie sollte daher fälschungssicher und verbindlich sein, d.h. sie ist nicht auf andere Dokumente übertragbar und das Dokument ist im Nachhinein auch nicht mehr änderbar (außer es wird neu unterschrieben).

GnuPG benutzt standardmäßig DSA (»Digital Signature Algorithm«), um digitale Unterschriften zu realisieren. Diese wird dabei mit dem geheimen Schlüssel des Absenders aus der Nachricht erzeugt. Der Empfänger kann die Authentizität dann mit dem öffentlichen Schlüssel des Absenders überprüfen.

Andere Personen (Freunde, Kommunikationspartner, usw.) können dann den eigenen öffentlichen Schlüssel unterschreiben, und versichern somit nach ihrem besten Gewissen, dass der öffentliche Schlüssel zu dem angegebenen Absender gehört. Man sollte nur Schlüssel von Personen unterschreiben, deren Identität man genau kennt. Hierbei spricht man auch vom »Web-of-Trust«. Als Beispiel sei das Debian-Projekt genannt, bei der jeder, der offizieller Entwickler werden will, als Grundvoraussetzung eine über Signaturen anderer Debian-Entwickler bestätigte Identität haben muss.

4. Erste Schritte

4.1. Installation

GnuPG sollte über distributions-eigene Mittel (apt-get install, emerge, pkgtool, yast, etc.) zu installieren sein. Das Paket heißt meist gnupg (z.B. in Debian, Gentoo, Fedora, Red Hat, Slackware, RockLinux und *BSD) oder gpg (bei SuSE). Ansonsten hilft das Herunterladen von der GnuPG-Homepage. Den bzip2-Tarball entpackt man ins aktuelle Verzeichnis mit tar xvfj gnupg-1.4.0.tar.bz2, zum Kompilieren und Installieren hilft ein Blick in README und gegebenenfalls INSTALL (einfaches GNU Build System).

Eventuell ist auch schon eine recht aktuelle Version auf Ihrem System installiert. Dazu gibt gpg --version Auskunft (wie auch über unterstützte Verfahren). Es sollte allerdings mindestens die Version 1.2.0 benutzt werden. Sie ist schneller und einige Versionen aus der 1.0-Serie haben Sicherheitslücken.

4.2. Erstellung der Schlüssel

Wenn man nicht nur Signaturen verifizieren möchte, ist ein eigenes Schlüsselpaar für das Arbeiten mit GnuPG unerlässlich. Man sollte die Schlüssel auf einem Rechner generieren, den man physisch vor sich hat. Auf eine telnet-Session sollte man ganz verzichten, eine ssh-Verbindung ist auch nicht zu empfehlen (z.B. auch wegen des Zufallszahlengenerators). Um ein eigenes Schlüsselpaar zu generieren, startet man nun auf der Kommandozeile:

~$ gpg --gen-key
gpg (GnuPG) 1.4.0; Copyright (C) 2004 Free Software Foundation, Inc.
...
Bitte wählen Sie, welche Art von Schlüssel Sie möchten:
   (1) DSA und ElGamal (voreingestellt)
   (2) DSA (nur signieren/beglaubigen)
   (4) RSA (nur signieren/beglaubigen)
Ihre Auswahl? 1

Man kann getrost die Voreinstellungen nehmen. Auswahl 1 heißt hier, dass ein DSA-Schlüsselpaar zum Signieren und ein untergeordnetes ElGamal-Schlüsselpaar zum Verschlüsseln verwendet wird. Auch bei den weiteren Fragen habe ich mich für die Voreinstellungen entschieden. Also: eine ELG-E-Schlüssellänge von 1024 Bit, der Schlüssel wird nie verfallen (Faulheit vs. Sicherheit, 1 oder 2 Jahre wäre vielleicht besser).

Als nächstes wird man nach Realname, E-Mailadresse und Kommentar gefragt, um den generierten Schlüssel einer realen Person zuzuordnen. Dies ist also korrekt auszufüllen. Im Kommentar kann man seinen Nicknamen, Zusätze wie z.B. »university« (also es handelt sich um die E-Mail-Adresse, die man von der Universität hat) oder »sign only« (der Schlüssel wird nur zum Signieren verwendet) benutzen, oder man lässt ihn einfach leer.

Nach der Bestätigung oder Korrektur folgt die Frage nach der »Passphrase« (in älteren Versionen auch »Mantra«). Trotz des anderen Namens ist dies nichts anderes als ein Passwort (außer dass Leerzeichen vorkommen dürfen und es länger als ein normales Passwort sein sollte), das den geheimen Schlüssel zusätzlich schützt. Trotz des anderen Namens gelten auch hier die allgemeinen Empfehlungen für ein sicheres Passwort. Das bedeutet, es sollte ein möglichst abstraktes Zeichengewirr sein, sprich: kein Name, kein Gegenstand, nicht erratbar, nicht zu kurz, und soll möglichst Zahlen, Buchstaben (klein und groß) und Sonderzeichen enthalten. Empfohlen wurde schon öfters ein ganzer Satz, allerdings sollte auch hier kreatives Chaos gemacht werden, da es nicht gut ist, wenn man die Wörter in einem Wörterbuch finden kann. Die Passphrase muss man - sofern man keinen Agenten benutzt - immer eingeben, wenn man auf den geheimen Schlüssel zugreifen will, also z.B. wenn Sie eine für Sie verschlüsselte Nachricht lesen wollen oder etwas signieren. Denken Sie also bei der Wahl einer sicheren Passphrase auch daran, dass Sie sich nicht jedes mal tottippen wollen.

Bevor Sie die Passphrase bestätigen: Setzen Sie ihr System unter Last! :-) Alternativ bewegen Sie nach der Bestätigung einfach exzessiv die Maus und drücken irgendwelche Tasten (schnell irgendein Spiel zwischendurch spielen?), denn nun werden die Zufallswerte erzeugt. Hierzu legt GnuPG Wert auf genügend »Zufälligkeit«, und der ist durch pure Werte von Software-Zufallsgeneratoren nicht ausreichend. Daher ist Ihre »Interaktion« notwendig. Nach Auflistung des erstellten öffentlichen Schlüssels mit Ihrer ersten »Benutzer-ID« (uid) sollte gpg sich beenden.

5. Und dann?

GnuPG ist nun schon voll einsatzbereit. Was man jetzt noch wissen sollte, steht in diesem Kapitel.

5.1. Auflisten

Mit gpg --list-keys erhält man eine Auflistung all seiner öffentlichen Schlüssel (»Schlüsselbund«, »key ring«). Zum Beispiel:

/home/sbeyer/.gnupg/pubring.gpg
-------------------------------
pub   1024D/FCC5040F 2004-04-26
uid                  Stephan Beyer <s-beyer@gmx.net>
uid                  Stephan Beyer (sbeyer) <sbeyer@kidstation.de>
uid                  [jpeg image of size 2193]
uid                  Stephan Beyer (Uni) %lt;Stephan.Beyer@stud.tu-ilmenau.de>
uid                  Stephan Beyer (JabberID) <sbeyer@jabber.org>
sub   1024g/AC6D579F 2004-04-26

pub steht für »öffentlich«, während sec für »geheim« stünde. Bei FCC5040F handelt es sich also um die Schlüssel-ID meines öffentlichen Schlüssels. 2004-04-26 ist das ISO-Datum (JJJJ-MM-TT) der Schlüsselerstellung. Die mit uid beginnenden Zeilen zeigen meine Benutzer-IDs (»user id«), wie z.B. Stephan Beyer <s-beyer@gmx.net>. 1024 bedeutet, der Schlüssel ist 1024 Bit lang. Hinter der Länge steht jeweils das Verfahren: ein D bedeutet DSA, g ist ElGamal. sub ist die Abkürzung für öffentliche und ssb für geheime Subkeys.

Man kann die Ergebnisliste auf bestimmte Treffer einschränken, wenn man als folgende Parameter einfach Suchkriterien eingibt. Diese sind automatisch mit ODER verknüpft. Beispiel:

~$ gpg  --list-key @pro-linux.de 'Werner Koch' 6EDDD207FCC5040F
pub   1024D/7C714C78 2004-03-24
uid                  Rene van Bevern (RvB) <rvb@pro-linux.de>
uid                  Rene van Bevern (RvB) <rvb@rvb-web.de>
uid                  Rene van Bevern (Jabber ID) <rvb@jabber.org>
uid                  Rene van Bevern (RvB) <rvb@fvwmwiki.org>
uid                  Rene van Bevern (RvB) <rvb@progn.org>
sub   1024g/77555177 2004-03-24 [expires: 2005-03-24]
sub   1024R/705988B3 2004-07-10

pub   1024D/FCC5040F 2004-04-26
uid                  Stephan Beyer <s-beyer@gmx.net>
uid                  Stephan Beyer (sbeyer) <sbeyer@kidstation.de>
uid                  [jpeg image of size 2193]
uid                  Stephan Beyer (Uni) <Stephan.Beyer@stud.tu-ilmenau.de>
uid                  Stephan Beyer (JabberID) <sbeyer@jabber.org>
sub   1024g/AC6D579F 2004-04-26

pub   1024D/57548DCD 1998-07-07 [expires: 2005-12-31]
uid                  Werner Koch (gnupg sig) <dd9jn@gnu.org>

pub   1024D/3DDBDDEA 2001-11-03
uid                  Hans-Joachim Baader <hjb@pro-linux.de>
sub   1024g/2C42C700 2001-11-03

Es ist übrigens (wie auch bei den vielen anderen gpg-Kommandos) egal, ob man Singular (--list-key) oder Plural (--list-keys) benutzt - die Ausgabe bleibt die gleiche. Kann gpg keine Treffer zur Suche finden, erzeugt es einen Fehler:

~$ gpg --list-keys gibtsnicht
gpg: error reading key: public key not found
~$ echo $?
2

Mit --list-secret-keys zeigt gpg die geheimen Schlüssel an. Brauchte ich ehrlich gesagt noch nie :-)
Mit --list-sigs zeigt gpg die Signaturen der Schlüssel an.
Mit --fingerprint zeigt gpg die »Fingerabdrücke« der Schlüssel an, mit denen man Schlüssel identifizieren kann. --fingerprint ist ein gpg-Kommando, während --with-fingerprint eine Option ist, die man bei anderen Kommandos nutzen kann:

~$ gpg --list-sigs --with-fingerprint sbeyer
pub   1024D/FCC5040F 2004-04-26
      Key fingerprint = F03F E6A6 F9B8 9520 88BA  587E 6EDD D207 FCC5 040F
uid                  Stephan Beyer <s-beyer@gmx.net>
sig 3        FCC5040F 2004-10-09  Stephan Beyer <s-beyer@gmx.net>
sig 3        7C714C78 2004-04-28  Rene van Bevern (RvB) <rvb@pro-linux.de>
sig          7624F276 2004-04-29  SilenceX <SilenceX@parityerror.de>
sig          687B8FCA 2004-06-26  Frank Lerche <frank@frank-lerche.de>
sig          4743206C 2004-06-28  Joachim Breitner <mail@joachim-breitner.de>
[...]

Anmerkung: Wenn Sie gpg-Listenausgaben in Skripten zur weiteren Verarbeitung verwenden wollen, nutzen Sie den Zusatzparameter --with-colons. Das Ausgabeformat dazu ist näher unter /usr/share/doc/gnupg/DETAILS.gz erläutert. Wenn Sie dabei mit --list-sigs arbeiten, nutzen Sie zusätzlich --fast-list-mode. Das ist schneller, da es nur die in der Signatur verankerte Schlüssel-ID anzeigt und nicht noch nach der primären Benutzer-ID im Keyring suchen muss (uid wird dann generell weggelassen). Dann sei noch --fixed-list-mode erwähnt, das Schlüssel-ID und primäre Benutzer-ID getrennt anzeigt und die Zeit in Sekunden seit 1.1.1970 angibt.

5.2. 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.

5.3. 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

5.4. 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.

5.5. Signieren von Schlüsseln

Mit gpg --sign-key ID gibt man an, dass man den Schlüssel mit der entsprechenden ID (wie bei --export oder --list-keys) signieren und somit beglaubigen will. GnuPG stellt zur Sicherheit noch ein paar Fragen, die man möglichst ehrlich beantworten sollte. Das soll heißen, dass der Schlüssel wirklich zu überprüfen ist: persönlich, mit amtlichen Ausweis und gpg-Fingerabdruck. Für solche Zwecke gibt es zum Beispiel Keysigning-Partys, worauf ich später noch zurückkommen werde.

Natürlich sollte man der Welt zeigen, dass man diesen Schlüssel signiert hat. Das macht man, indem man den Schlüssel an einen Keyserver oder dem Schlüsseleigentümer per E-Mail sendet (am besten verschlüsselt), er ihn dann importiert und selbst zum Keyserver schickt.

5.6. Bearbeiten und Löschen

Mit gpg --edit-key ID (kurz: --edit) erhält man eine interaktive GnuPG-Kommandozeile zum Bearbeiten des Schlüssels. help oder auch die Manpage leisten dazu Hilfe. Wenn man die Begriffe beherrscht, ist die Menüführung an sich sehr einfach. Mit den verfügbaren Befehlen kann man alle bisher gemacht Angaben nochmals verändern, Schlüssel signieren, ein JPEG-Foto (nicht zu groß!) von sich hinzufügen, Owner-Trusts setzen und vieles mehr.

Das Kommando --delete-key ID entfernt den angegebenen öffentlichen Schlüssel aus dem Schlüsselbund (z.B. falls man versehentlich einen falschen oder veralteten importiert hat). --delete-secret-key ID löscht angegebene (eigene) geheime Schlüssel.

5.7. PGP-Keyserver

Ich hab es vorher schon etwas erwähnt. Ein Keyserver speichert die öffentlichen Schlüssel für alle (leider auch für Spammer) abrufbar ab. Um Keyserver anzugeben, kann man die Option --keyserver Keyserver benutzen. Ich empfehle aber einen Eintrag wie keyserver Keyserver in die ~/.gnupg/gpg.conf. Außerdem empfehle ich einen Blick in die Manpage (man gpg), wegen --keyserver-options (bzw. seinen gpg.conf-Konfigurationszeilen), womit man Timeouts, Proxyserver und andere Dinge einstellen kann.

Werner Koch, der Entwickler von GnuPG, schrieb mir nach Erstveröffentlichung des Artikels eine Mail und bat mich, einen Keyserver zu empfehlen. Er schrieb:

»Fast alle Keyserver haben gewaltige Probleme mit OpenPGP-Schlüsseln, die über die ganz einfache Struktur hinausgehen. Man sollte sie deswegen nicht mehr benutzen. Die Round-Robin-Adresse subkeys.pgp.net ist eine Alternative, da diese Server gepatcht sind und die Keys wenigstens nicht mehr unbrauchbar machen - falls das passiert ist, kann man sowieso nichts mehr machen. Meine Empfehlung lautet, SKS-Keyserver zu benutzen. Diese haben eine moderne Software, die aktiv entwickelt wird, und zudem noch einen sehr fortschrittlichen Synchronisationsmechanismus. Sie syncen auch mit den alten Keyservers, sofern die Keys in Ordnung sind. In Deutschland ist keyserver sks.keyserver.penguin.de angebracht.«

Viele Keyserver bieten ein Web-Interface zur Suche, zum Abrufen und zum Einsenden von öffentlichen Schlüsseln an. Allerdings ist es oft schneller und einfacher, GnuPG selbst mit dem Keyserver kommunizieren zu lassen. Hierzu beherrscht GnuPG verschiedene Protokolle:

• Das »Horowitz Key Protocol«, kurz HKP, benannt nach Marc Horowitz vom MIT, der den ersten Keyserver überhaupt programmierte und aufsetzte. Dieser ist aber jetzt anscheinend veraltet bzw. fehlerhaft (siehe oben), daher bitte nicht verwenden! HKP basiert eigentlich auf HTTP und ist nur eine Art Erweiterung. Sowohl die ältere PKS-Software als auch die neue und bessere SKS-Serversoftware kommunizieren über HKP, das über Port 11371 läuft. Beispiele nutzbarer Server sind: x-hkp://sks.keyserver.penguin.de, x-hkp://random.sks.keyserver.penguin.de, x-hkp://keyserver.noreply.org, hkp://subkeys.pgp.net. Wer hinter einer Firewall sitzt, wird sich über einen HKP-Server auf Port 80 freuen, wie zum Beispiel hkp://keyserver.kjsl.com:80 (gepatchter PKS) oder hkp://pgp.srv.ualberta.ca:80 (SKS).
• »Finger« ist ein sehr altes Protokoll, um Informationen eines anderen Nutzers (auf demselben oder anderem Host) zu bekommen. Solch eine Information kann auch der öffentliche Schlüssel sein (je nach Fingerdämon in ~/.pgpkey, ~/.pubkey oder ~/.plan). Als Keyserver gibt man finger:User@Host an. Finger läuft über TCP-Port 79.
• GnuPG kann auch per E-Mail Keys anfordern, hochladen, suchen. Allerdings erhält man die Antwort des Servers auch nur per E-Mail und nicht von gpg selbst. Dazu sollte ein lauffähiger und konfigurierter MTA (z.B. Exim, Postfix, Sendmail, etc.) installiert sein. Die Serversoftware dazu stammt von Michael Graff. Das Keyserver-Schema sieht so aus: mailto:E-Mailadresse, meist mailto:pgp-public-keys@Server. Allerdings habe ich den Verdacht, dass alle E-Mailkeyserver veraltete PKS-Software laufen haben.
• Das »Lightweight Directory Access Protocol«, kurz LDAP, ist eigentlich ein Protokoll für Verzeichnisdienste. Network Associates Inc. kreierten die erste (einzigen?) LDAP-Keyserversoftware. Beispiele: ldap://certserver.pgp.com funktionierte bei mir als einziger, angeblich soll auch ldap://pgp.surfnet.nl gute Dienste leisten. LDAP-Keyserver lauschen auf Port 11370 und LDAPS-Keyserver auf 11369.

Für alle Protokolle sind GnuPGs Befehle die gleichen, aber das Verhalten mag leicht unterschiedlich sein. HKP ist die übliche und wahrscheinlich auch älteste Methode, daher beziehe ich mich immer auf das Verhalten von gpg, wenn es mit einem HKP-Keyserver kommuniziert.

Also wie lauten die Befehle?

1. Mit gpg --search-keys "Stephan Beyer" (kurz: --search) suche ich z.B. alle meine öffentlichen Schlüssel, und natürlich die meiner namentlichen Doppelgänger. GnuPG zeigt mir daraufhin die Treffer an. Aus diesen Treffern kann ich einen auswählen und dieser wird automatisch importiert.
2. Mit gpg --send-keys 0xFCC50404F (kurz: --send) exportiere ich meinen Schlüssel an den angegebenen Keyserver. GnuPG meldet sich dabei nur mit einer Fehler- oder Erfolgsmeldung zurück.
3. Mit gpg --recv-keys 0xDEADBEEF 0xF00BA211 (kurz: --recv) importiere ich direkt die öffentlichen Schlüssel mit den Schlüssel-IDs 0xDEADBEEF und 0xF00BA211. (Die Beispiele sind rein fiktiv.) Ist der zu empfangende Schlüssel bereits im Schlüsselbund, so entspricht das --recv einem --refresh.
4. gpg --refresh-keys (kurz --refresh) aktualisiert alle importierten öffentlichen Schlüssel. Dies kann man auch auf bestimmte Schlüssel (analog zu den anderen Befehlen) eingrenzen. Ist ein zu aktualisierender Schlüssel nicht im Schlüsselbund enthalten, so wird er ignoriert.

5.8. Verschlüsseln, Entschlüsseln, Signieren

Wenn man GnuPG hauptsächlich für E-Mails verwenden will, dann sollte man sich mit der Dokumentation seines MUAs (E-Mailprogramm) vertraut machen. Von mutt bis evolution unterstützen die meisten MUAs GnuPG direkt, über ein Plug-In oder über ein Hilfsprogramm. Meistens ist es ganz einfach mit zwei Tasten oder einem Mausklick erledigt, und schon ist eine E-Mail verschlüsselt (und signiert). Leider existieren zu viele MUAs, um hier auf alle einzugehen und es wäre ungerecht, es nur für mutt zu beschreiben ;-)

Will man vertrauliche Daten nicht per E-Mail, sondern z.B. per CD-R an den Empfänger weitergeben, so kann man Dateien auch direkt verschlüsseln:

gpg --output Datei.gpg --recipient Empfänger --encrypt Datei

Oder kurz:

gpg -o Datei.gpg -r Empfänger -e Datei

Die Endung .gpg ist natürlich nicht zwingend, sondern nur ein Vorschlag. Die armor-Einstellung lohnt bei großen über CD-R weitergegebenen Dateien nicht mehr, da eine binäre Speicherung auf CD-R kein Problem darstellt (im Gegensatz zur binären Übertragung per E-Mail) und die Datei nur unnötig größer wird. Steht also armor in Ihrer Konfiguration, so können Sie diese mit der Option --no-armor deaktivieren. Eine rekursive Verschlüsselung von Verzeichnissen ist seitens GnuPG nicht möglich. Hier sollte man entweder

• die Dateien in ein Archiv (z.B. tar) packen und dieses dann verschlüsseln, oder
• die Dateien einzeln verschlüsseln mit find Verzeichnis -type f -exec gpg -o {}.gpg -r Empfänger -e {} \; oder gpg -r Empfänger --encrypt-files Verzeichnis/* (Vorsicht mit Wildcards bei Unterverzeichnissen!) - mit armor bekommen die verschlüsselten Dateien ein .asc-Suffix, und ohne wird .gpg an den Dateinamen angehängt. Die Originaldateien bleiben erhalten.

Wie weiter oben schon erwähnt, kann der Empfänger z.B. über seine E-Mailadresse, seinen Namen oder seine Schlüssel-ID angegeben werden.

Die Entschlüsselung erfolgt analog dazu mit:

gpg -o Datei -d Datei.gpg

-d kann der besseren Lesbarkeit wegen auch als --decrypt ausgeschrieben werden. Zum Entschlüsseln wird man nach seiner Passphrase gefragt, da gpg ja auf den geheimen Schlüssel zugreifen muss.

Pures Verschlüsseln reicht oft nicht, da die Daten ja auf dem Weg zum Empfänger trotzdem noch verändert werden können. Hier hilft das digitale Signieren der Nachricht. Schlechte Überleitung :-) Mit gpg -o Datei.sig --sign Datei erstellt man eine Signatur für die Datei. Verschlüsseln und signieren zugleich funktioniert mit --sign --encrypt Datei oder kurz mit -s -e Datei. Die Signatur überprüft man mit gpg --verify Datei.gpg auf Unversehrtheit (»Integrität«). Wenn das Entschlüsseln auch ohne Signatur-Überprüfung möglich sein soll, generiert man eine abgespaltene Signatur, mit --detach-sign (kurz: -b) statt --sign. Die mit -o angegebene Ausgabedatei ist hierbei die Datei, die die Signatur enthält. Empfohlener Dateisuffix ist .sig oder auch .asc. -b lässt sich nicht sinnvoll mit -e kombinieren. Um den Unterschied zwischen -s und -b zu zeigen, ein Beispiel:

/tmp$ gpg --no-armor -s foo.tar.gz
[...]
/tmp$ gpg --no-armor -b foo.tar.gz
[...]
/tmp$ wc -c foo*
 518144 foo.tar.gz
 519374 foo.tar.gz.gpg
     65 foo.tar.gz.sig
1037583 total
/tmp$ rm foo.tar.gz
/tmp$ gpg --verify foo.tar.gz.gpg
gpg: Signature made Mon Feb 14 03:23:14 2005 CET using DSA key ID FCC5040F
gpg: Good signature from "Stephan Beyer <s-beyer@gmx.net>"
[...]
/tmp$ gpg --verify foo.tar.gz.sig
gpg: no signed data
gpg: can't hash datafile: file open error

foo.tar.gz.gpg enthält foo.tar.gz und dessen Signatur; foo.tar.gz.sig enthält nur die Signatur. Nach dem Löschen der Originaldatei kann die abgespaltene Signatur nicht mehr zum überprüfen genutzt werden. Abgespaltene Signaturen nimmt man immer, wenn man Dateien zum Download anbietet und diese signieren möchte.

Doch - Vorsicht: Zusatzwissen! - was passiert beim Signieren überhaupt? Digitale Signaturen sind eigentlich nur mit asymmetrischen Verfahren so zu erreichen, dass sie den Ansprüchen an Unterschriften gerecht werden. Zuerst wird von der Datei ein nicht umkehrbarer Hashwert über eine Einweg-Hashfunktion wie z.B. MD5 (gilt mittlerweile als unsicher) oder SHA* (SHA-1 ebenfalls) ermittelt. Salopp gesagt: Bilden Sie von einer 10-stelligen Zahl die Quersumme - das ist einfach - und dann versuchen Sie mal aus ihrer Quersumme die 10-stellige Ausgangszahl zu ermitteln (ohne sie zu kennen) - da wird es schon schwerer :-) Das leistet im Grunde die Hashfunktion. Der Hashwert wird daraufhin mit Hilfe des geheimen Schlüssels entschlüsselt - dass er gar nicht verschlüsselt ist, spielt dabei keine Rolle. Beim Überprüfen der Signatur wird sie mit dem öffentlichen Schlüssel wieder verschlüsselt (man erhält den Hashwert) und von der erhaltenen Datei wir ebenfalls der Hashwert gebildet. Die beiden Hashwerte werden verglichen. Sind sie identisch, dann ist - bei guter Hashfunktion - die Wahrscheinlichkeit sehr groß, dass die erhaltene Datei der Originaldatei entspricht. Gibt es Abweichungen, so ist eindeutig belegt, dass die Datei verändert wurde.

Die Hashfunktion ist notwendig. Würde man sie weglassen und direkt die Datei zum Signieren entschlüsseln, so hätte man das Problem, dass ein Angreifer über die Signatur Rückschlüsse auf ihren geheimen Schlüssel machen kann. Daher sollte auch der Hashwert möglichst nicht umkehrbar sein. Außerdem geht das Entschlüsseln des Hashwertes um einiges schneller, als riesige Dokumente zu entschlüsseln.

Analog zu dem weiter oben erwähnten --encrypt-files (um mehrere Dateien zu verschlüsseln) gibt es auch --decrypt-files (entschlüsseln), --verify-files (Signaturen überprüfen) und irgendwann vielleicht auch Entsprechendes für -s und -b, was in Version 1.4.0 leider noch nicht möglich ist.

Beim Verschlüsseln sollte man wissen, dass die verschlüsselten Dateien bzw. E-Mails wirklich nur der Empfänger entschlüsseln kann, also, wenn man dieser nicht ist, kann man sie auch selbst nicht mehr lesen (z.B. eine Kopie einer gesendeten verschlüsselten Mail wird lokal archiviert, und man will diese später wieder lesen). Um das zu ändern, ergänzt man encrypt-to eigeneID in der ~/.gnupg/gpg.conf. So wird zusätzlich der eigene öffentliche Schlüssel zum Verschlüsseln mitverwendet. Möchte man darauf in Ausnahmefällen wieder verzichten, so gibt man die Option --no-encrypt-to an.

Möchte man Daten gar nicht weitergeben, sondern nur vor fremden Zugriffen schützen, so kann man GnuPG auch symmetrisch verschlüsseln lassen. Dazu dient das gpg-Kommando --symmetric (kurz: -c).

~$ gpg -o gnupg.wml.gpg -c gnupg.wml
Geben Sie die Passphrase ein:

Als Passphrase wird natürlich nicht die Passphrase des geheimen Schlüssels verlangt, sondern eine frei erdachte, die nur für dieses eine Dokument gelten sollte. Entschlüsselt wird, wie auch bei der asymmetrischen Verschlüsselung, mit -d, nur dass eben die dokumentspezifische Passphrase angegeben werden muss.

Voreingestellter Verschlüsselungsalgorithmus für -c ist übrigens CAST5. Mit der Option --cipher-algo Algorithmus darf man einen anderen Algorithmus wählen. Meiner GnuPG-Version stehen zum Beispiel 3DES, BLOWFISH, AES, AES192, AES256 und TWOFISH als Alternativen zur Verfügung. Diese Information erhält man mit gpg --version.

6. Web of Trust

Ich erwähnte schon das Web-of-Trust. Ein OpenPGP-Nutzer vertraut einem anderen, indem er seine Schlüssel signiert. Das »Vertrauen« bezieht sich hierbei auf das Wissen, dass genau dieser Nutzer auch hinter diesem Schlüssel steckt und kein Man-in-the-Middle oder eine Spaßidentität. Das Vertrauen bezieht sich hier also nicht auf persönliches Vertrauen. Somit kann man auch ohne Bedenken fremde Personen und ihre Schlüssel überprüfen und sie dann signieren. Durch starke Verwebungen im Web-of-Trust wird es auch schwer, dieses Netz wieder zu zerstören: ein kompromittierter (geknackter) Schlüssel bringt nicht das gesamte System zu Fall.

6.1. Keysigning-Partys

Keysigning-Partys (kurz: KSP) sind leider viel zu seltene gesellschaftliche Ereignisse. Auf dem Linuxtag in Karlsruhe und auf dem Chaos Communication Congress waren im Jahr 2004 wohl größere Ereignisse dieser Art. Zu einer Keysigning-Party treffen sich Menschen aus allen Gegenden, um sich gegenseitig zu signieren. Die Motivationen sind unterschiedlich: die Stärkung und Ausweitung des Web-of-Trusts, das Erhöhen des eigenen Ranges in Key-Analysen, ... - für einige ist es auch einfach nur eine Art Sport, möglichst viele Signaturen zu ergattern. Wenn Sie viele Signaturen haben, haben auch Menschen, die Sie nicht signiert haben, einen Anhaltspunkt, dass Sie auch wirklich Sie sind. Allerdings ist das noch kein Grund, Sie einfach so ohne Kontrolle zu signieren, denn das würde eine Abschwächung des Web-of-Trusts bedeuten, da die Schwelle zum Signieren sinkt - Ihre ganzen Signaturen könnten ja auch von Menschen sein, die mit Ihnen unter einer Decke stecken :-) Nebenbei kann man auf Keysigning-Partys einige neue, vielleicht auch interessante, Leute kennen lernen. Durch Keysigning-Partys werden auch manchmal mehrere kleinere Web-of-Trusts zu einem großen zusammengeführt bzw. vom so genannten »Strong Set« aufgesogen.

Wie laufen also solche Keysigning-Partys ab? Meist steht alles Wichtige dazu auf der Website einer solchen Veranstaltung und meist ist dort auch ein Link auf das GnuPG Keysigning-Party HOWTO zu finden. In dem ist eigentlich alles Wichtige beschrieben, trotzdem hier eine kurze, grobe Zusammenfassung...

Als erstes sollte man seinen öffentlichen Schlüssel an den Koordinator (Veranstalter, Organisator, ...) oder auf einen Keyserver schicken - das ist von KSP zu KSP unterschiedlich. Bei der Lösung über den Keyserver muss man sich dennoch anmelden, da der Aufwand einer KSP riesig wäre, wenn alle unangemeldet kämen. Vom Veranstalter wird zu gegebenem Zeitpunkt eine Liste veröffentlicht, die alle Teilnehmer enthält. Diese Liste ist, wenn sie im Internet veröffentlicht wird, auszudrucken und mitzunehmen. Manchmal wird sie auch direkt vor der Veranstaltung unter den Teilnehmern verteilt.

Auf den Listen befindet sich nicht nur der Name und die Schlüssel-ID der Teilnehmer, sondern auch die Fingerprints. Der Fingerprint ist übersetzt der elektrische Fingerabdruck des Schlüssels und eigentlich nichts anderes als der MD5-Hashwert. Die Schlüssel-ID ist bei DSA-Schlüsseln übrigens einfach der letzte 16- bzw. 8-stellige Teil des Fingerprints. Es gilt nun vor bzw. bei der KSP den eigenen Fingerprint (Ausgabe mit gpg --fingerprint eigeneID) mit dem auf der Liste zu vergleichen und abzuhaken. Ein Stift ist bei einer Keysigning-Party also auch von Vorteil (wird auch im Howto extra genannt) :-) Im ersten Teil der KSP bestätigt jeder lautstark, dass der Fingerprint auf der Liste mit dem eigenen übereinstimmt. Stimmt er nicht, dann ist er zu berichtigen oder einfach nicht abzuhaken.

Im zweiten Teil geht es ans Vergleichen der Identität der Teilnehmer. Alle nehmen einen amtlichen Ausweis heraus und dann wird reihum oder zentral (z.B. über eine Projektion des Ausweises an die Wand) verglichen. Beim Vergleichen sollte der Name auf der Liste mit dem Namen auf dem Ausweis und das Gesicht auf dem Ausweis ungefähr mit dem realen Gesicht übereinstimmen. Wenn ja (beim Photo-Gesicht-Vergleich muss man meist tolerant sein), gibt es ein Häkchen, sonst nicht.

Auf KSPs sind aus Sicherheitsgründen keine Laptops zugelassen, und so geht die Arbeit erst im Nachhinein richtig los: das Signieren. Also man nimmt sich etwas Zeit und signiert (--sign-key) alle Teilnehmer, bei denen zwei Häkchen sind und bei denen der Fingerprint auf der Liste mit dem von GnuPG angezeigten Fingerprint übereinstimmt. Als nächstes sendet man den signierten Schlüssel entweder auf einen Keyserver oder per E-Mail zu dem Teilnehmer selbst (meist bevorzugt).

Da Signieren und Verschicken die aufwändigsten Schritte darstellen, gibt es dafür einige Skripte und Hilfen im Netz. Ich hab diese allerdings noch nicht getestet und kann nicht viel zur Funktionsweise sagen:

• der von u.A. Peter Palfrader geschriebene CABot, eine Perl-Skriptsammlung, scheint relativ beliebt zu sein, denn er begegnete mir schon recht häufig. Einfach zu installieren (auch apt-get install cabot in Debian), gepflegt und gut dokumentiert, aber recht komplex bzw. umfangreich. Werde ich wohl für die nächsten KSPs auch nutzen.
• signing-party bzw. apt-get install signing-party enthält das Skript gpg-mailkeys IDs, womit das Verschicken recht einfach fällt.
• Beschreibung, wie man »schnell und einfach« signiert und ein Perl-Skript, das die signierten Keys an ihre Eigentümer mailt - von Thomas Themel, 2001
• gpgsigs ist ein Perl-Skript, das einem vor einer Keysigning-Party auflistet, wen man aus dem KSP-Keyring schon signiert hat.

6.2. Key-Analysen

Im Internet stößt man ab und zu auf Analysen bestimmter Web-of-Trusts. Einige Keyserver-Betreiber lassen ihre Skripte sogar den gesamten Schlüsselbestand analysieren. Das Ergebnis sind oft Tabellen oder sonderbare Graphen. Einige Begriffe möchte ich dazu schnell klären.

Pfad

Der Pfad ist ein möglicher Weg, um über die Signaturen eines Schlüssels zu einem anderen zu gelangen. Von Interesse ist meist der kürzeste Pfad.

Distanz

Die Distanz eines Schlüssels zu einem anderen Schlüsseln beschreibt die Länge des kürzesten Pfades, d.h. die Anzahl der »Stationen«, um von einem Schlüssel zum anderen zu gelangen.

MSD

Die »Mean Shortest Distance« ist die durchschnittliche Distanz eines Schlüssels zu allen anderen analysierten Schlüsseln.

Rank

Der Rank (Rang) ist die Platzierung eines Schlüssels innerhalb einer analysierten Menge. Die Rangordnung geht meist von den MSDs aus, d.h. der Schlüssel mit der kleinsten MSD ist auch der erste.

Strong Set

Die, wörtlich, »starke Menge« ist die größte Menge der Schlüssel, die einen Pfad zu einem anderen Schlüssel in dieser Menge haben - oder kurz: das größte abgeschlossene Web-of-Trust.

Beispiele für Key-Analysen im Internet:

• Pfade und Statistiken einzelner Schlüssel (über Formular eingebbar).
• Jason Harris erstellt u.A eine Top 1000 und eine Top 50 aller Keys (geordnet nach MSD). Haben Sie sich schon entdeckt?
• eine Analyse über die Entwicklung vom Strong Set, von Henk Penning.
• Auf der sig2dot-Homepage findet man Graphen verschiedener Web-of-Trusts.
• »Leaf Of Trust«-Grafiken mit dem Web-of-Trust von Jörgen Cederlöf

6.3. BigLumber.com

BigLumber.com hat, wie ich finde, eine besondere Erwähnung verdient: Es bietet alles, was man braucht, um Keysignings zu organisieren. Als signierwilliger Mensch fügt man dort seinen Schlüssel hinzu, gibt sein Land und die nächstgrößere Stadt ein und schon ist man von anderen Signierwilligen auffindbar, kann sich treffen und signieren. Ebenso kann man geplante Keysigning-Partys eintragen und BigLumber verwaltet auf Wunsch sogleich den KSP-Schlüsselbund, wodurch sich jeder selbst anmelden kann, ohne dass der Koordinator sich darum kümmern muss. Über einen RSS-Feed bleibt man immer über die neuesten Anmeldungen informiert. Nachteil ist das sehr lange Passwort, das sich kein Mensch merken kann. Aber dafür wird es einem verschlüsselt gesendet :-)

7. Grafische Oberflächen

Da GnuPG an sich nur durch Kommandozeilenoptionen bedienbar ist und es einige GUI-Liebhaber unter den GnuPG-Nutzern gibt, wurden auch GUI-Frontends dafür programmiert. Fünf davon stelle ich hier kurz vor.

7.1. GNU Privacy Assistant

Der GNU Privacy Assistant (gpa) erschien mir auf den ersten Blick als eine nett anzusehende GTK2-Anwendung. Doch es steckt auch etwas dahinter.

Schlüsselverwaltung und Über-Fenster

Zuerst wäre da die Schlüsselverwaltung: für jeden öffentlichen Schlüssel im Schlüsselbund sieht man unten eine Detailansicht (mit allen wichtigen Informationen), im »Signaturen«-Tab kann man lesen, wer diesen Schlüssel signiert hat und wenn man die »Bearbeiten/Einstellungen/Einstellungen für Fortgeschrittene« aktiviert, sieht man auch die untergeordneten Schlüssel. Durch Anklicken der Tabellenköpfe in der Tabelle kann man die Sortierung ändern - intuitiv - wie auch die Menüführung an sich. Schlüsselgenerierung, Import, Export, Löschen, an Keyserver exportieren, von Keyserver importieren (allerdings keine Suche), das Ändern der Passphrase, des Owner-Trusts und des Verfallsdatums - man kann sagen, dass zur Schlüsselverwaltung alles Wichtige enthalten ist. Das Einfügen von Fotos kann der GNU Privacy Assistant allerdings nicht.

Klickt man auf »Fenster/Dateiverwaltung« oder auf das »Dateien«-Icon, so öffnet sich ein neues Fenster. Hier kann man eine oder mehrere Dateien verschlüsseln, signieren, entschlüsseln oder prüfen. Dabei sind stets wichtige Einstellungen möglich, z.B. ob man eine »Ascii-Verpackung« (armor) will oder nicht. Auch hier kann man bei der Bedienung nicht viel falsch machen. Einfach nett.

Einen Haken gibt es bei der getesteten Version 0.7.0 trotzdem: Es ist mir mehrfach beim Arbeiten in der Schlüsselverwaltung wegen mißglücktem free() eines falschen Pointers abgestürzt - z.B. beim Laden des Preferences-Dialogs, nach einer Umsortierung, während es noch lädt, oder beim Suchen eines Schlüssels im Schlüsselbund - nie ganz rekonstruierbar. Unschön.

7.2. gPGP

gPGP mit Datei und Tools Menü

gPGP wartete mit einer schlichten Gnome/GTK1-Oberfläche auf. Dürre Menüs, nicht implementierte Funktionen und die nicht ganz so intuitive Bedienung ließen mich nicht lange an gPGP kleben. Zum Verschlüsseln, Signieren, Entschlüsseln, Überprüfen, Exportieren und Importieren taugt es wohl trotzdem.

7.3. Seahorse

Seahorse-Hauptfenster

Seahorse kommt mit einer recht netten und simpel gehaltenen GNOME2-Oberfläche. Im Gegensatz zu GPA und entgegen der Programmbeschreibung ist Seahorse eine reine Schlüsselverwaltung und man kann keine Dateien verschlüsseln - zumindest konnte ich solche Funktionen nicht finden. Dafür steht im »Key«-Menü z.B. die in GPA fehlende Foto-Funktion. Allerdings hab ich sie in der Version 0.7.5 nicht aktiviert bekommen - ist wohl immer noch nicht implementiert. In GPA fehlte außerdem die Funktion, sich ein Widerrufs-Zertifikat zu erstellen. Dies ist hier möglich. Außerdem ist der gesamte Schlüsselbund sofort verfügbar und muss sich nicht erst ewig aufbauen, wie in GPA. Dafür konnte ich keine Keyserver-Funktionen in Seahorse finden. Für sich ganz nett, aber im Vergleich ist GPA nutzbarer.

7.4. TkPGP

TkPGP-Hauptfenster

TkPGP ist, wie der Name schon sagt, eine Tcl/Tk-Anwendung und auf PGP ausgelegt, hat aber ebenso Support für GnuPG. Die Oberfläche ist recht spartanisch. Eine Schlüsselverwaltung ist mit TkPGP gar nicht möglich, sondern nur das Verschlüsseln, Signieren und Entschlüsseln von möglichst nicht-binären Daten. Ich würde insgesamt wohl eher zum Kommandozeilentool gpg greifen als zu TkPGP.

7.5. kgpg

kgpg-Hauptfenster

kgpg scheint die einzige noch entwickelte GnuPG-GUI zu sein, die die KDE-Bibliotheken nutzt. Das heißt für mich: erst mal 60 Megabyte (ungepackt) KDE-Bibliotheken installieren :-) Bei meinem ersten Aufruf des Programms entgegnete mir nach wenigen Sekunden ein »KGpg Wizard«, der mich fragte, wo sich meine GnuPG-Konfiguration befindet, und ob er ein »Shredder«-Icon auf meinem Desktop installieren darf, welcher Dateien, die man darauf zieht, 35 mal überschreibt und löscht. Danach kam der »Generate Key Pair«-Dialog, den ich abbrach, da ich ja schon einen Schlüsselpaar habe, und dahinter öffnete sich das Fenster mit der Schlüsselverwaltung.

Was mir gleich positiv auffiel: mein gesamter Schlüsselbund war wie bei Seahorse sofort sichtbar, wo GPA noch ewig laden musste. Die Bedienung von kgpg ist ebenso intuitiv wie GPA. Durch das »Aufklappen« eines Schlüssels werden Signaturen und Benutzer-IDs sichtbar (bei Seahorse lediglich Benutzer-IDs). Der »Keys/Edit key«-Dialog ist übersichtlich. kgpg ist weitestgehend konfigurierbar: Toolbars, Schriften, Shortcuts, Keyserver, etc. Es erlaubt das Gruppieren von Schlüsseln unter »Groups/Create Group with Selected Keys...«, was auch eine nette Idee ist. Eine Photo-ID kann es direkt in der Auflistung der Schlüssel mit anzeigen und auch hier bleibt es relativ flott. Das Exportieren eines Schlüssels unter »Keys/Export Public Key(s)« ist in eine Datei, in die Zwischenablage, als E-Mail oder auf einen Keyserver möglich. Die Suche in der Schlüsselverwaltung beinhaltet nicht nur die Suche nach einer Schlüssel-ID, sondern auch nach Name und E-Mail.

Unter »File/Open Editor« öffnet sich ein integrierter Editor, worin sich Texte tippen und zugleich verschlüsseln, signieren, entschlüsseln und überprüfen lassen kann. Allerdings klappte nichts davon bei mir. Binäre Dateien kann man über »File/Encrypt File...« verschlüsseln, bzw über »File/Decrypt File...« entschlüsseln, ohne sie erst in den Editor laden zu müssen. Wahrscheinlich gliedert sich alles perfekt in die gesamte KDE-Oberfläche ein, aber das kann ich nicht beurteilen, da ich nichts davon installiert habe.

Insgesamt lässt sich sagen, dass ich von kgpgs Funktionsumfang positiv überrascht bin. Allerdings startet es bei mir nach dem ersten Aufruf nicht mehr, solange ~/.kde noch existiert. Das liegt aber bestimmt nur daran, dass ich kein KDE benutze.

8. Referenzen

Lizenz

Dieser Text unterliegt einer »Creative Commons«-Lizenz. Freie Verbreitung in modifizierter oder unmodifizierter Form ist erlaubt; Modifikationen müssen ebenfalls unter dieser Lizenz vertrieben werden; Stephan Beyer muss als ursprünglicher Autor genannt werden; über weitere Verwendungen würde ich gern informiert werden.