Man müht sich ab, seinen Kunden beizubringen, wichtige Informationen im Internet verschlüsselt zu übertragen. Eine Voraussetzung dafür, dass der Kunde sich mit den entsprechenden Verfahren anfreundet, ist, dass das Erzeugen eines Schlüsselpaares und das Verteilen des öffentlichen Schlüssels ohne größere Schwierigkeiten durchgeführt werden kann – unter Linux wie unter Windows. Leider können hier auch unter Linux Schwierigkeiten auftreten, die den Anfänger überfordern.
Vor kurzem konnte ich die Probe aufs Exempel machen – ein Kunde, der Thunderbird unter Windows einsetzt, lud sich das Enigmail-Plugin und GnuPG für Windows herunter. Die Installation verlief problemlos. Ebenso nach einer kurzen Einweisung die Suche nach meinem “public key” und der Import des Schlüssels von einem PGP-Server in den Schlüsselring. Der Kunde konnte mir dann auch ohne Schwierigkeiten verschlüsselte Mails schicken. So weit so gut.
Die Überraschung kam nach dem Generieren des eigenen Schlüssels. Die Erzeugung des Schlüsselpaares verlief wie erwartet. Der Kunde sah den Schlüssel, dessen Kennung (die letzten 8 Ziffern des Fingerprints) und bei einer Detailansicht auch den gesamten Fingerprint. Der Kunde versuchte dann seinen öffentlichen Schlüssel auf einen PGP-Server hochzuladen. Auch dies war ohne Problem möglich. Dann suchte der Kunde zur Probe nach seinem Schlüssel – zunächst mittels eines Statements der folgenden Art:
http://pgpkeys.pca.dfn.de/pks/lookup?op=vindex&hash=on&fingerprint=on&search=0x{16 Hex-Ziffern}
wobei “{16 Hex Ziffern }” durch die letzten 16 Hexadezimal – Ziffern des Schlüssel-Fingerprints zu ersetzen ist. Der Schlüssel wurde einwandfrei identifiziert und angezeigt. Dann probierte der findige Kunde jedoch folgendes Statement, bei der er dem “search”-Parameter nur die letzten 8 Stellen der Schlüssel-Kennung übergab (nur diese werden nämlich typischerweise in den Key-Verwaltungsprogrammen angezeigt):
http://pgpkeys.pca.dfn.de/pks/lookup?search=0x{8 Hex Ziffern = Schlüsselkennung}&fingerprint=on&hash=on&op=vindex
Wie es der (unwahrscheinliche) Zufall so will, kamen als Antwort 2 Schlüssel mit derselben 8-stelligen Kennung hoch – der des Kunden und einer, der im Jahre 1998 angelegt wurde. Diese “Konkurrenz” bzgl. der 8 stelligen Schlüsselkennung fand der Kunde sehr beunruhigend. Ich demonstrierte ihm dann, dass sein Schlüssel dennoch von dem des “Konkurrenten” verschieden war und dass die Schlüsselkennung und der Fingerprint ja eigentlich mehr als 8 Hex-Stellen umfassen. So zeigt z.B. KGpg unter KDE in der Detailansicht eines Schlüssels nicht 8 sondern die hinteren 16 Hex-Stellen des Fingerabdrucks an.
Der wirkliche Ärger begann aber, als ich versuchte, den öffentlichen Schlüssel des Kunden unter Linux/KDE in meinen eigenen Schlüsselring zu importieren. Das misslang unter KDE KGpg bei Einsatz des Standardimports von einem PGP-Server auf wirklich schlimme Weise:
Obwohl ich die eindeutige 16 stellige Kennung im Such/Import-Dialog angab, importierte KGpg beide Schlüssel – den des Kunden und des Konkurrenten. Noch schlimmer: In der Detailansicht wurde bei beiden Namen ein und derselbe Fingerprint (der des Kunden), aber die falsche Kennung (die des Konkurrenten) angezeigt. KGpg hatte also die beiden Schlüssel beim Import intern nicht sauber getrennt.
So etwas ist katastrophal! KGpg ist offenbar nicht in der Lage den Standard-Import von Schlüsseln zu regeln, wenn die letzten 8 Hex-Stellen der Kennung mit denen eines anderen Schlüssels identisch sind. Das Gleich geschah übrigens auch, wenn man nach der dem Schlüssel zugeordneten Namen bzw. der Web-Adresse suchte.
Testweise versuchte ich dann den Import unter Windows mit Thunderbird und den dahinter liegenden OpenPG-Programmen. Auch hier werden zwar zwei Schlüssel importiert – offensichtlich reagieren die Programme nur auf die letzten 8 Hex-Stellen. Aber der Import verlief mit der richtigen Zuordnung der Schlüssel zu den Namen und Webadressen.
Eine Lösung des Problems unter KGpg besteht darin, den Import des Kundenschlüssels manuell über die Zwischenablage durchzuführen. Für Einsteiger wäre das aber nicht zumutbar.
