[This article is in German because it is an reply to an article in the German c't magazine]

In der c't 6/2015 vom 21. Februar fordert Redakteur Jürgen Schmidt in seinem Editorial: „Lasst PGP sterben“. Er hält PGP (also den OpenPGP Standard) für technisch veraltet und einen „lahmen Dinosaurier“. Dabei vergleicht er PGP mit Online Diensten von Apple sowie mit TextSecure Chat-Dienst. Mal ganz abgesehen davon, daß alle amerikanischen Firmen gezwungen sein können, Hintertüren in Ihre Anwendungen einzubauen, werden hier Güterzüge mit U-Booten verglichen. Gut, sie werden beide aus Metall gebaut und könne Dinge transportieren, aber damit hört es dann schon auf. In dem Artikel Die Schlüssel-Fälle auf Seite 160 versucht er sodann die Probleme zu erläutern.

Online Protokolle wie TextSecure mit Offline Protokollen wie OpenPGP oder S/MIME zu vergleichen ist keine lautere Argumentation. Ein Meeting, ob direkt oder per Videokonferenz, hat offensichtlich ja auch ganz andere Erfordernisse als ein Briefwechsel. Viele Angelegenheiten können in einem direkten Gespräch viel einfacher geklärt werden als durch eine zeitlich versetzte Diskussion per Mail. Aber damit werden Briefe/Mails und Berichte noch lange nicht überflüssig; nur durch diese Offline Kommunikation können Information auch (vertraulich) aufbewahrt werden und stehen für spätere Bearbeitung noch zur Verfügung.

Wir benötigen Offline Protokolle, da sie auch funktionieren wenn das Netz zusammengebrochen ist. Auch ist das „Sneakernet” in vielen Fällen günstiger (hohe Bandbreite, vgl. Backups) und sicherer als eine Onlineverbindung. Wer Citizen Four gesehen hat wird sich daran erinnern, wie Snowden zwischen Online und Offline Laptop unterscheidet. Im Übrigen ist Email qua Architektur Offline.

Im Gegensatz zu S/MIME, dem anderen Offline Protokoll, ist OpenPGP dezentral und hat damit große Vorteile: Man kann es überall benutzen und braucht nicht erst eine CA. Die Zusammenkünfte mit anderen Menschen muß man sich ja auch nicht vorab vom Einwohnermeldeamt (dem Pendant zu einer CA) bestätigen lassen.

Die Forderung, Keyserver sollen einen Upload nur zulassen, nachdem sie eine Mail Bestätigung eingeholt haben, zielt wiederum auf ein zentralisiertes System und geht damit vollkommen an der Realität der de-zentralen Architektur von OpenPGP vorbei. Bei zentralen Diensten kann man das halt machen aber nicht bei de-zentralen replizierten Diensten, die absichtlich nicht unter einer gemeinsame Kontrolle stehen.

Die lästigen Probleme, die Jürgen Schmidt offenbar mit nicht-enschlüsselbaren Mails hat, könnte man seht leicht abmildern, indem die c't im Impressum und auf der Webseite auch die notwendigen Kontaktdaten angibt: Also nicht nur Mailadresse sondern zumindest auch die lange KeyID oder den Fingerprint sowie die direkte URL zum Schlüssel.

Auf die gleichartigen Probleme bei S/MIME ist gar nicht eingegangen worden, obgleich dies das andere und angeblich gängigere Mailverschlüsselunsgprotokoll ist. Dies wundert umso mehr, als die c't seit einigen Jahren immer wieder S/MIME als einfache Lösung propagiert. Nur, wie findet man damit den Schlüssel wenn er einem nicht in einer ersten Mail geschickt wird? Die vermeintlichen vertrauenswürdigen CAs sind ein Scherz. Mit deren Hilfe kann jede staatliche oder private Spionageorganisation sich beliebige Zertifikate für beliebige Adressen ausstellen lassen. Das sind dann zwar nicht so offensichtlich falsche Schlüssel wie bei den Keyservern aber freut um so mehr die NSA, den GCHQ, und den BND.

Das direkte Webinterface der Keyserver zu benutzen, um so angebliche „falsche“ Schlüssel aufzuzeigen, ist eine unsinnige Vorgehensweise da Keyserver keine kryptographischen Prüfungen durchführen können (bzw. wollen). Das sollte dem Autor des Artikels bekannt sein, inbesondere da er mich noch einige Tage vorher danach gefragt hatte. Bei der Benutzung von OpenPGP Software wird sich schnell herausstellen, was ein „gefälschter Schlüssel” ist - so ein Schlüssel bzw. User-Id wird erst gar nicht importiert oder in einer Schlüsselliste angezeigt.

Selbstverständlich kann man beliebige Schlüssel anlegen. Beliebtes Beispiel is [email protected] mit zirka 27 Schlüsseln. Das ist ja nun wirklich nichts Neues und etwas was man auf jeder Crypto-Party lernt. Deswegen gibt es aber auch die Fingerprints in manchen Zeitschriften und auf vielen Visitenkarten. Eingeweihte haben dann auch noch die Keysigning-Parties (obgleich diese mehr ein Gesellschaftsspiel sind als einem Massenpublikum dienlich).

Anstatt über Keyserver und OpenPGP allgemein herzuziehen wäre mehr erreicht, die Mail-Provider aufzufordern, etwas zu tun: Mailadressen sind einzig über das DNS festgelegt und deswegen kann und sollte man auch das DNS benutzen um an einen passenden Schlüssel zu gelangen. Der kann zwar immer noch gefälscht sein, da DNS nicht wirklich sicher ist, aber immerhin gäbe es dann einen passenden Schlüssel zu jeder Mailadresse. Dazu gibt es seit Jahren RFCs und GnuPG hat es seit 2006 implementiert (vgl. GUUG FFG Vortrag). In 2012 habe ich hierzu mit meinem Kollegen Marcus Brinkmann ein Konzept unter dem Namen Steed veröffentlicht, wozu es in der c't den größtenteils korrekten Artikel Vertrauen auf den ersten Blick gab.

Leider wollen die Provider dabei nicht mitmachen und lullen die Öffentlichkeit in Sicherheit durch Schwachsinn wie Email made in Germany oder gar dem Verweis auf den Hintertürdienst De-Mail ein.