spamtrap@pkx.be

Wie verschlüsseln – sicher kommunizieren mit OpenPGP

Eine Einführung in OpenPGP für Leute, die wenig Ahnung haben und viel Ahnung haben wollen.

Worum geht’s

Das ist eine Anleitung für OpenPGP. Die Voraussetzungen sind gering. Da die Annahme aber ist, dass du Interesse daran hast, wirklich zu verstehen, was du da tust, wenn du Sachen verschlüsselst, Signaturen prüfst usw., ist die Annahme auch, dass du generell keine sehr doll großen Berührungsängste gegenüber Computern hast. Es wird also nicht erklärt, was eine Tastatur ist, was ein Internet ist und wie man den Computer einschaltet. Andererseits wird auch mal mehr in die Tiefe gegangen. Wenn dich die Passagen interessieren, kannst du die lesen. Wenn nicht, kannst du sie überspringen.

Passagen, die du überspringen kannst, sind so markiert wie diese hier. Klapp sie mal kurz aus, um den Inhalt zu sehen!

So sieht der Inhalt der ausgeklappten Passage aus. Du kannst sie jetzt wieder einklappen.

Das letzte Drittel (ab dem Abschnitt „Schlüssel und andere Dinge widerrufen“) könnte man als weiterführende Gedanken betrachten. Ich denke, dass das auch wichtig ist, aber du kannst das dann lesen, wenn du dich ein bisschen eingefuchst hast mit deinem ganzen neuen Kryptowissen.

Ende 2023 habe ich hier zuletzt etwas bearbeitet.

Mithilfe erwünscht

Wenn du dich schon ein bisschen mit den Themen auskennst, um die es hier geht, dann lies bitte hier weiter, denn ich möchte diese Anleitung mit deiner Hilfe weiterentwickeln.

Diese Anleitung ist natürlich nicht vollständig und endgültig. Für Anmerkungen bin ich immer offen. Wenn du Fundamentalkritik hast – Das kann man so gar nicht schreiben. Der Ansatz, Leute an Kryptographie heranzuführen, ist völlig falsch. OpenPGP soll man gar nicht mehr benutzen. Sowas in der Art. –, dann musst du dich nicht mit Verbesserungsvorschlägen bei mir melden; sondern in dem Fall empfehle ich dir, deinen eigenen Ansatz zu verfolgen. Du kannst mir dann gerne Bescheid sagen, wenn es etwas Verlinkbares gibt. Vielleicht verlinke ich das dann in meiner Anleitung. Wenn du aufbauend auf dem, was ich hier geschrieben habe, konstruktive Verbesserungs- und Ergänzungsvorschläge hast, dann bitte her damit.

Ich habe auch konkrete Wünsche: Wenn du MacOS nutzt und mir sagen kannst, wie man unter MacOS Software installiert und aktuell hält, dann freu ich mich über deine Kontaktaufnahme. Es ist mir bisher nicht gelungen, MacOS in einer VM zu installieren, um das selber auszuprobieren. Wenn du zu Android und IOS etwas sagen kannst, dann bin ich auch da für Ergänzungen offen, weil ich auch auf diese Betriebssysteme keinen unkomplizierten Zugriff habe. Streckenweise habe ich nur wenige Links im Text, weil ich keine Muße hatte, geeignete Quellen rauszusuchen. Wenn du schöne Quellen kennst, die ich verlinken kann, dann gib her.

Für allen Input schreib an die E-Mail-Adresse t-spamschutz-@pkx.be. Mein OpenPGP-Schlüssel ist per WKD abrufbar.

Warum verschlüsseln

Hier sind Argumente dafür zusammengetragen, warum du dich überhaupt mit Kryptographie allgemein beschäftigen solltest. Wenn du das jetzt nicht brauchst, sondern schnell loslegen willst, dann überspring diesen Abschnitt.

Privatsphäre ist ein Grundrecht. Man muss sich deswegen nicht erklären. Damit könnte dieser Abschnitt beendet sein.

Na gut. Ein bisschen mehr ließe sich dazu noch schreiben. Außerhalb Deutschlands interessiert sich niemand für die deutschen Grundrechte. In nicht ganz so bindender Weise folgt die Privatsphäre und das Fernmeldegeheimnis zumindest auch aus Artikel 12 der Allgemeinen Erklärung der Menschenrechte und Artikel 8 der Europäischen Menschenrechtskonvention. Sich auf die vom Staat zugebilligten Rechte zu beziehen, taugt nur insofern sie vorhanden sind und so lange sie nicht wieder abgeschafft wurden. Das politische Klima kann sich schnell wandeln. Weltweit gibt es Bestrebungen, Privatsphäre zu untergraben. Aber es gibt eine Sache, die hilft gegen Kriminalisierung von Verschlüsselung; gegen Versuche, Verschlüsselung unbrauchbar zu machen durch den Zwang, Schlüssel an offizieller Stelle zu hinterlegen (sog. Key Escrow); dagegen, dass der Staat Sicherheitsprobleme in Software rausfindet und geheimhält, um sie selber auszunutzen und Computer von Leuten zu hacken, um deren Verschlüsselung zu umgehen (sog. Quellen-TKÜ); gegen den Druck auf Organisationen, schlechte (nicht verschlüsselnde) Standardeinstellungen zu wählen – gegen das alles hilft massenhafte selbstverständliche Nutzung von Verschlüsselung. Sich darauf auszuruhen, dass „die Server in der EU stehen“, hilft nicht.

„Ich habe ja nichts zu verbergen.“ ist genau kein Argument gegen Verschlüsselung, sondern eins dafür. Wenn nur diejenigen verschlüsseln, die etwas zu verbergen haben, dann fällt die Auslese und genauere Beobachtung leicht. Im Übrigen haben alle ganz viel zu verbergen. Wer nicht verschlüsselt, gefährdet auch sich, aber vor allem – was viel schlimmer ist – andere. Wenn A nicht verschlüsselt, dann können A und B nur unverschlüsselt kommunizieren. Das sind also Bs Daten, mit denen A viel zu leichtfertig umgeht. Verschlüsselung hilft gegen zielgerichtete Überwachung.

Alle haben ganz viel zu verbergen. Aus großen Datenmengen werden mit Verfahren des Maschinellen Lernens Rückschlüsse nicht nur auf Trends, sondern auch auf Einzelpersonen gezogen. Reale Precrime-Bestrebungen zum Beispiel basieren auf solchen Datenauswertungen. Verschlüsselung hilft gegen Massenüberwachung.

Wenn du trotz alledem der Meinung bist, dass die politische Situation, in der du dich befindest, ja nicht so furchtbar schlimm sei und du bei deinem Lebensstil zumindest keine staatliche Repression zu befürchten habest, dann möchte ich dich daran erinnern, dass sich solche Zustände auch ändern können. Nach der Wahl in Thüringen 2024 könnte zum Beispiel eine Regierungsbeteiligung einer faschistischen Partei anstehen, wie es bei der Wahl davor auch schon befürchtet wurde. Deutschland hatte in den letzten hundert Jahren oft nicht so richtig viel Glück mit seinen Regierungen. Auch die Nachbarstaaten hatten infolge dessen einige Probleme, beispielsweise die Niederlande, die aus Versehen zu viele Daten rumliegen hatten. Hochgradig gefährliche Datensammlungen sind kein abgeschlossenes Kapitel aus vergangenen Jahrtausenden. Rosa Listen wurden mindestens bis vor Kurzem noch geführt in Deutschland. Möglicherweise immer noch. Was Polizeien und Geheimdienste so alles notieren, weiß man naturgemäß nie ganz genau. Aber auch außerhalb dieser Behörden sammelt der Staat aktuell – und es ist kein Ende in Sicht – sehr sensible Daten. In vielen Fällen kann man sich individuell dagegen kaum wehren, sondern nur als Teil einer größeren Protest- oder Boykottbewegung. Zumindest erscheint es ratsam, den Schatz an Daten, der einem später gefährlich werden könnte, nicht durch bloße Unbekümmertheit noch zusätzlich zu vergrößern. Glaub nicht, dass gegen dich nichts vorläge und du deshalb keine Probleme bekommen könntest. Wenn dir etwas angehängt werden soll, dann wird dir schon irgendetwas angehängt – notfalls „höchst verdächtiges Verhalten“ wie die Nutzung öffentlicher WLANs und verschlüsselter Kommunikationsmittel wie Whatsapp.

Das Trumpf-Argument ist aber: Weil es geht. Es gibt fast keine Gegenargumente. Nur eins: Man muss wenigstens einmal das Problem mangelnder Verschlüsselung als Problem wahrnehmen und sich das Minimum an Zeit nehmen, zu verstehen, was man dagegen tun kann, und das dann tun. Dauerhaft ist das kein messbarer Mehraufwand an Zeit, Geld, Hirnschmalz oder was auch immer.

Warum nicht einfach Signal

Neben OpenPGP gibt es ja noch andere Kryptographie-Systeme, zu denen man keine langen Anleitungen schreiben muss und die auch irgendwie moderner wirken. Warum also nicht einfach sowas verwenden?

Kurz gesagt: Es sind verschiedene Einsatzzwecke. Es gibt viel Kritik an OpenPGP. Wahrscheinlich findest du schnell solche Texte, wenn du dich mit dem Thema beschäftigst. Einige davon sind argumentativ verkürzt, andere basieren auf Falschaussagen, Missverständnissen, Fehlbenutzungen oder Vorlieben für bestimmte Programmiersprachen, einige sind einfach Verkaufsveranstaltungen für irgendein Alternativprodukt. Manche sind ganz lustig zu lesen und enthalten einige interessante Ideen. Hier, hier und hier sind Artikel, die ich der letztgenannten Kategorie zuordne.

Ein beliebtes Argument gegen OpenPGP ist sein Alter und das Alter von E-Mail. Aus dem hohen Alter wird geschlossen, dass es schlecht sein muss. Das ist zu kurz gedacht. Die Welt dreht sich weiter und mit ihr geht auch die Entwicklung von OpenPGP weiter. Neue Kryptographie-Algorithmen werden eingeführt, wenn alte als schwach erkannt werden. Neue Anwendungssoftware macht die Benutzung manchmal einfacher, manchmal komplizierter. OpenPGP mit Blick auf den Kalender generell abzulehnen, wäre Quatsch. Ein anderes beliebtes Argument gegen OpenPGP ist, dass es kompliziert sei. Es wird behauptet, dass Leute Mühe haben, es zu verstehen, und es deshalb nicht oder falsch benutzen. Man kann ein inhärent komplexes Konzept wie die Kryptographie aber nicht unterkomplex darstellen, ohne unzulässige Vereinfachungen vorzunehmen, die das System angreifbar machen. Das ist eine große Forschungsfrage in der Informatik, seit Jahrzehnten ungelöst: Bis jetzt gibt es nicht den vollautomatischen „Alles sicher machen“-Knopf, der einfach und ohne mitdenken zu müssen absolute Sicherheit herstellt. In Bezug auf OpenPGP versus andere Kryptographiesysteme läuft das letztlich auf eine Zielgruppendiskussion hinaus: Willst du weitreichende Sicherheitsgarantien haben, zu dem Preis, dass du ein bisschen Hirnschmalz investieren und mal eine längere Anleitung wie diese hier lesen musst? Dann nimm OpenPGP. Willst du einfach nur ein bisschen Kryptographie mitbenutzen, solange es nicht wehtut, ohne dass du wirklich Stress hättest, wenn du dann doch aus Versehen im Klartext kommunizieren würdest? Dann ist OpenPGP vielleicht wirklich zu kompliziert für deinen konkreten Anwendungsfall.

Was trendige Instant-Messaging-Systeme wie Signal und Threema von OpenPGP unterscheidet, ist in erster Linie, dass es sich um Plattformen, also zentralisierte Systeme, handelt. Das heißt, es gibt einen zentralen Dienst, zu dem man sich verbinden muss, um an dem Kommunikationssystem teilzunehmen, und man verwendet dafür das eine zur Verfügung stehende Programm, zu dem es keine Alternative gibt. Was der zentrale Server genau tut, ist prinzipbedingt nicht nachvollziehbar. Das ist in einem Überwachungsstaat durchaus ein großes Problem.

So ein einheitliches Ökosystem mit zentraler alles steuernder Instanz hat aus Betreiber*innen-Sicht den Vorteil, dass ein paar Zaubertricks möglich sind, die den Bedienkomfort und die Abhörsicherheit steigern können. Wenn man weiß, dass alle anderen Teilnehmer*innen die gleiche Software verwenden und dass sämtliche Kommunikation über denselben Server läuft, dann lassen sich Schritte der Kommunikationsanbahnung automatisieren, so dass man als Benutzer*in davon weniger mitbekommt. Wenn man nicht so ganz genau versteht, was da gerade passiert und inwiefern das jetzt wirklich verschlüsselt ist, kann das ein Einfallstor für opportunistische Sicherheit sein, also eine Sicherheit, die dann keine mehr ist, sobald man sie wirklich braucht (wenn sich zum Beispiel jemand Unbefugtes bemüht, sich in die Kommunikation einzuschalten, statt nur passiv zuzuhören). Wer den Server kontrolliert (als ihn betreibendes Unternehmen oder als Staat, in Ausnahmefällen auch als Hacker, wenn der Server schlecht gesichert ist), hat es besonders leicht, sich so in die Kommunikation einzuschalten.

Das heißt: Es kommt darauf an, was dein Anwendungsfall ist. Wenn du einfach nur mit Leuten kommunizieren willst und es dir nicht so schrecklich wichtig ist, dass das Verfahren dazu absolut wasserdicht ist, dann ließe sich sicherlich für ein System argumentieren, das in erster Linie wenige Fragen stellt und „einfach funktioniert“. Wenn du es aber gerne wirklich sicher hättest, dann würde ich von Systemen abraten, die aus dem Grund, dass dich das verunsichern könnte, versuchen, niemals irgendwelche Warnungen und Fehlermeldungen zu werfen, auch nicht wenn es angebracht wäre. Bei OpenPGP kannst du immer genau nachvollziehen, was gerade passiert und warum bzw. unter welchen Annahmen du darauf vertrauen kannst, dass das sicher ist. Wenn das Protokoll obskur ist und Aushandlungsschritte vor dir versteckt werden, dann sind manchmal überraschende Angriffe möglich. Und wenn es nicht möglich ist, die Infrastruktur selbst zu betreiben, und es keine alternativen Programme gibt, mit denen man diese Infrastruktur nutzen kann, dann ist das ein Umstand, der ebenfalls misstrauisch stimmen sollte.

Im Gegensatz zu den verschiedenen Instant-Messaging-Lösungen ist OpenPGP ja auch kein Kommunikationsprotokoll, sondern ein Datenformat. Das heißt, ob und wie du diese kryptographisch gesicherten Daten dann überträgst, ist eine ganz andere Frage. Du kannst mit OpenPGP auch Daten an dich selbst verschlüsseln, um zum Beispiel ein sicheres Backup zu haben. Du kannst einen mit OpenPGP signierten Text in ein Wiki schreiben. Über den Verteilungsweg der Daten bist du also völlig frei. Demgegenüber geht es bei Instant Messaging spezifisch darum, mit anderen Menschen zu kommunizieren, die dasselbe Instant-Messaging-Protokoll verwenden. Dadurch ist bei Instant Messaging zum Beispiel sog. forward secrecy möglich, was oft als Vorteil gegenüber OpenPGP gepriesen wird. (Dadurch bleiben verschlüsselte Nachrichten aus der Vergangenheit weiterhin geheim, selbst wenn der damals zur Entschlüsselung verwendete Schlüssel in falsche Hände gerät.) Das Verfahren basiert darauf, dass Nachrichten hin und her geschickt werden und nicht nur in eine Richtung. Deshalb lässt sich das bei OpenPGP nicht so direkt umsetzen. Das ist nicht unbedingt eine Schwäche von OpenPGP, sondern ein ganz anderes Konzept für andere Anwendungsfälle. Instant-Messaging-Nachrichten kannst du nicht an unbekannte Empfänger*innen verschicken (auf eine Website packen, in einem Buch abdrucken etc.), OpenPGP-Nachrichten schon.

Anonymität wird bei diesen Instant-Messaging-Systemen oft nicht mitbedacht. Bei Signal zum Beispiel identifizierst du dich dem System gegenüber mit deiner Telefonnummer, die sich nicht so problemlos ändern lässt wie zum Beispiel eine E-Mail-Adresse. Seit 2016 gibt es beim SIM-Kauf eine Ausweispflicht in Deutschland (in anderen Staaten ähnlich), so dass die Telefonnummer sowieso in der Regel hochgradigst persönlich identifizierend ist. Anonymität gegenüber Außenstehenden kann eine Rolle spielen bei Gruppenkommunikation, da unabhängig vom Inhalt der Nachrichten allein nur die Mitgliedschaft in einer bestimmten Kommunikationsgruppe schon eine hohe Aussagekraft hat. Wenn nur eins der Gruppenmitglieder ausgeforscht wird (bei sog. Smartphones trivial mit erprobten Systemen wie Cellebrite etc.), dann liegen die Telefonnummern und damit die staatlichen Meldedaten aller Gruppenmitglieder unmittelbar offen.

Ein föderiertes (also nicht zentralisiertes) Instant-Messaging-Protokoll, für das es haufenweise Anwendungssoftware gibt, ist Matrix. Das ist auf jeden Fall empfehlenswert. Es gibt eine gute, knackige Anleitung dafür.

Ist E-Mail nicht eh schon verschlüsselt

Vielleicht bist du irritiert über die Werbung eines E-Mail-Providers, die sagt, dass E-Mail-Nachrichten zumindest bei diesem Provider immer nur verschlüsselt übertragen werden. Inwiefern brauchst du dann noch zusätzlich OpenPGP?

Tatsächlich werden E-Mail-Nachrichten mittlerweile fast immer verschlüsselt übertragen und oft findet auch eine Überprüfung statt, ob der absendende E-Mail-Server eigentlich berechtigt ist, Nachrichten von dieser E-Mail-Adresse abzuschicken. Beides ersetzt OpenPGP nicht, weil der Geltungsbereich dieser Verfahren ganz anders ist: Es geht dabei um die direkte Kommunikation zwischen je zwei Maschinen. Wenn von Maschine zu Maschine die Kommunikation verschlüsselt (und authentifiziert) ist, beide Maschinen aber den Inhalt der Kommunikation kennen, dann spricht man von einer Transportwegverschlüsselung. Das dazu verwendete Protokoll heißt TLS (Transport Layer Security). Es ist schwer, heute noch E-Mail-Nachrichten zu finden, die nicht über TLS verschickt werden. Zwischen den E-Mail-Servern wird TLS gesprochen. Wenn du eine E-Mail-Nachricht an jemanden abschickst, wird zwischen deinem Rechner und deinem E-Mail-Server ebenfalls TLS gesprochen. Wenn du eine E-Mail-Nachricht für dich abholst, ebenfalls.

Das ist alles wunderbar und wann immer die Frage gestellt wird, ob für eine Verbindung TLS genutzt werden soll, sollte man zurückfragen, warum das bitte immer noch eine Frage ist, und auf die Eingangsfrage selbstverständlich Ja sagen. TLS stellt aber auf gar keinen Fall sicher, dass es nur zwei Personen gibt, die den Inhalt der Nachricht kennen, nämlich die Absender*in und die Empfänger*in; und auch nicht, dass die Empfänger*in mit Sicherheit feststellen kann, dass diese Nachricht genau so von der Absender*in verfasst wurde und nicht von jemand anderem.

Der entscheidende Unterschied ist kryptographische Sicherheit, die von Ende zu Ende gilt (unabhängig davon, welche Zwischenstationen die Nachricht genommen hat und wie bösartig die Leute sind, die unterwegs Zugriff auf sie haben) versus die auf dem Transportweg gilt (also von Zwischenstation zu Zwischenstation, wobei allen Zwischenstationen vollständig vertraut wird).

Vertrauenmüssen ist immer blöd und sollte so weit wie möglich reduziert werden. Blöd ist vor allem, wenn du Instanzen vertrauen musst, die du gar nicht kennst und die du dir nicht selbst ausgesucht hast. Der E-Mail-Provider deiner Kommunikationspartner*in zum Beispiel, und dessen Rechenzentrum. Oder der gammlige E-Mail-Client deiner Kommunikationspartner*in.

Es gibt auch E-Mail-Provider, die mit E-Mail-Verschlüsselung werben und damit nicht das oben beschriebene TLS meinen, sondern OpenPGP. Wenn du so einem E-Mail-Provider begegnest, musst du genau gucken, inwiefern das ein valides Verkaufsargument ist. OpenPGP kannst du nämlich, weil es ein Ende-zu-Ende-Verfahren ist, unabhängig vom E-Mail-Provider benutzen. Inwiefern brauchst du dann also einen E-Mail-Provider, der OpenPGP in irgendeiner Weise „unterstützt“? Dafür gibt es schlechte und gute Gründe, die du hoffentlich im Laufe der Anleitung zu unterscheiden lernen wirst. Jetzt musst du das noch nicht verstehen: Ein schlechter Grund wäre zum Beispiel, dass der E-Mail-Provider für dich ein Schlüsselpaar erzeugt und ausgehende Nachrichten für dich signiert, ohne dass du immer dein Mantra eingeben musst (dazu später mehr). Ein guter Grund wäre zum Beispiel, dass der E-Mail-Provider einen WKD-Server betreibt, der die Schlüsselverteilung vereinfacht (auch dazu später mehr).

Warum noch eine Anleitung

Diesen Abschnitt kannst du überspringen, wenn du schnell loslegen willst. Es geht hier darum, was diese Anleitung von anderen mit ähnlichem Inhalt unterscheidet.

Es gibt ganz viele Anleitungen im Internet zu „E-Mail-Verschlüsselung“. Wer nach diesem Stichwort sucht, wird fündig. Eine Anleitung wie diese hier gibt es aber noch nicht oder sie ist ziemlich schwer zu finden. Die Alleinstellungsmerkmale sind:

Diese Anleitung geht davon aus, dass du dein Hirn hochgefahren hast und etwas lernen willst; dass es dir zu blöd wäre, unverstanden irgendwelche Häkchen zu klicken und das Verständnis der Materie dahinter den Profis zu überlassen.
Diese Anleitung ist keine Sammlung von Wikipedia-Artikeln und Handbüchern von Verschlüsselungssoftware. Du wirst Schritt für Schritt zum Ziel geführt.
Diese Anleitung bricht mit dem Mythos, dass Kryptographie so furchtbar kompliziert wäre, dass man Mathe studiert haben muss, um sie überhaupt benutzen zu können. Kryptographie ist nicht nur für Nerds. Diese Anleitung macht sie normalen Leuten zugänglich.
Diese Anleitung bricht auch mit dem Mythos, dass Kryptographie wegautomatisiert werden könnte und die Programme das schon irgendwie von alleine machen würden, ohne dass man selber irgendwas davon verstanden haben muss. Du wirst befähigt, zu verstehen, was du da tust.
Diese Anleitung sagt klar, welche Alternativen es in jedem Schritt jeweils gibt, empfiehlt bestimmte Alternativen und begründet die Empfehlung.
In dieser Anleitung geht es um OpenPGP. Das ist nicht gleichbedeutend mit E-Mail-Verschlüsselung. E-Mail-Verschlüsselung umfasst mehr als OpenPGP und OpenPGP umfasst mehr als E-Mail-Verschlüsselung. Wenn es dir darum geht, E-Mail-Nachrichten zu verschlüsseln, dann bist du hier trotzdem richtig, denn auch das lernst du mit dieser Anleitung.

Was du brauchst

Du brauchst als erstes einen Computer. Das ist ein rechnendes Gerät, auf dem Programme laufen können. Das Format ist egal. Tablet, Smartphone, ISS-Bordcomputer oder Geldautomat geht. Für den Anfang ist es einfacher, wenn du dir einen Laptop oder Desktop-Rechner hernimmst: einen Computer mit Tastatur, den du voll unter deiner Kontrolle hast (also einen, auf dem du auch beliebige neue Software installieren kannst zum Beispiel – das trifft oft auf Smartphones nicht zu).

Internetzugang ist hilfreich, um die Software zu bekommen, die du im Laufe dieser Anleitung installierst. Für den Nachrichtenaustausch später kann Internet eventuell auch nicht schaden.

Auf dem Computer läuft ein Betriebssystem. Das ist bei den eben empfohlenen Laptops oder Desktop-Rechnern oft eine Art von Linux, Windows oder MacOS, wenn es ein Apple-Computer ist. Es gibt viele andere Betriebssysteme für Laptop- und Desktop-Rechner. Aber wenn du ein anderes als die drei genannten hast, dann erfährst du in diesem Abschnitt hier eh nichts Neues und kannst gleich zum Abschnitt „Kommandozeile“ springen. Tablets, Smartphones, ISS-Bordcomputer und Geldautomaten werden erstmal nicht weiter betrachtet; nur am Ende im Abschnitt „Lobotomierte Computer“ kurz.

An dieser Stelle ist eine Frage relevant: Benutzt du Windows oder irgendein anderes Betriebssystem? Wenn du Windows benutzt, dann ist der nachfolgende Abschnitt „Betriebssystem“ relevant für dich. Wenn nicht, dann kannst du den überspringen und gleich bei „Kommandozeile“ weiterlesen.

Betriebssystem

Es gibt zwei Arten von Betriebssystemen: Windows und alle anderen. Also bezogen auf Laptops und Desktop-Rechner und natürlich abgesehen von super-exotischen Ausnahmen und historischen Fundstücken auf Omas Dachboden. Wenn du Windows benutzt, dann lies bitte diesen Abschnitt, weil Windows speziell ist.

Die Philosophie von Windows verkompliziert die Benutzung von Software, bei der Sicherheit ein wichtiges Feature ist. Wenn du unter Windows ein Programm installieren willst, dann gehst du wohl auf die Website des Programms, lädst dir von da ein Installationsprogramm runter, führst das aus und fertig. Vielleicht googelst du sogar vorher noch die angebliche Website des Programms (oder eines anderen Programms, das genau so genannt wurde, um von dir anstelle des richtigen gefunden zu werden). Die Probleme dabei sind: Wie stellst du denn fest, dass du das richtige Installationsprogramm runtergeladen hast und dir dabei niemand was untergeschoben hat, womit du zum Beispiel ausspioniert wirst? Es werden ja mit der Zeit Sicherheitsprobleme in der Software bekannt, die du installiert hast, und neue, korrigierte Versionen davon werden veröffentlicht. Wie bekommst du denn die Updates? Gehst du wirklich einmal die Woche auf die Website von jedem Programm, das du installiert hast, um zu gucken, ob du noch die aktuelle Version hast? Wahrscheinlich nicht. Und wenn doch, dann hat eine Person, die dir eine gegen deine Interessen manipulierte Version des Programms unterjubeln will, jede Woche neu die Gelegenheit dazu. Manche Programme, die eine graphische Oberfläche haben, haben auch einen Update-Mechanismus drin. Die gucken selber im Internet nach neuen Versionen ihrer selbst und sagen dann Bescheid. Das setzt voraus, dass man das Programm mit der Update-Routine regelmäßig ausführt, dass es Internetzugriff hat und dass nicht der Update-Mechanismus selbst fehlerhaft ist.

Andere Betriebssysteme verwalten die installierte Software zentral. Es gibt einen Ort, an den du gehst, um etwas zu installieren. Dabei kann dir egal sein, ob das Programm eine Website hat, und wenn ja, wo sie zu finden ist. Es ist ein Arbeitsschritt, zentral für jede installierte Software nach Updates suchen zu lassen und die eventuellen Updates zu installieren. Das macht alles viel einfacher und dein Gesamtsystem gleichzeitig sicherer.

Die Firma, die Windows vertreibt, Microsoft, ist ein kommerzielles Unternehmen, das im Daten-sammeln-Business ist. Das ist bei Android (Google), MacOS (Apple) und anderen kommerziell vertriebenen Betriebssystemen nicht anders. In allen diesen Fällen hast du weniger die Kontrolle über deinen Rechner, weil darauf Software läuft, die extra vor dir geheim gehalten wird. Die bessere Alternative ist ein freies Betriebssystem, das von einer Freiwilligen-Gemeinschaft gepflegt wird, die vor dir keine Geheimnisse hat. In dem Fall wirst du wahrscheinlich auch nicht ganz exakt verstehen, wie dieses Betriebssystem in allen Einzelheiten funktioniert, aber zumindest lohnt es sich für die an der Weiterentwicklung beteiligten Freiwilligen nicht, dein Nutzungsprofil abzufangen und für kommerzielle Zwecke auszuwerten. Auch für nicht-kommerzielle Zwecke (z. B. durch staatliche Akteure) können deine Daten dann schlecht verwendet werden, wenn dein Betriebssystem sie gar nicht erst veruntreut. Freie Software bietet keine Garantie für Sicherheit, ist aber eine Voraussetzung dafür.

Wenn du eh schon gelegentlich mal darüber nachgedacht hast, von Windows weg auf ein freies Betriebssystem zu wechseln, dann ist jetzt – bevor du diese Anleitung weiter verfolgst – der perfekte Zeitpunkt, dieses Vorhaben mal konkret anzugehen. Wenn nicht, dann ist jetzt der beste Zeitpunkt, um das erste Mal darüber nachzudenken. Über die Wahl eines Betriebssystems zu philosophieren und zu erklären, wie man das dann installieren würde, würde doch ziemlich weit vom eigentlichen Thema dieser Anleitung weg führen. Dazu kannst du mal jemanden fragen oder woanders weiterlesen. Nur so viel: Viele Leute benutzen eine Art von Linux. Zur Beantwortung der Frage, welches Linux das Passendste für dich sei, gibt es auch Informationsquellen.

Wenn du meinst, dass Windows einfacher zu bedienen sei, dann muss ich dich enttäuschen. Wenn dein Anwendungsfall Zocken, Powerpoint-Spreadsheets und der Konsum von Werbung ist, dann ist es vielleicht einfach zu bedienen. Wenn dir Sicherheit etwas bedeutet, dann ist das Gegenteil zutreffend: Das Projekt SiSyPHuS vom Bundesamt für Sicherheit in der Informationstechnik, das sich damit befasst, wie das unsichere Betriebssystem Windows (in dem Fall in der Version 10) ein bisschen sicherer gemacht werden kann, hat seinen Namen nicht umsonst.

Kommandozeile

Wenn du es gewohnt bist, mit der Software deines Computers, also insbesondere mit deinem Betriebssystem, in einer solchen Weise zu interagieren, dass dir eine Fläche von Möglichkeiten angeboten wird, aus denen du (zum Beispiel per Mausklick) eine auswählst, woraufhin die dargestellte Fläche an Möglichkeiten sich verändert, dann benutzt du Computer wohl so, wie sie die meisten Menschen benutzen. Wenn du aber über die reine Benutzung hinausgehend verstehen möchtest, was vor sich geht, und dir von deiner Software nicht sagen lassen willst, was deine nächsten Interaktionsmöglichkeiten sind, dann wirst du vielleicht früher oder später in einer direkteren, unverfälschteren, nicht-reduzierten Weise mit deinem Betriebssystem reden wollen.

Bitte lies diesen Abschnitt, wenn du nicht weißt, wie du auf deinem Rechner zu einer Kommandozeile kommst und wie du die dann bedienst.

Das Mittel dazu ist die Kommandozeile, auf der du die Möglichkeit hast, jeden Befehl zu geben, den der Computer ausführen kann. Wenn du nicht so richtig weißt, was du tust, wird das erstmal komplizierter aussehen als eine klickbare graphische Oberfläche mit einem reduzierten Möglichkeitsraum. Aber wenn du weißt, was du tun willst, dann ist das auf jeden Fall einfacher, weil du den dazu nötigen Befehl kennst und direkt eingeben kannst, statt die entsprechende Funktionalität erst im 99. Untermenü suchen zu müssen. Die Kommandozeile ist barriereärmer als graphische Interfaces, weil die Schriftart und -größe und Farbe anpassbar ist und sie mit Screenreader und Braillezeile gut bedient werden kann.

Deshalb wird hier die Kommandozeile erklärt. Und auch aus dem Grund, dass es auf der Kommandozeile eine stärkere Einheitlichkeit der verschiedenen Systeme gibt (weitgehend unabhängig vom Betriebssystem, der eingestellten Sprache usw.). Für so eine Anleitung ist das einfach praktikabler. Und auch aus dem Grund, dass die Befehle auf der Kommandozeile dazu neigen, auch in 25 Jahren noch fast genau so zu funktionieren, während der gleiches auslösende Knopf in der graphischen Schnittstelle wahrscheinlich schon nach 5 Jahren umbenannt wurde, in ein anderes Untermenü verschwand; oder die ganze graphische Software wird nicht mehr weiterentwickelt.

Bitte versuch einmal, deine eventuell vorhandenen Ängste gegenüber Texteingabe kurz in den Griff zu kriegen und der Anleitung zu folgen. Du wirst sehen, dass es so schlimm doch gar nicht ist.

Der allerschwierigste Schritt ist der erste: Wahrscheinlich ist die Oberfläche, mit der dich dein Betriebssystem begrüßt, eine, die nicht zur Eingabe textförmiger Befehle geeignet ist. Wie kommst du jetzt von da zu einer solchen Eingabemöglichkeit? Das ist je nach Betriebssystem und Betriebssystemversion und Betriebssystem-Konfiguration unterschiedlich. Um das Ziel schon mal zu definieren: Ein Fenster mit einer Kommandozeile könnte so aussehen: $Anwendungsfenster unter Microsoft Windows, Titel „Command Prompt“, mit schwarzem Hintergrund und weißer dicktengleicher Schrift: Versionsangabe zu Microsoft Windows, darunter „C:\Users\Sarah>“$ Oder so: Die Farben können anders sein. Es kann anderer Text drin stehen. Aber so ungefähr. Probier einmal die folgende Liste an Möglichkeiten durch, um zu so einer Kommandozeile zu kommen, bis du eine Möglichkeit gefunden hast, die dich zum Ziel führt:

Wenn du ein Linux-System verwendest, dann drück die Tastenkombination Strg-Alt-T. Das heißt, du hältst Strg und Alt gedrückt, drückst dann einmal kurz T und lässt das wieder los und lässt dann Strg und Alt los. Strg ist die deutsche Beschriftung. Die Taste heißt unter anderem auf schweizerisch und englisch beschrifteten Tastaturen Ctrl.
Wenn du Windows verwendest und auf deiner Tastatur eine Windows-Taste ist (links unten zwischen Strg und Alt, dann drück die Tastenkombination Win-R, um ein kleines Fensterchen anzeigen zu lassen, in dem du einen einzelnen Befehl eingeben kannst. Hier gibst du
```
cmd
```
ein und drückst die Eingabetaste (Enter oder ↵).
Wenn du Windows verwendest und keine Windows-Taste hast, dann kannst du das kleine Fensterchen, in dem du cmd Enter eingeben sollst, auch erreichen, indem du auf das Startmenü klickst (der Knopf mit dem Windows-Logo) und dort dann auf „Ausführen“ oder „Run“ klickst. Je nach Windows-Version und Konfiguration gibt es diesen Menüpunkt nicht. Dann gibt es vielleicht im Startmenü direkt eine Eingabezeile wie auf diesem Bild oben: und es wird wahrscheinlich auch funktionieren, wenn du dort cmd Enter eingibst. Wenn dann noch nicht die Kommandozeile erscheint, dann erscheint aber wahrscheinlich unter der Eingabezeile ein „Eingabeaufforderung“ oder „Command Prompt“ benannter Knopf mit einem seltsamen schwarzen Zeichen, das du anklicken kannst: $Programmsymbol der Eingabeaufforderung cmd.exe unter Microsoft Windows: weiße Zeichen „C:\_“ auf schwarzem Hintergrund$
Wenn du MacOS verwendest, dann drück die Tastenkombination Cmd-Leertaste, wobei Cmd die Befehlstaste ist: die mit dem Apfel und / oder der Schleife, links neben der Leertaste. In dem erscheinenden Suchfenster gibst du das Wort terminal ein und klickst mit der Maus doppelt auf das Suchergebnis.
Wenn du bis hierhin noch nicht zum Ziel gekommen bist, gibt es noch andere Möglichkeiten: Wenn du am oberen oder unteren Bildschirmrand eine Leiste hast, in der aktuell laufende und / oder ausführbare Programme aufgelistet sind und auch ein Anwendungsmenü (auch manchmal Startmenü genannt) existiert, über das weitere ausführbare Programme ausgewählt werden können, dann klick mal auf das Anwendungsmenü und guck da, ob du zum Beispiel unter einer Kategorie wie „System“ oder „Zubehör“ einen Menüpunkt findest, der ein so ähnlich aussehendes Symbol hat: oder: und zum Beispiel „Terminal“, „Eingabeaufforderung“, „Konsole“ oder „Kommandozeile“ heißt.
Wenn auch das nicht hilft, gibt es noch eine unschönere Variante, mit der du vielleicht erstmal weiterkommst, bis du eine schönere für dich gefunden hast: Drück die Tastenkombination Strg-Alt-F2, um zu einer Kommandozeile zu kommen, die allerdings bildschirmfüllend ist. Um von dort wieder zurück zu deiner graphischen Oberfläche zu kommen, drücke Alt-F9 oder, wenn das nicht klappt, Alt in Kombination mit einer anderen hohen F-Taste. Auf der Kommandozeile, die du auf diese letzte Weise erhältst, musst du dich erst anmelden. Hoffentlich kennst du deinen Loginnamen und dein Passwort.

Wenn du jetzt also eine Kommandozeile hast, dann kannst du deinem Betriebssystem jeden Befehl geben, den es versteht, und es wird ihn ausführen. Wenn du Befehle eingibst, ist es wichtig, dass du genau darauf achtest, sie richtig einzugeben. Es kann auf jedes einzelne Leerzeichen ankommen oder darauf, den richtigen Schrägstrich – / oder \ – zu verwenden usw.

Wenn du dich vertippt hast und nicht mehr weißt, wie du jetzt wieder zurück zu einer sauberen Kommandozeile kommst, kannst du die Tastenkombination Strg-C drücken, um die aktuelle Aktion abzubrechen und eine neue Zeile zu beginnen. Probier mal aus.

Auf einer neuen Zeile gib jetzt folgendes ein:

echo a

Also das Wort „echo“ in Kleinbuchstaben, gefolgt von einem Leerzeichen, gefolgt vom Buchstaben „a“, gefolgt von der Eingabetaste (Enter oder ↵). Alle Befehle werden mit einem Zeilenumbruch bzw. der Enter-Taste abgeschlossen. Das wird ab jetzt in dieser Anleitung nicht mehr erwähnt.

Sobald du den Befehl mit Enter abschließt, erscheint unter der Zeile, die du selbst eingegeben hast, eine Zeile mit dem Buchstaben a und darunter dann die nächste Kommandozeile, auf der du wieder was eingeben kannst. Der Befehl echo gibt also das aus, was du dahinter eingibst. Du kannst auch „echo“, Leerzeichen und dann einen anderen Text eingeben und mit Enter abschließen. Probier mal aus.

Allgemein ist das erste Wort (also alles vor dem ersten Leerzeichen) auf einer Zeile der Befehl und danach stehen mit Leerzeichen voneinander getrennt sogenannte Argumente, die beeinflussen, was der Befehl genau tut. Einen Befehl kann man sich auch wie einen Programmaufruf vorstellen. Der Befehl ist also der Name des Programms, das du ausführst, und die Argumente bestimmen den Programmablauf.

Ein Befehl, den du oft brauchst, ist cd für change directory. Wenn du den ohne Argument eingibst – also einfach

cd

–, dann wechselst du in dein sogenanntes Home-Verzeichnis, also das Verzeichnis für deine persönlichen Daten. Außer du benutzt Windows: Dann wechselt der Befehl ohne Argumente nirgendwohin, sondern gibt stattdessen das aktuelle Verzeichnis aus. Wenn du hinter cd mit Leerzeichen abgetrennt ein Verzeichnis angibst, das tatsächlich existiert, dann wechselst du dahin.

Was es überhaupt so gibt (zum Beispiel Verzeichnisse, in die du wechseln kannst), kannst du mit dem Befehl ls auflisten lassen. Aber nicht unter Windows: Da gibt es diesen Befehl nicht, sondern der heißt da stattdessen dir. Außer allem, was da in der Auflistung steht, gibt es auch noch das Verzeichnis namens .. (also zwei Punkte). Das ist das übergeordnete Verzeichnis. Mit dem Befehl

cd ..

gehst du also aus dem aktuellen Verzeichnis raus und bist dann in dem eine Ebene drüber.

Das soll für den Moment als Einführung in die Kommandozeile erstmal reichen.

GnuPG

OpenPGP ist ein offener Standard für ein kryptographisches Datenformat. Es gibt keine Beschränkung, mit welcher Software du dieses Datenformat einliest bzw. erzeugst, solange die Software so weit standardkonform ist, dass du deine Daten mit anderen Leuten austauschen kannst. Das einzige mir bekannte Programm, das OpenPGP umfassend implementiert und gut funktioniert, ist GnuPG. Fast die ganze Welt benutzt GnuPG. Deshalb ist es ziemlich gut dokumentiert und man bekommt leicht Hilfe bei allerlei Problemen. GnuPG war von Anfang an freie Software und wird seit Jahrzehnten aktiv weiterentwickelt. Es ist also auch ziemlich aktuell im Sinne von neueren Kryptographie-Algorithmen als auch sicher in der Hinsicht, dass nicht oft schlimme Sicherheitslücken entdeckt werden. (Wenn niemals Sicherheitsprobleme bekannt werden würden, dann würde das eher darauf hindeuten, dass niemand welche gesucht hat. Also ist es gut, dass selten doch mal welche gefunden werden.)

In dieser Anleitung wird es hauptsächlich um die Bedienung von GnuPG auf der Kommandozeile gehen. Das ist die Grundlage, um dann auch verschiedene graphische Oberflächen gewinnbringend nutzen zu können, die hintenrum auf GnuPG aufsetzen. Diverse E-Mail-Clients und Schlüsselverwaltungswerkzeuge setzen für ihre OpenPGP-Funktionalität voraus, dass GnuPG installiert ist, und benutzen einfach die Schlüsseldatenbank von GnuPG. Deshalb halte ich es für eine gute Idee, erstmal die Grundlage zu verstehen, also GnuPG bedienen zu können. Der Schritt hin zu einer Software, die dir diese Bedienung für die tägliche Benutzung erleichtert, ist dann eher unspektakulär. Auch das Thema E-Mail-Clients wird in dieser Anleitung später kurz angerissen.

Als erstes werden wir gucken, ob du GnuPG vielleicht schon hast – das kann durchaus sein –, und es sonst installieren. Um zu gucken, ob du eine GnuPG-Installation hast, gib auf der Kommandozeile folgenden Befehl ein:

gpg --version

Wenn dabei nur eine Fehlermeldung kommt, die so ungefähr besagt, dass der Befehl oder das Programm gpg nicht gefunden wurde, dann hast du GnuPG möglicherweise nicht installiert. In dem Fall kannst du mal stattdessen folgenden Befehl probieren:

gpg2 --version

Wenn wieder die gleiche Fehlermeldung kommt (nur dass diesmal gpg2 nicht gefunden wurde), dann hast du wohl tatsächlich noch nicht GnuPG installiert. Wenn du es aber installiert hast, dann kommt eine etwas längere Ausgabe, die so ungefähr aussehen kann:

gpg (GnuPG) 2.3.8
libgcrypt 1.9.4
Copyright (C) 2021 Free Software Foundation, Inc.
License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /home/schnuffelchen/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
AEAD: EAX, OCB
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

Wichtig ist, dass in der ersten Zeile der Ausgabe die erste Zahl in der GnuPG-Versionsnummer (in diesem Fall 2.3.8) eine 2 ist. Wenn es eine 1 ist, dann hast du GnuPG nur in einer abgespeckten Version und musst die richtige Version noch installieren.

Wenn du noch nicht so eine Ausgabe bekommst und GnuPG erst installieren musst, dann lies hier weiter. Wenn du GnuPG schon hast, dann kannst du diese Passage überspringen.

Wenn du ein freies System verwendest, hast du sicherlich eine Paketverwaltung. Das ist die zentrale Stelle in deinem Betriebssystem, an der du neue Software findest, die du installieren willst, und auch vorhandene Software auf den neuesten Stand bringen bzw. deinstallieren kannst. Vielleicht hast du dafür eine graphische Oberfläche, die du im Anwendungsmenü unter einem Namen wie „Softwareverwaltung“ oder so ähnlich findest. Du kannst sie auch über die Kommandozeile bedienen. Wie das genau funktioniert, hängt aber davon ab, welche Paketverwaltung du genau hast, was wiederum davon abhängt, welches Betriebssystem du verwendest.

Wenn du irgendein Linux benutzt, dann gibt es so eine Paketverwaltung mit ziemlicher Sicherheit. Wenn du nicht weißt, wie die zu bedienen ist, dann lies bitte in der Dokumentation nach. Das würde zu weit führen, hier sämtliche Varianten aufzulisten. Wie man das System aktuell hält (Paketdatenbank updaten, installierte Pakete upgraden) und neue Pakete installiert, dürfte ganz am Anfang der Beschreibung deiner Linux-Distribution stehen. Ein GnuPG-Paket findest du unter dem Namen „gnupg2“ oder „gnupg“ oder „gpg2“ oder „gpg“.

Wenn du Windows benutzt, dann hast du anscheinend Freude daran, Schmerzen zu erleiden. Windows und IT-Sicherheit sind gegensätzliche Konzepte. GnuPG ist deshalb unter Windows nicht sinnvoll zu betreiben. Wenn du warum auch immer dennoch Windows benutzen möchtest, dann ist es wichtig, dass du dein System so weit wie möglich sicher und aktuell hältst. Also:

Bitte benutze nur eine von Microsoft noch mit Sicherheitsupdates versorgte Windows-Version.
Bitte führe zirka einmal die Woche das Windows-Update aus, um bekannte Sicherheitslücken im Betriebssystem zu schließen.
Bitte hab nur solche Software installiert, der du hinreichend vertraust und die du wirklich brauchst.
Bitte halte alle installierte Software auf dem neuesten Stand, indem du zirka einmal die Woche auf Updates prüfst.
Bitte googel nicht nach Software, sondern bediene dich vertrauenswürdiger Quellen.
Bitte führe keine Programme aus, die du von fadenscheinigen Websites runtergeladen hast, schon gar nicht mit Administrator-Rechten.

Die ersten drei Punkte musst du selber hinkriegen. Bei den letzten drei Punkten hilft dir das Kommandozeilenwerkzeug winget, das ab Windows-Version 10 in der Basisinstallation enthalten ist. Gib auf der Kommandozeile einfach den Befehl winget ein – ohne Argumente –, um angezeigt zu bekommen, wie winget funktioniert. Wenn da die Fehlermeldung kommt, dass der Befehl nicht gefunden wurde, dann hast du winget nicht.

Du kannst nun sämtliche Software sauber per winget installieren. Wenn du das fiktive Programm „Superprogramm“ installieren willst, kannst du erstmal gucken, ob das in der Winget-Datenbank vorhanden ist mit diesem Befehl:

winget search superprogramm

Falls das „Superprogramm“ in der Winget-Datenbank gefunden wird, wird dessen ID ausgegeben und du kannst es mithilfe der ID installieren. (Beim ersten Aufruf von winget musst du noch bestätigen, dass das Programm den Microsoft-Server anfragen darf.) GnuPG installierst du zum Beispiel so:

winget install gnupg.gnupg

Um alle deine mit winget installierte Software automatisch auf Upgrades prüfen zu lassen und dein System auf den neuesten Stand zu bringen, führe bitte einmal die Woche den Upgrade-Befehl aus:

winget upgrade --all

Um ein halbwegs sicheres System zu betreiben, ist es sinnvoll, sämtliche Software per winget zu installieren; also auch E-Mail-Client, Browser, Officepaket, Mediaplayer und was du sonst so brauchst. Dann wird es auch immer was zu upgraden geben.

Nachdem du jetzt also – egal, unter welchem Betriebssystem – GnuPG installiert hast, solltest du mit

gpg --version

oder

gpg2 --version

eine ausführliche Ausgabe wie oben erhalten. Wenn nicht, dann kann es daran liegen, dass das GnuPG-Programm auf deiner aktuell laufenden Kommandozeile noch nicht gefunden wird und du eine neue Kommandozeile aufrufen musst. Die bisherige Kommandozeile kannst du beenden (indem du das Fenster schließt oder exit eingibst oder Strg-D drückst). Auf einer frischen Kommandozeile sollte das GnuPG-Programm dann auffindbar und ausführbar sein.

Im Folgenden gehe ich davon aus, dass dein GnuPG-Programm unter dem Namen gpg ausführbar ist. Wenn das bei dir konkret anders ist, dann kannst du die Befehlszeilen, die mit gpg anfangen, selber geeignet anpassen.

OpenPGP-Schlüssel

OpenPGP ist ein kryptographisches Protokoll, das den gesicherten Datenaustausch mit Hilfe von sog. asymmetrischer Kryptographie (oder Public-Key-Kryptographie) ermöglicht. Um das gewinnbringend benutzen zu können und nicht über Fallstricke zu stolpern, solltest du zumindest ein grobes Verständnis davon haben, was sich hinter diesen Wörtern verbirgt. Wenn du also weißt, was der Unterschied zwischen öffentlichem und geheimem Schlüssel ist, welchen man jeweils braucht, um zu verschlüsseln, zu entschlüsseln, zu signieren und zu verifizieren, inwiefern du Schlüsseln anderer Leute vertrauen kannst und was ein Fingerabdruck ist, dann kannst du diese Passage überspringen. Wenn du dir bei einer der vorgenannten Sachen aber noch nicht so ganz sicher bist, dann lies bitte besser weiter, damit wir wirklich auf demselben Stand sind, was die absoluten Grundlagen angeht.

Asymmetrische Kryptographie

Klassischerweise kannst du digital vorliegende Daten verschlüsseln, indem du ein öffentlich bekanntes und gut erforschtes Verschlüsselungsverfahren (sog. Algorithmus) wählst, ein Programm hernimmst, das diesen Algorithmus ausführt, dir ein superstreng geheimes Passwort überlegst und das Programm mit den Daten und dem Passwort fütterst. Dabei fällt dann der nicht lesbare Geheimtext raus. Dasselbe Programm kann wahrscheinlich auch die Umkehrung des Verschlüsselungsalgorithmus ausführen, so dass du bei Eingabe des Geheimtextes und des korrekten superstreng geheimen Passwortes wieder den Klartext erhältst, den du eingangs eingegeben hattest.

So weit übersichtlich. Die Probleme fangen jetzt an, wenn du die Daten nicht nur für dich selber verschlüsseln willst (Dein Backup könntest du so verschlüsseln.), sondern mit anderen Leuten diese Daten austauschen willst, auch genannt kommunizieren. Da stellt sich die Frage, wie das Passwort vorher abhörsicher ausgetauscht wird, damit die eine Person das entschlüsseln kann, was die andere vorher verschlüsselt hat.

Solche Probleme löst die asymmetrische Kryptographie, die so heißt, weil die Verschlüsselung und Entschlüsselung nicht mit demselben Passwort stattfindet (symmetrisch), sondern dazu zwei verschiedene Passwörter verwendet werden: Was mit dem Verschlüsselungspasswort verschlüsselt wurde, kann nur mit dem dazu passenden Entschlüsselungspasswort entschlüsselt werden. Aber wir nennen das ab jetzt nicht mehr Passwort, sondern Schlüssel, weil die Schlüssel sehr große sehr zufällig aussehende Zahlen sind, die man nicht per Hand eingibt, sondern als Datei gespeichert hat, weil man sich die auf gar keinen Fall merken kann. Das Thema Passwörter kommt später auch nochmal, aber die Ver- und Entschlüsselung selber findet mit Schlüsseln statt, nicht mit Passwörtern.

Die mathematischen Details sind nicht ganz so wichtig. Die kannst du dir durchlesen, wenn sie dich interessieren. Nur ganz grob, damit du eine Vorstellung davon hast, wie das funktionieren kann: Alles im Computer, alles Digitale, lässt sich ja als Zahlen repräsentieren. Daher die Namen Computer (Rechner*in) und digital (mit den Fingern abzählbar). Also der Klartext ist eine (sehr große) Zahl, der Geheimtext auch, der Verschlüsselungsschlüssel auch und der Entschlüsselungsschlüssel auch. Der Algorithmus, der die Verschlüsselung und Entschlüsselung ausführt, ist im Prinzip eine etwas umfangreichere mathematische Berechnung auf ganz normalen (positiven ganzen) Zahlen.

Zu stark vereinfacht könnte man sich das so vorstellen, dass der Algorithmus einfach die Multiplikation ist. Dazu musst du einmal kurz annehmen, dass du die Multiplikation nicht umkehren könntest; dass also die Division unbekannt oder sehr schwer ausführbar wäre. Der Verschlüsselungsschlüssel einer Person könnte zum Beispiel die Zahl 4 sein. Der dazugehörige Entschlüsselungsschlüssel dieser Person wäre dann die Zahl 0,25. Wenn ich die Klartext-Nachricht durch die Zahl 1312 repräsentiere, dann kann ich die Nachricht an diese Person mit dem Verschlüsselungsschlüssel 4 verschlüsseln, indem ich den Algorithmus (also die Multiplikation) auf die Klartextnachricht (also die 1312) und den Verschlüsselungsschlüssel (also die 4) anwende. Das Ergebnis ist dann die Zahl, die dem Geheimtext entspricht, nämlich 1312 · 4 = 5248. Nur die Person, die im Besitz des zur 4 passenden Entschlüsselungsschlüssels (0,25) ist, kann nun den Algorithmus auf die Geheimtextnachricht (5248) und den Entschlüsselungsschlüssel (0,25) anwenden und erhält daraus den Klartext: 5248 · 0,25 = 1312. Bedenke nochmal, dass wir hier annehmen wollen, dass die Division nicht ausführbar ist. Also nur mit dem Geheimtext (5248) und dem Verschlüsselungsschlüssel (4) kommt man nicht auf den Klartext. Du kannst dir denken, dass in der Praxis nicht einfach die Multiplikation verwendet wird, weil quasi das „Gegenteil“ einer Zahl bezüglich der Multiplikation sehr einfach zu finden ist (0,25 ist das „Gegenteil“ von 4), also der Entschlüsselungsschlüssel sich aus dem Verschlüsselungsschlüssel berechnen ließe. In Wirklichkeit wird ein Algorithmus verwendet, wo das „Gegenteil“ des Verschlüsselungsschlüssels zwar existiert, aber nicht berechnet werden kann. Du kannst dir auch denken, dass echte Schlüssel sehr sehr viel größere Zahlen sind, damit es sehr sehr viele verschiedene gibt und man nicht einfach alle durchprobieren kann.

Die Idee ist jetzt, dass die Verschlüsselungs- und die Entschlüsselungsberechnung (also der Algorithmus) öffentlich ist und dass eine Person, die an diesem Kommunikationsnetz teilnehmen will, für sich selber die zwei Zahlen generiert: die Verschlüsselungszahl und die Entschlüsselungszahl. Die Verschlüsselungszahl gibt sie weiter, die ist also öffentlich. Die Entschlüsselungszahl gibt sie nicht weiter, die ist also geheim. In diesem Setting sollte es also möglich sein, dass ich an dich eine geheime Nachricht schicke, die nur du lesen kannst: Indem ich nämlich die Nachricht mit deinem öffentlichen Verschlüsselungsschlüssel verschlüssele. Dann kannst nur du den Geheimtext mit deinem geheimen Entschlüsselungsschlüssel entschlüsseln. Niemand anderes hat deinen geheimen Entschlüsselungsschlüssel, auch ich nicht. Dass das wirklich funktioniert, wenn der Algorithmus öffentlich bekannt ist, dass man so ein Zahlenpaar erzeugen kann mit einer öffentlichen und einer geheimen Zahl, so dass die Berechnungen alle aufgehen und man nicht aus der öffentlichen Zahl die geheime Zahl berechnen kann – das ist zugegebenerweise erstmal schwer nachzuvollziehen. Mit der Erkenntnis haben sich viele schwergetan. Deshalb hat es auch bis in die 1970er Jahre gedauert, bis diese Verfahren entwickelt wurden. Nehmen wir für den Moment einfach hin, dass es funktioniert: Du kannst dir nach einem bestimmten Verfahren zwei zusammen gehörende Zahlen ausdenken, von denen du eine geheimhältst und die andere weitergibst. Diese ganze Verschlüsselungsberechnung funktioniert, obwohl sich aus der einen nicht die andere Zahl berechnen lässt. Also obwohl beide Zahlen untrennbar zusammen gehören und es zu jeder öffentlichen Zahl genau eine geheime Zahl gibt und umgekehrt, kannst du nicht aus der öffentlichen Zahl die geheime Zahl berechnen. Wie gesagt: Für die Details lies gerne hier und hier.

Wenn von einem OpenPGP-Schlüssel die Rede ist, dann sind damit also eigentlich zwei Schlüssel gemeint, die aber zusammen gehören: ein öffentlicher Schlüssel (public key) und ein geheimer Schlüssel (privater Schlüssel, secret key, private key). Den öffentlichen Schlüssel erzeugst du auf einem vertrauenswürdigen Computer. Im Zuge der Erzeugung des öffentlichen Schlüssels erfährst du auch den dazu gehörenden geheimen Schlüssel. Den geheimen Schlüssel speicherst du dir sicher weg, damit den garantiert sonst niemand erfährt. Niemand außer dir selbst soll jemals Zugriff auf den geheimen Schlüssel haben. Den öffentlichen Schlüssel dagegen streust du so breit, wie es nur geht. Alle sollen den öffentlichen Schlüssel von dir haben, denn sie brauchen ihn, um Nachrichten an dich verschlüsseln zu können, die nur du dann mit deinem geheimen Schlüssel entschlüsseln kannst.

Digitale Signaturen

Jetzt weißt du also, wie Verschlüsselung und Entschlüsselung funktioniert. Bei dieser Gelegenheit will ich dir noch eine spannende Anwendungsmöglichkeit dieser Public-Key-Kryptographie zeigen: Das ist ja alles nur Mathematik. Und die Mathematik weiß nichts von der Bedeutung dieser Zahlen. Die Mathematik weiß nicht, dass der geheime Schlüssel geheim ist und dass der öffentliche Schlüssel öffentlich ist. Für die Mathematik gilt einfach nur: Wenn du mit irgendeiner Zahl „Klartext“ die Zahl „öffentlicher Schlüssel“ verrechnest und mit dem Ergebnis die Zahl „geheimer Schlüssel“ verrechnest, dann bekommst du wieder die Zahl „Klartext“ raus. Spannenderweise funktioniert das auch andersrum. Genauso wie es bei der Multiplikation egal ist, ob du zuerst mal 4 und dann mal 0,25 rechnest oder zuerst mal 0,25 und dann mal 4, genauso kannst du im Prinzip auch eine Zahl „Klartext“ zuerst mit einer Zahl „geheimer Schlüssel“ verrechnen. Wenn du das Ergebnis davon dann mit der dazugehörigen Zahl „öffentlicher Schlüssel“ verrechnest, bekommst du wieder die vorher eingegebene Zahl „Klartext“.

Das braucht man für sog. digitale Signaturen. Wenn du einen Klartext mit deinem geheimen Schlüssel „verschlüsselst“ (in Anführungszeichen, weil das keine richtige Verschlüsselung ist), dann kann jede Person, die Zugriff auf deinen öffentlichen Schlüssel hat, – also im Prinzip jede Person – diesen Kauderwelsch mit deinem öffentlichen Schlüssel „entschlüsseln“ und bekommt wieder den Klartext raus. Das heißt, jede Person kann nachvollziehen, dass nur du den Kauderwelsch aus dem Klartext erzeugt haben konntest, denn um das zu tun, braucht man ja den geheimen Schlüssel, den definitiv nur du haben solltest.

Wir können noch ein kleines Rechenbeispiel durchgehen mit dem zu stark vereinfachten Modell, dass der Krypto-Algorithmus die einfache Multiplikation ist. Nehmen wir an, dein öffentlicher Schlüssel ist die 4. Dein geheimer Schlüssel ist also die 0,25. Nehmen wir an, mein öffentlicher Schlüssel ist die 5. Mein geheimer Schlüssel ist also die 0,2. Die öffentlichen Schlüssel haben wir ausgetauscht: Ich weiß, dass dein öffentlicher Schlüssel die 4 ist, und du weißt, dass mein öffentlicher Schlüssel die 5 ist. Aber ich kenne deinen geheimen Schlüssel nicht und du kennst meinen geheimen Schlüssel nicht. Jetzt könnte ich dir eine signierte und verschlüsselte Nachricht schicken. Die Nachricht ist die Zahl 815. Ich signiere diese Nachricht zuerst mit meinem Schlüssel, indem ich den Algorithmus Multiplikation mit der Nachricht 815 und meinem geheimen Schlüssel 0,2 ausführe: 815 · 0,2 = 163. Das ist die Signatur der Nachricht. Damit du die Nachricht auch lesen kannst, ohne die Signatur zu überprüfen, und damit du überhaupt weißt, gegen welche Originalnachricht du die Signatur prüfen sollst, will ich dir sowohl die Klartextnachricht 815 als auch die Signatur 163 schicken. Beides zusammen – die Zahl 815163 – ist die signierte Nachricht. Die signierte Nachricht 815163 verschlüssele ich mit deinem Schlüssel, indem ich den Algorithmus Multiplikation mit der signierten Nachricht 815163 und deinem öffentlichen Schlüssel 4 ausführe: 815163 · 4 = 3260652. Die verschlüsselte Nachricht 3260652 schicke ich dir. Nur du kannst sie mit deinem geheimen Schlüssel 0,25 auspacken und erhältst die signierte Nachricht 3260652 · 0,25 = 815163. Meine Nachricht 815 kannst du jetzt schon mal lesen. Aber da nicht nur ich deinen öffentlichen Schlüssel habe, sondern die ganze Welt damit Nachrichten an dich verschlüsseln kann, könnte die Nachricht 815 ja auch von einer anderen Person kommen. Deshalb überprüfst du die Signatur, indem du die Nachricht 815 von der Signatur 163 trennst und den Algorithmus mit der Signatur und meinem öffentlichen Schlüssel 5 ausführst: 163 · 5 = 815. Das Ergebnis ist identisch zur Nachricht. Also war die Signaturprüfung erfolgreich und du kannst davon ausgehen, dass du die Nachricht von einer Person geschickt bekommen hast, die Zugriff auf den geheimen Schlüssel hat, von dem du vermutest, dass nur ich den habe.

Vertrauen in Schlüssel

Wenn wir das so umsetzen, wie ich es bis hierhin beschrieben habe, sollte das schon funktionieren. Es bleibt aber ein praktisches Problem, bei dem uns die Mathematik kaum weiterhilft: Woher weiß ich denn, dass dein öffentlicher Schlüssel wirklich deiner ist? Also es könnte ja irgendjemand ein Schlüsselpaar erzeugen, den öffentlichen Schlüssel ans schwarze Brett hängen und daneben schreiben, dass das deiner ist, obwohl überhaupt nicht du im Besitz des dazu passenden geheimen Schlüssels bist, sondern die andere Person. Wenn das passiert, dann ist ein sog. Angriff möglich. Die Person, die den falsch zugeordneten Schlüssel veröffentlicht hat, kann geheime Nachrichten unbefugt mitlesen: Wenn ich eine Nachricht an dich verschlüsseln will (egal, ob signiert oder nicht), dann verschlüssele ich sie aus Versehen mit dem falsch zugeordneten öffentlichen Schlüssel, der in Wirklichkeit der Angreifer*in gehört. Die Angreifer*in entschlüsselt die Nachricht, liest sie, verändert sie gegebenenfalls (falls sie nicht signiert ist; oder sie entfernt die Signatur) und verschlüsselt sie neu mit deinem tatsächlichen öffentlichen Schlüssel, zu dem du auch den geheimen Schlüssel hast, und schickt dir das Ergebnis. Du kannst die mitgelesene Nachricht dann entschlüsseln. Die Signaturprüfung wird erfolgreich sein (wenn die Nachricht nicht verändert wurde), weil die Angreifer*in die Originalsignatur einfach unverändert weitergeleitet hat.

Aus diesen Überlegungen folgen ein paar Dinge, die wichtig zu verstehen und zu beachten sind:

Wenn du öffentliche Schlüssel anderer Leute einsammelst, dann sei dir darüber im Klaren, aus welcher Quelle du einen Schlüssel beziehst. Hängt der an einem schwarzen Brett? Auf schwarze Bretter haben normalerweise mehrere Leute Zugriff, die da öffentliche Schlüssel ranhängen könnten. Woher weißt du, dass die Zuordnung des Schlüssels zu der Person stimmt? Hat die Person dir ihren Schlüssel zugeschickt? Auf welchem Kommunikationskanal? Vielleicht auf demselben Kanal, den du mit OpenPGP absichern willst? Wenn du zum Beispiel deinen E-Mail-Verkehr mit OpenPGP absichern willst und eine Person schickt dir ihren öffentlichen Schlüssel oder einen Link zu ihrem öffentlichen Schlüssel per E-Mail, dann kannst du entweder davon ausgehen, dass der Schlüssel möglicherweise von einer Angreifer*in verändert wurde, oder du vertraust deinem E-Mail-Verkehr so sehr, dass du ihn nicht mit OpenPGP absichern musst. In beiden Fällen erscheint es nicht sehr sinnvoll, dass du einen öffentlichen Schlüssel verwendest, der dir per E-Mail zugeschickt wurde. Finde besser eine vertrauenswürdige Quelle für öffentliche Schlüssel.
Verschlüsselung schränkt nur das Ziel einer Nachricht ein, nicht die Quelle. Wenn du eine verschlüsselte Nachricht verschickst, dann weißt du, dass niemand sonst diese Nachricht unbefugt lesen wird. Wenn du eine verschlüsselte Nachricht bekommst, weißt du aber nicht, wer sie dir geschickt hat. Selbst wenn in der Nachricht drinsteht, von wem sie ist, heißt das überhaupt nichts. Das hätte jede* da reinschreiben können.
Digitale Signaturen machen Nachrichten nicht unlesbar für Unbefugte. Wenn du jemandem eine signierte Nachricht schickst, dann ermöglichst du damit der Empfänger*in, zu überprüfen, dass du diese Nachricht tatsächlich genau so verfasst hast. Aber alle – nicht nur die von dir vorgesehene Empfänger*in – können die Nachricht lesen. Es kann so erstmal nicht unbedingt festgestellt werden, an wen du die Nachricht verfasst hast und wann (wenn der Zeitstempel der Signatur nicht überprüft wird). Die Nachricht kann also in einem völlig anderen Kontext entstanden sein und im Zuge eines Angriffs geeignet weitergeleitet worden sein, um eine bestimmte Bedeutung zu suggerieren, die die Nachricht ursprünglich nie hatte. Wenn die Empfänger*in die Signatur nicht überprüft, dann kann die Nachricht auch unbemerkt unterwegs verändert werden. Es kann auch unterwegs die Signatur entfernt werden, so dass die Nachricht als unsignierte Nachricht zugestellt wird. Wenn die Empfänger*in unsignierten Nachrichten von dir vertraut, dann kann auch auf diese Weise an der Nachricht herummanipuliert werden.

Es ist wichtig, dass du diese Fallstricke im Blick hast und gut abschätzen kannst, inwiefern du gerade wirklich der scheinbaren Realität vertrauen kannst. Zwar kannst du auch mal fünfe grade sein lassen und einfach hoffen, dass schon nichts schiefgehen wird, aber strenggenommen brauchst du dann OpenPGP nicht und kannst an dieser Stelle aufhören zu lesen (und auf ein automatisierteres, also nur opportunistische Sicherheit bietendes, kryptographisches System umsteigen wie Signal etc.).

Fingerabdrücke

Vor allem zu dem einen Fallstrick gibt es noch mehr zu sagen: Wo kommen die öffentlichen Schlüssel anderer Leute her? Das beste wäre natürlich, du triffst dich mit der Person, deren öffentlichen Schlüssel du haben willst, und nimmst ihn von ihr eigenhändig entgegen. Das ist aus einem Grund oft nicht ganz so praktikabel, den ich vorhin erwähnt habe: Um überhaupt eine Sicherheit bieten zu können, sind OpenPGP-Schlüssel sehr sehr große sehr sehr zufällig aussehende Zahlen. Das sind keine Passwörter wie hasenpups123, die man sich mal eben merken und abtippen kann, sondern das sind völlig wild zusammengewürfelte Zahlen der Größenordnung 32 Byte bis 512 Byte. Im geläufigeren Dezimalsystem sind das Zahlen mit 77 bis 1234 Stellen. Theoretisch könnte man diese Zahlen statt im üblichen Zahlensystem zur Basis 10 (mit den zehn Ziffern 0, 1, 2, 3, 4, 5, 6, 7, 8 und 9) in einem Zahlensystem zur Basis 36 notieren, wobei die „Ziffern“ 36 verschiedene Symbole sind, zum Beispiel die Buchstaben a bis z und die Ziffern 0 bis 9. Auf die Weise erhält man kürzere Zahlendarstellungen, ist aber trotzdem immer noch bei mindestens 50 Zeichen (bis zu 800 Zeichen, je nach Sicherheitsniveau) ohne erkennbare Struktur, die dann fehlerfrei abgetippt werden müssten. So richtig handlich ist das nicht. Die einzige Möglichkeit scheint es also zu sein, den öffentlichen Schlüssel vertrauenswürdig und digital zu übergeben, zum Beispiel per USB-Stick oder direkter Netzwerkverbindung. Die vertrauenswürdigsten Übergabekanäle sind aber die, die die beteiligten Menschen hundertprozentig nachvollziehen können, also die nicht-digitalen.

Typischerweise bedient man sich hier eines Tricks: Ein wesentlicher Vorteil der asymmetrischen gegenüber der symmetrischen Kryptographie ist ja, dass der Schlüsselaustausch in der Öffentlichkeit stattfinden kann. Das Schlüsselmaterial muss nicht vor fremden Blicken geheimgehalten werden, da sowieso nur öffentliche Schlüssel ausgetauscht werden. Es muss nur sichergestellt werden, dass am Übertragungskanal nicht herummanipuliert wird, damit nicht der falsche Schlüssel übertragen wird. Also findet die Schlüsselübergabe in zwei Schritten statt: Im einen Schritt wird der komplette öffentliche Schlüssel in all seiner Länge und Breite über einen möglichst komfortablen (aber nicht unbedingt gegen böswillige Manipulationen gesicherten) Kanal übertragen; zum Beispiel einfach über das Internet. Im anderen Schritt bildet die Person, der der Schlüssel gehört, eine relativ kurze Prüfsumme von dem Schlüssel und gibt nur diese kurze Prüfsumme auf einem manipulationssicheren, aber weniger komfortablen, Kanal an die Empfänger*in des öffentlichen Schlüssels. Die Prüfsumme alleine reicht nicht aus, weil das nicht der ganze öffentliche Schlüssel ist. Aber wenn ich sowohl deinen öffentlichen Schlüssel als auch die Prüfsumme von dir bekommen habe, dann kann ich gucken, ob ich auch tatsächlich den richtigen öffentlichen Schlüssel von dir bekommen habe. Eine Angreifer*in könnte mir einen falschen öffentlichen Schlüssel unterjubeln, aber es ist im Prinzip unmöglich (aus mathematischen Gründen ultraextrem schwer), für den Angriff ein neues Schlüsselpaar mit der passenden Prüfsumme zu erzeugen.

Durch diesen Trick mit der Prüfsumme muss nicht mehr der komplette öffentliche Schlüssel manipulationssicher übergeben werden, sondern nur noch die kürzere Prüfsumme. Und die muss auch nicht abgetippt werden, sondern es reicht, sie sich anzugucken, um festzustellen, dass es dieselbe ist. Das geht natürlich viel einfacher. Weil die Prüfsumme für jedes Schlüsselpaar weltweit eindeutig ist und es niemandem gelingen dürfte, ein Schlüsselpaar zu erzeugen, das dieselbe Prüfsumme hat wie ein anderes irgendwo existierendes Schlüsselpaar, deshalb wird diese Prüfsumme Fingerabdruck (fingerprint) genannt.

Wenn du einen öffentlichen Schlüssel irgendwo her bekommen hast und den Fingerabdruck noch nicht abgeglichen hast, dann kannst du diesen Schlüssel nur unter Vorbehalt benutzen und musst davon ausgehen, dass er sich später eventuell als gefälscht herausstellt.

GnuPG ausführen

Lass uns dann jetzt mal anfangen, GnuPG zu benutzen, um ein eigenes Schlüsselpaar zu erzeugen. Wenn du GnuPG das erste Mal benutzt, stellt es möglicherweise fest, dass das Verzeichnis noch nicht existiert, in dem das Programm seine Daten ablegt, und erstellt dann das Verzeichnis. Führe GnuPG einfach einmal mit dem Kommandozeilenargument -k aus, also gib ein:

gpg -k

Der Zweck dieses Befehls ist es, alle Schlüssel aufzulisten, die du schon hast. Da du nun wahrscheinlich keine Schlüssel hast, sollte auf diesen Befehl hin keine Ausgabe kommen. Wenn doch eine kommt, dann ist das vielleicht eine, die dir etwas über GnuPGs Hausmeistertätigkeiten erzählt, weil das Programm erstmal das Verzeichnis und seine Datenbank angelegt hat. Dann kannst du mal gucken, was passiert, wenn du den Befehl gleich nochmal ausführst. Wahrscheinlich musst du ihn dazu nicht neu eintippen, sondern es sollte reichen, die Pfeil-nach-oben-Taste zu drücken und den Befehl neu abzuschicken, also ↑ und ↵.

Wenn die Ausgabe immer noch nicht leer ist, dann lies mal genau, was da steht: Entweder hast du schon irgendwelche Schlüssel in deiner Schlüsseldatenbank drin (die jetzt nicht weiter stören sollten) oder GnuPG gibt eine Warnung aus über Konfigurationsprobleme (die hoffentlich nicht so schlimm sind, dass du sie jetzt dringend beheben müsstest) oder du hast den Befehl irgendwie falsch eingegeben.

Ich werde jetzt im Folgenden neben -k noch verschiedene andere Kommandozeilenargumente nennen, mit denen du GnuPG dazu bringen kannst, bestimmte Dinge zu tun. Wahrscheinlich merkst du dir das alles nicht auf Anhieb. Dann ist es gut, wenn du sowas alles irgendwo übersichtlich nachschlagen kannst. GnuPG hat eine eingebaute Hilfefunktion, die du mit dem Argument -h erreichst. Gib einfach ein:

gpg -h

Daraufhin bekommst du eine halbwegs vollständige Auflistung aller Argumente und noch ein paar zusätzliche Infos. Es wird aber zu jedem Argument nur jeweils ein knapper Stichpunkt genannt. Eine ausführlichere Erklärung mit viel mehr Text gibt es auch, zumindest wenn du nicht Windows benutzt. Wenn du nicht Windows benutzt, dann gibt es einen Befehl man (für manual), mit dem du Handbuchseiten lesen kannst. GnuPG hat auch eine Handbuchseite, die du mit

man gpg2

oder

man gpg

aufrufen kannst. Wenn es beide gibt, dann ist die zu gpg2 wahrscheinlich die richtige und ausführlichere. In dieser man-Ansicht kannst du mit den Pfeiltasten navigieren und mit der Taste Q kommst du wieder raus zu deiner Kommandozeile.

Wenn du Windows benutzt, dann musst du dir das Handbuch wahrscheinlich extra aus dem Internet besorgen. Auf der GnuPG-Website gibt es das im PDF-Format. Seite 39–103 „Invoking GPG“ entspricht dem, was man gpg2 ausgibt.

Schlüssel erzeugen

Die Funktion von GnuPG, die uns jetzt zur Schlüsselerzeugung interessiert, nennt sich --full-gen-key. Full bedeutet, dass man da ganz viele Möglichkeiten hat, alles individuell einzustellen. Es gibt alternativ auch die Argumente --generate-key für weniger Einstellmöglichkeiten und --quick-generate-key für noch weniger Einstellmöglichkeiten. Da ich aber davon ausgehe, dass du wissen willst, was unter der Haube passiert, bleiben wir jetzt erstmal bei --full-gen-key und setzen noch einen drauf, indem wir zusätzlich das Argument --expert angeben. Damit hat man sogar noch mehr Einstellmöglichkeiten, auch potenziell unkluge. Es wird empfohlen, dieses Argument nur dann anzugeben, wenn man ziemlich genau weiß, was man tut. Das weißt du jetzt zwar noch nicht, aber du willst es lernen und das Schlüsselpaar, das du jetzt erzeugst, ist sowieso nicht für den praktischen Gebrauch bestimmt, sondern nur zum Experimentieren. Also bitte gib folgenden Befehl ein:

gpg --expert --full-gen-key

Du wirst dann Schritt für Schritt durch einen Fragebogen geführt, an dessen Ende du ein Schlüsselpaar erhältst. Wenn du zwischendurch abbrechen willst, um wieder zur Kommandozeile zurückzukommen und nochmal neu anfangen zu können, dann kannst du jederzeit Strg-C drücken. Gehen wir mal durch, was da so gefragt wird.

gpg (GnuPG) 2.3.8; Copyright (C) 2021 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Please select what kind of key you want:
   (1) RSA and RSA
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
   (7) DSA (set your own capabilities)
   (8) RSA (set your own capabilities)
   (9) ECC (sign and encrypt) *default*
  (10) ECC (sign only)
  (11) ECC (set your own capabilities)
  (13) Existing key
  (14) Existing key from card
Your selection?

Hier wird als erstes nach einem Algorithmus gefragt, mit dem die asymmetrische Kryptographie später ablaufen soll. Du hast hier im Wesentlichen zwei Optionen. Die eine heißt RSA. Das ist ein sehr altes (gewissermaßen das älteste) Verfahren, das deshalb sehr vertrauenswürdig ist, weil es seit über vierzig Jahren intensiv erforscht wird und bislang immer noch als unknackbar gilt. Wenn du auf altehrwürdige Standards setzen willst, dann nimm das. Die andere Option ist ECC. Das ist ein komplexeres mathematisches Konzept, das ein bisschen jünger ist als RSA und von wesentlich weniger Menschen gut verstanden wird als RSA.

Hier sind noch ein paar Sätze zu RSA vs. ECC.

Die Umsetzung eines ECC-Algorithmus in ein fehlerfreies Programm ist wegen der Komplexität des Verfahrens schwieriger. Außerdem kann prinzipbedingt bei ECC-Algorithmen nie hundertprozentig ausgeschlossen werden, dass es eine Hintertür gibt, durch die die Person, die die ECC-Variante (sog. Kurve) entwickelt hat, alle Nachrichten entschlüsseln kann. Und von den derzeit neun ECC-Kurven, die du mit GnuPG verwenden kannst, sind nur drei standardisiert, von denen keine einzige empfehlenswert ist (siehe unten). Das heißt, wenn du eine eher empfehlenswerte Kurve verwendest, dann bewegst du dich strenggenommen außerhalb des Standards und kannst vielleicht mit einigen Leuten (die nicht GnuPG, sondern eine andere OpenPGP-Software verwenden) nicht kommunizieren. Diesen Nachteilen stehen auch Vorteile gegenüber: Bei ECC hast du mit deutlich kleineren Zahlen zu tun. Dein öffentlicher Schlüssel ist bei RSA etwa 20-mal so lang wie bei ECC. Die Berechnungen gehen auch schneller bei ECC. Und es gibt unbelegbares Geraune, dass RSA irgendwie unsicherer als ECC sein könnte, vielleicht. Alle diese Vor- und Nachteile lassen sich trefflich relativieren. Es ist unwahrscheinlich, dass du am laufenden Band tonnenweise Nachrichten signieren oder entschlüsseln willst oder mehr als ein Schlüsselpaar pro Sekunde erzeugst. Also ist Geschwindigkeit meistens auch egal in diesen Größenordnungen. Dass Berechnungen schneller gehen, bedeutet übrigens nicht, dass sich ECC-Verschlüsselungen schneller illegitim knacken ließen als RSA-Verschlüsselungen. Die Schlüssel willst du unabhängig von deren Länge sowieso nicht manuell abtippen, sondern du schiebst die als Dateien hin und her. Also ist es wurscht, ob die 20-mal so groß sind oder nicht. Die empfehlenswerteren nicht standardisierten Kurven werden von aktueller OpenPGP-Software trotzdem normalerweise unterstützt. Bei einigen ECC-Kurven, die bei GnuPG verwendet werden können (eben den empfehlenswerteren), ist es ziiiemlich unwahrscheinlich, dass sich da jemand eine Hintertür eingebaut hat. Und da GnuPG eine gut gepflegte Software ist, die auch schon seit vielen Jahren ECC-Unterstützung eingebaut hat, dürften da keine sehr schwerwiegenden Fehler mehr drin sein, hofft man.

Also entscheide dich nach welchen Kriterien auch immer: für RSA (set your own capabilities) oder ECC (set your own capabilities), indem du die davor in Klammern angegebene Zahl 8 bzw. 11 eingibst und die Enter-Taste drückst.

Dass da bei den ersten beiden Auswahlmöglichkeiten je zwei Algorithmen in einer Reihe stehen und dass darunter verschiedene Dinge in Klammern stehen, das hat mit einer Sache zu tun, die ich vorher noch nicht erwähnt hatte: Nämlich dass ein OpenPGP-Schlüsselpaar mehr ist als einfach nur zwei Zahlen, die für die kryptographischen Algorithmen verwendet werden. OpenPGP-Schlüssel sind Behälter, in die ganz viele Informationen reingeworfen werden; unter anderem diese kryptographischen Zahlen. Aber auch sowas wie Name, E-Mail-Adresse, Erstellungsdatum, Gültigkeitszeitraum, Foto und diverse obskure andere Dinge. Ein einziges OpenPGP-Schlüsselpaar besteht sogar üblicherweise aus mehr als einem mathematischen Schlüsselpaar. Angenommen, du erzeugst dir ein OpenPGP-Schlüsselpaar, das aus drei verschiedenen mathematischen Schlüsselpaaren besteht. Wenn du dann jemandem deinen „öffentlichen Schlüssel“ gibst, dann übergibst du eigentlich in dem Beispiel drei verschiedene Zahlen, die alle drei verschiedene öffentliche Schlüssel für verschiedene Einsatzzwecke sind. Alle drei öffentlichen Schlüssel zusammen werden gemeinsam mit deiner E-Mail-Adresse, dem Ablaufdatum der Schlüssel und weiteren Infos in eine Datei zusammengepackt. Diese Datei ist dann im Sinne von OpenPGP dein „öffentlicher Schlüssel“.

In dieser ersten Frage kannst du schon wählen, welche kryptographischen Schlüssel mit welchem Einsatzzweck (zum Beispiel signieren oder verschlüsseln) du zu einem einzigen OpenPGP-Schlüssel kombinieren willst. Wenn du (set your own capabilities) wählst, dann kannst du das im Detail in einer späteren Frage noch festlegen und es wird dann jetzt erstmal nur ein einziges kryptographisches Schlüsselpaar erzeugt. Die anderen Auswahlmöglichkeiten sind einfach nur Abkürzungen für gewisse beliebtere Konfigurationen. Mit (set your own capabilities) kannst du alle Varianten erreichen und hast die maximale Flexibilität.

Ich sage noch kurz etwas zu den anderen angebotenen Optionen.

Elgamal ist ein Verschlüsselungsverfahren, das früher gegenüber RSA den Vorteil hatte, lizenzfrei benutzt werden zu können, also in einem dezentralen Kommunikationssystem überhaupt benutzt werden zu können. Seit das RSA-Patent ausgelaufen ist, entfällt dieser Vorteil und Elgamal ist nur noch aus historischen Gründen weiterhin dabei. DSA ist ein Signaturverfahren, das von der Regierung der USA standardisiert wurde, mit deren Hintergedanken im Blick. DSA erzeugt kurze Signaturen. Kürzer als bei ECC sind sie aber auch nicht. Gegen beide, Elgamal und DSA, spricht nichts prinzipiell. Deshalb werden sie von GnuPG angeboten. RSA und die ECC-Verfahren sind weiter verbreitet und besser beforscht. In der Kryptographie scheint es eine gute Idee zu sein, nicht allzu exotisch unterwegs zu sein.

Deshalb entscheide ich persönlich (du kannst das anders sehen) mich immer gegen DSA und Elgamal. Unter RSA und ECC wähle ich normalerweise RSA, weil ich das selbst besser nachvollziehen kann. ECC wähle ich in besonderen Fällen, wo geringerer Platzbedarf und schnellere Berechnungen wirklich eine Rolle spielen – beim Anwendungsfall Austausch von E-Mail-Nachrichten also nicht.

Die letzten beiden angebotenen Optionen beziehen sich auf den Fall, dass du keine neuen kryptographischen Schlüssel erzeugen willst, sondern nur einen neuen OpenPGP-Behälter, in den ein schon existierender kryptographischer Schlüssel eingebaut werden soll. Sehr wahrscheinlich brauchst du das nicht. Du kannst einfach ein neues Schlüsselpaar erzeugen.

Gehen wir zur nächsten Frage. Ich habe hier in dem Beispiel die Option RSA (set your own capabilities) gewählt. Es geht aber so ähnlich weiter, wenn du stattdessen ECC (set your own capabilities) gewählt hast:

Your selection? 8

Possible actions for this RSA key: Sign Certify Encrypt Authenticate 
Current allowed actions: Sign Certify Encrypt 

   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished

Your selection?

Dazu muss ich jetzt wieder was erklären, damit das verständlich ist. Ein OpenPGP-Schlüssel besteht ja wie gesagt aus einem oder mehreren kryptographischen Schlüsseln. Einer dieser Schlüssel ist der Hauptschlüssel (primary key), alle anderen sind dann dessen Unterschlüssel (subkeys). Es gibt unterschiedliche Ansichten darüber, inwiefern man das braucht. Einige Kryptographie-Profis sind der Meinung, dass das optimale Vorgehen ist, immer mehrere Schlüsselpaare zu erzeugen – für jeden Anwendungszweck eins. Auf jeden Fall sollte man nicht denselben RSA-Schlüssel zum Signieren verwenden, den man auch zum Verschlüsseln verwendet. (Das ist eine Spitzfindigkeit aufgrund der speziellen Funktionsweise von RSA, nach der Signieren und Entschlüsseln mathematisch gesehen tatsächlich exakt dieselbe Operation ist. Dadurch sind witzige Angriffe möglich, wenn du für die beiden Operationen auch noch denselben Schlüssel verwendest.) Die sicherste Variante ist es, immer wirklich für jeden einzelnen Zweck einen eigenen Schlüssel zu erzeugen.

Der Hauptschlüssel wird dann nicht dafür benutzt, Nachrichten zu signieren oder andere Leute Nachrichten verschlüsseln zu lassen. Der einzige Zweck des Hauptschlüssels ist es in diesem Szenario, Aussagen über OpenPGP-Schlüssel zu signieren. Man nennt das genauer auch „zertifizieren“ (oder beglaubigen): Wenn du deinem OpenPGP-Schlüssel die Information anhängst, wie deine neue E-Mail-Adresse lautet, wenn du für deinen OpenPGP-Schlüssel einen neuen Unterschlüssel erzeugst, wenn du den Gültigkeitszeitraum deines OpenPGP-Schlüssels um ein Jahr verlängerst, wenn du anderer Leute OpenPGP-Schlüssel die Information anhängst, dass du glaubst, dass die nicht der falschen Person zugeordnet sind, dann sind das alles Aussagen über OpenPGP-Schlüssel, die du mit deinem eigenen Hauptschlüssel signierst, also zertifizierst. „Zertifizieren“ ist im Prinzip auch signieren, heißt aber immer OpenPGP-Schlüssel signieren. Ein Zertifikat ist ein signierter öffentlicher Schlüssel.

Konsequent für jeden Einsatzzweck (zertifizieren, signieren und verschlüsseln) je ein eigenes Schlüsselpaar zu erzeugen, die alle zusammen in einem OpenPGP-Schlüssel stecken, kann ein sichereres Schlüsselmanagement ermöglichen. Ich denke, es würde zu weit führen, das hier im Detail auszudiskutieren, aber wenn es dich näher interessiert, kannst du es nachlesen oder auch noch ausführlicher nachlesen. Also unter Umständen hat das Vorteile. Nennenswerte Nachteile hat das nicht; höchstens dass dein öffentlicher Schlüssel größer wird, weil er mehrere öffentliche Schlüssel enthält. Im normalen Gebrauch guckt sich niemand so genau deinen öffentlichen Schlüssel an und interessiert sich für dessen Größe, zumal wir hier von einigen Kilobyte reden. Also nichts, was in Zeiten von Ultra-HD-Porno-Streaming eine Revolution auslöst. Aber vielleicht ist das für dich ein Argument.

Ich gehe hier mal davon aus, dass du deine Schlüssel wirklich auseinander halten willst, also einen Hauptschlüssel nur zum Zertifizieren und je einen Unterschlüssel zum Signieren und Verschlüsseln erzeugen willst. Außerdem gibt es noch die Option „authentifizieren“. Das ist für den Fall, dass du deinen OpenPGP-Schlüssel auch für SSH verwenden willst. Wenn du nicht weißt, was das ist, dann brauchst du es nicht.

Also drücke die angegebenen Buchstaben, um alle angeschalteten Schlüsselfunktionen abzuschalten, die sich abschalten lassen, und schließe dann die Frage ab:

Your selection? 8

Possible actions for this RSA key: Sign Certify Encrypt Authenticate 
Current allowed actions: Sign Certify Encrypt 

   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished

Your selection? s

Possible actions for this RSA key: Sign Certify Encrypt Authenticate 
Current allowed actions: Certify Encrypt 

   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished

Your selection? e

Possible actions for this RSA key: Sign Certify Encrypt Authenticate 
Current allowed actions: Certify 

   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished

Your selection? q

Welche Frage als nächstes aufploppt, hängt davon ab, ob du dich vorher für RSA oder ECC entschieden hast.

Wenn du einen RSA-Schlüssel erzeugst, dann lies hier weiter.

Dir wird jetzt die Frage nach dem Sicherheitsniveau gestellt:

Your selection? q
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (3072)

Die Zahl in Klammern ist die, die angenommen wird, wenn du gleich Enter drückst, ohne eine Zahl einzugeben. Aber wir können ja mal kurz drüber nachdenken.

Du kannst die vorgegebene 3072 übernehmen (was schon sicher genug ist) oder 4096 für noch mehr Sicherheit eingeben. Das ist beides ok. Noch mehr Sicherheit, wenn es schon absolut sicher ist, gibt es eh nicht. Wenn du es genauer wissen willst, dann lies hier weiter.

1024 Bit ist im Prinzip lang genug, aber es ist nicht ausgeschlossen, dass irgendjemand (vielleicht nicht jetzt, aber in den nächsten Jahren) genug Rechenpower zusammen hat, um einen 1024-Bit-Schlüssel in einem Jahr Rechenzeit zu knacken. Das ist also nichts, worum du dir konkret Sorgen machen müsstest. Aber staatliche Akteure (die wiederum staatliche Akteure als Feinde haben; und staatliche Akteure neigen dazu, viel Geld zu haben, um Rechenzeit zu kaufen) empfehlen, mehr als 1024 Bit zu verwenden. 1024-Bit-RSA-Schlüssel gelten heute als ein bisschen altmodisch.

Die Kryptographie-Forschung macht sich einen Spaß draus, mit viel Aufwand bestimmte RSA-Schlüssel zu knacken. Wer als erster einen bestimmten Schlüssel geknackt hat, hat gewonnen. Das klingt vielleicht bisschen albern, aber die Liste der Wettkampf-Ergebnisse gibt etwas Aufschluss darüber, wo wir heute als Menschheit stehen in Bezug auf Rechenleistung und Angriffe auf RSA-Schlüssel. Wenn man sich die Tabelle anguckt, dann erscheint es heute nicht mehr so unwahrscheinlich, dass vielleicht jetzt schon jemand (ein Staat?) insgeheim so viel Rechenpower zusammen geschmissen hat, um im Prinzip (allerdings mit hohem Zeitaufwand) 1024-Bit-Schlüssel zu knacken. Das müsste dann aber für jeden Schlüssel einzeln gemacht werden. Also es müsste jemand mit genügend Rechenpower explizit an deinem 1024-Bit-RSA-Schlüssel Interesse haben. Na ja.

Wenn dir das zu wackelig ist, dann kannst du die Schlüssellänge verdoppeln auf 2048 Bit. Damit solltest du ziemlich safe sein. Und zwar nicht doppelt so safe, sondern eine Milliarde mal so safe. (Warum? Das würde jetzt zu weit führen, aber für die Matheprofis steht das in dem hier verlinkten PDF-Dokument auf Seite 42 bzw. „30“, Suchbegriff Effective Key-size.) Kann höchstens sein, dass jemand ein krasses Verfahren entwickelt hat, wie man RSA-Schlüssel effizienter knacken kann als alle glauben (aber nicht so effizient, dass RSA komplett kaputt und unbenutzbar wäre). In dem Fall wären 2048 Bit vielleicht doch nicht mehr so sicher. Das ist ganz schön hypothetisch, aber kann ja sein.

Jedenfalls empfiehlt das BSI (Bundesamt für Sicherheit in der Informationstechnik) (um mal wieder auf das Thema staatliche Akteure zurückzukommen) mittlerweile mindestens 3000 Bit, weil ihnen ihre alte Empfehlung von mindestens 2000 Bit doch zu unwägbar geworden ist.

Also 2048 Bit ist nach allem, was wir wissen, absolut sicher. Wenn es da noch etwas gibt, was wir nicht wissen, dann sollte aber die Standardeinstellung von GnuPG von 3072 Bit absolut sicher sein. Wenn du es unnötig auf die Spitze treiben willst, dann verdopple halt 2048 Bit und nimm 4096 Bit. Na ja. Das ist das Maximum, weil alles darüber hinaus einfach wirklich albern und in keiner Weise zu rechtfertigen wäre.

Der Nachteil von großen RSA-Schlüssellängen ist, (neben einfach dem größeren Schlüssel, der mehr Speicherplatz und mehr Übertragungskapazität belegt) dass Berechnungen damit länger dauern. Ich glaube aber kaum, dass dir der Unterschied auffällt. Das geht auf aktueller Hardware eh schnell genug.

Falls du wissen willst, wo diese krummen Zahlen herkommen (bis auf die vom BSI): Die sind gar nicht krumm. Im Binärsystem sind das runde Zahlen. Das BSI hat krumme Zahlen. So.

Wenn du keinen RSA-, sondern einen ECC-Schlüssel erzeugst, dann lies hier weiter.

Dir wird jetzt die Frage nach der „Kurve“ gestellt:

Your selection? q
Please select which elliptic curve you want:
   (1) Curve 25519 *default*
   (2) Curve 448
   (3) NIST P-256
   (4) NIST P-384
   (5) NIST P-521
   (6) Brainpool P-256
   (7) Brainpool P-384
   (8) Brainpool P-512
   (9) secp256k1
Your selection?

Nur die ersten beiden Optionen – Curve 25519 und Curve 448 – sind wirklich empfehlenswert. Die Standardauswahl Curve 25519 ist sicher genug. Wenn du extreme Sicherheit willst (wobei fraglich ist, ob es etwas noch sichereres als sicher gibt), dann nimm Curve 448 – damit wird aber dein Schlüssel ein bisschen größer und die Berechnungen dauern ein bisschen länger. Nicht dass das in diesen Größenordnungen groß stören oder überhaupt auffallen würde, aber falls du dich vor allem wegen Schlüssellänge und Rechenintensität für ECC statt RSA entschieden hast, dann spricht das hier wohl eher für Curve 25519.

Falls du noch nen Satz mehr dazu und auch etwas zu den anderen angebotenen Kurven lesen willst, dann hab ich das hier für dich.

Du kannst ja oben in der Passage über RSA-Schlüssel meine Auslassungen über die Sicherheit von soundsoviel Bit langen RSA-Schlüsseln lesen, falls du die vorher übersprungen hast. Darauf aufbauend: Curve 25519 entspricht von der Sicherheit her etwa dem 3072-Bit-RSA-Schlüssel. Also wirklich sicher genug. Curve 448 ist eher so zirka mit einem 6144-Bit-RSA-Schlüssel vergleichbar, also absurd sicher. Da RSA und ECC aber zwei komplett verschiedene Verfahren sind, kann es sein, dass durch neue Forschungsergebnisse sich rausstellt, dass RSA wesentlich leichter geknackt werden kann als ECC, oder andersrum. Deshalb sind diese Vergleiche mit Vorsicht zu genießen und beziehen sich auf den aktuellen Stand der Dinge unter der (durchaus plausiblen) Annahme, dass nur die allgemein verfügbare Rechenleistung weiter steigt, aber die Angriffsmöglichkeiten gegen RSA und ECC nicht sprunghaft besser werden.

Wenn du Curve 448 wählst, dann erzeugt GnuPG dir ein Schlüsselpaar in einem neueren OpenPGP-Format (OpenPGP v5), das im Gegensatz zu dem aktuell verbreiteten Format (OpenPGP v4) vielleicht noch nicht von allen deinen Kommunikationspartner*innen verstanden wird, falls die nicht GnuPG benutzen. Auch mit Schlüsselservern usw. könntest du Probleme bekommen, wenn die das neue Format noch nicht verarbeiten können.

Zu den anderen Kurven: Die, die mit NIST anfangen, wurden vom NIST (National Institute of Standards and Technology der USA) empfohlen. Vom NIST ist bekannt, dass es in der Kryptographie auch Dinge auf Geheiß der NSA (National Security Agency der USA) empfiehlt, so dass die NSA internationale Kommunikation besser entschlüsseln kann. Bei ECC-Verfahren kommt es sehr darauf an, wie die zufällig aussehenden Parameter gefunden wurden (durch echten Zufall oder gezielt ausgedacht). Man kann dem fertigen Standard nicht mehr ansehen, ob er eine Hintertür hat oder nicht. Deshalb fallen die NIST-Kurven wegen Vertrauensmangel raus.

Die Kurven, die mit Brainpool anfangen, wurden vom deutschen Staat erzeugt. Das ist also auch keine unbedingt vertrauenswürdige Angelegenheit. Sie haben sich Mühe gegeben, dass das Verfahren vertrauenswürdig aussieht, aber es riecht komisch.

Zu secp256k1 fehlt mir das Wissen, um dazu etwas Fundiertes sagen zu können. Es ist wenig Information dazu auffindbar. Die Macher*innen von Curve 25519 und Curve 448 sehen in dieser Kurve einige Probleme, die sichere Implementationen erschweren, was auch immer das genau heißt. Ich habe jedenfalls bisher noch kein Argument irgendwo gelesen, warum diese Kurve besser sein soll. Insofern kann man sie auch einfach weglassen, denke ich. Diese Kurve wird bei Bitcoin verwendet und wird von GnuPG nur aus diesem Grund unterstützt. Wahrscheinlich hat secp256k1 keine Hintertür.

Gehen wir zur nächsten Frage: Der nach dem Ablaufdatum.

Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0)

Das ist auch wieder so eine Frage, die recht verwirrend ist und unter der man sich viele verschiedene Sachen vorstellen kann, die alle falsch sind. Also mal ganz langsam:

Wenn du deinen OpenPGP-Schlüssel fertig erzeugt haben wirst, dann wirst du ihn (automatisch) selbst signieren – also zertifizieren nennt man das in dem Fall genauer. Das Zertifikat enthält dann neben dem eigentlichen mathematischen Schlüsselmaterial (also den Zahlen für die Kryptoalgorithmen) noch ein paar textuelle Begleitinfos. Zum Beispiel den Zeitpunkt, ab dem der Schlüssel nicht mehr verwendet werden soll. Diese Begleitinfos können nur von dir selbst gesetzt und verändert werden, denn wenn andere Leute diese Infos verändern würden, dann würde damit deine Selbstsignatur ungültig werden, das heißt, das würde auffallen. Das Ablaufdatum eines Schlüssels ist also immer von der Person gesetzt worden, die im Besitz des geheimen Schlüssels ist. Wer einen Schlüssel verwenden will, der laut Zertifikat abgelaufen ist, wird sehr eindringlich darauf hingewiesen und von vernünftig programmierter Software (wie zum Beispiel GnuPG) mit allen Mitteln davon abgehalten, diesen Schlüssel zu verwenden. Das heißt aber natürlich nicht, dass du dir nach Ablauf deines Schlüssels einen neuen erstellen müsstest. Es spricht sogar einiges dafür, denselben weiter zu verwenden. Du kannst einfach das Ablaufdatum ändern. Mit deinem geheimen Schlüssel hast du ja die Mittel dazu.

Warum solltest du dann überhaupt ein Ablaufdatum setzen und nicht die Standardeinstellung übernehmen, dass der Schlüssel nie abläuft? Weil es Situationen geben kann, in denen du deinen Schlüssel nicht mehr verwendet sehen willst, ihn aber nicht selbst widerrufen kannst. Kann zum Beispiel sein, dass du dein Backup nicht richtig gemacht hast und jetzt dein geheimer Schlüssel weg ist. Oder du kannst dich an dein Passwort nicht mehr erinnern. Solche Fehler passieren gerade OpenPGP-Neulingen immer. Deinen ersten OpenPGP-Schlüssel, den du anderen Leuten gibst, wirst du verlieren. Meiner Erfahrung nach besteht daran kein Zweifel. Dann wirst du dich freuen, wenn dessen Ablaufdatum nicht allzu weit in der Zukunft liegt.

Außerdem könnte es passieren, dass jemand anderes unbefugt Zugriff auf deinen geheimen Schlüssel bekommt. Dann willst du deinen Schlüssel widerrufen. Das kannst du machen. Leute, die deinen öffentlichen Schlüssel schon haben, werden davon aber erstmal nicht unbedingt etwas mitkriegen, dass du deinen Schlüssel widerrufen hast. Mit einem nicht allzu großzügig gewählten Gültigkeitszeitraum zwingst du die Leute quasi dazu, gelegentlich mal zu gucken, ob dein Schlüssel eigentlich immer noch gültig ist.

Da du das jederzeit ändern kannst, spricht meines Erachtens nichts dagegen, jetzt eine sehr kurze Frist von zwei Wochen einzustellen. Dann kannst du in einer Woche schon mal üben, wie man das Ablaufdatum ändert. Blöde Sachen könnten höchstens passieren, wenn du ein zu spätes Ablaufdatum setzt. Aber ein zu frühes ist völlig unproblematisch. Ich empfehle dir, für den ersten Schlüssel, den du wirklich richtig benutzen und verteilen willst, nicht mehr als ein halbes Jahr einzustellen.

Als nächstes geht es um weitere Begleitinfos, die signierte (also nur von dir selbst veränderbare) Bestandteile des Zertifikats sein werden:

Key is valid for? (0) 2w
Key expires at Thu Feb 30 12:35:62 2342 CET
Is this correct? (y/N) y

GnuPG needs to construct a user ID to identify your key.

Real name: 
Email address: 
Comment:

Wenn du mit OpenPGP deinen E-Mail-Verkehr kryptographisch absichern willst, dann ist vor allem die E-Mail-Adresse wichtig. Wenn hier genau die E-Mail-Adresse (ohne Schreibfehler) drin steht, mit der du später OpenPGP verwenden willst, dann wird das von den verschiedenen E-Mail-Clients unterstützt und sie finden deinen Schlüssel automatisch.

Was als Name und als Kommentar angegeben ist, ist den ganzen Programmen völlig egal. Das ist höchstens für Menschen interessant, die deinen Schlüssel verwenden wollen und dann halt wissen müssen, wem er gehört. Wenn du nicht überall mit deinem Namen hausieren gehst, dann trag hier irgendwas ein. Wenn du deinen „richtigen“ Namen hier einträgst, dann könnten Menschen mit ihrer Signatur an deinem Schlüssel zertifizieren, dass sie überprüft haben, dass du es wirklich bist. Je nach dem, wie offiziell du so unterwegs bist. Wenn du hier irgendwelchen Quatsch einträgst, wird es anderen Leuten schwerer fallen, deinen Schlüssel richtig zuzuordnen.

Real name: Schnuffelchen
Email address: schnuffelchen@pkx.be
Comment: 
You selected this USER-ID:
    "Schnuffelchen <schnuffelchen@pkx.be>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o

Nachdem du das bestätigt hast, wird dein Schlüsselpaar erzeugt. Das dauert bis zu wenige Sekunden. Und dann wirst du zur zweifachen Eingabe eines Passwortes aufgefordert – oder nein, warte … Dialogfenster mit der Aufforderung, die Passphrase einzugeben, die den neuen Schlüssel schützt, und zwei Eingabefeldern für die Passphrase

Einer „Passphrase“ oder eines „Mantras“. Das Ding wird im OpenPGP-Kontext nie Passwort genannt, damit Leute nicht auf den blöden Gedanken kommen, dafür tatsächlich ein Wort zu wählen.

Was es mit dieser Passwortabfrage auf sich hat, ist Folgendes: Nachdem dein OpenPGP-Schlüsselpaar jetzt erzeugt wurde, kann der öffentliche Schlüssel und der geheime Schlüssel als Datei abgespeichert werden, damit du damit tun kannst, was auch immer du damit tun willst. Was den öffentlichen Schlüssel angeht: kein Problem. Aber der geheime Schlüssel sollte nicht einfach so auf einen permanent speichernden Datenträger geschrieben werden, weil der ja geheim ist. Wenn dir jemand eben diesen Datenträger abnimmt oder den ganzen Rechner, in dem er verbaut ist, dann war’s das mit der Geheimhaltung. Deshalb wird nur der öffentliche Schlüssel einfach so abgespeichert und der geheime Schlüssel immer nochmal mit einer Passwort-Verschlüsselung versehen, so dass der geheime Schlüssel niemals unverschlüsselt auf einen permanenten Speicher trifft. Von Festplatten und noch schlimmer SSDs und USB-Sticks bekommt man Daten nie wieder sicher runter, die man da einmal drauf gepackt hat. Deshalb werden geheime Schlüssel, die einmal unverschlüsselt auf ein solches Medium geschrieben wurden, als nicht mehr benutzbar (Fachsprache: kompromittiert) betrachtet.

Wenn du jetzt nur einen Testschlüssel zum Rumspielen erzeugst, muss dein Mantra nicht supersicher sein. Aber für deinen richtigen Schlüssel solltest du dir ein gutes Mantra überlegen. Du kannst dein Mantra zwar später noch ändern, das bringt aber nur begrenzt was: Wenn du deinen geheimen Schlüssel einmal mit einem schlechten Mantra abgespeichert hast, das jemand durch Ausprobieren vielleicht knacken könnte, dann musst du diesen Schlüssel bereits als geknackt betrachten, weil du die Version mit dem schlechten Mantra nie wieder sicher gelöscht kriegst. Wenn du wissen willst, wie man sowas doch sicher löschen kann, dann gib mal auf der Videoplattform deines geringsten Misstrauens „Thermit“ ein.

Hier ist ein Exkurs zum Thema sichere Passwörter aka. Mantren. Wenn du dir der Sicherheit deines Mantras sicher bist, kannst du das überspringen.

Es geht das Gerücht um, dass die Sicherheit von Passwörtern mit ihrer Länge und/oder dem Vorkommen schwierig einzugebender Zeichen zusammenhänge. Beides ist nicht total falsch, aber eher falsch als richtig. Es geht auch das Gerücht um, dass ein Passwort umso sicherer sei, je schwieriger man es sich merken kann. Das geht schon mehr in Richtung richtig, trifft es aber auch noch nicht so ganz. Was tatsächlich stimmt, ist: Ein Passwort ist umso sicherer, je mehr theoretisch mögliche und gleich wahrscheinliche Passwörter es gibt, aus denen dieses nur eines ist (unter der Annahme, dass eine Angreifer*in weiß, aus welcher Menge möglicher Passwörter dieses Passwort zufällig ausgewählt wurde).

Diese Passwörter sind alle gleich sicher: hasenpups, hasenpups123, hasenpups!23, has3npups!23 und Has3npups!23$. Das Passwort kh2a879e3 ist aber echt sicherer. Und das Passwort 9v3twpvmgjmpxcl ist nochmal sicherer. Das Passwort dieSchoeneKatrineljeUndPifPafPoltrie ist wesentlich unsicherer als alle bisher genannten Passwörter. Und zwar aus folgenden Gründen: Die Sicherheit eines Passwortes hängt davon ab, wie viele Versuche man geschätzt braucht, um durch Raten schlussendlich auf das richtige zu kommen. Deshalb ist es eigentlich auch nicht so sinnvoll, von der Sicherheit einzelner bestimmter Passwörter zu reden. Die Frage ist eher, aus welcher Menge von möglichen Passwörtern ein einzelnes Passwort ausgewählt wurde. Wenn die Menge groß ist, dann ist sie sicher, weil es schwer ist, zu erraten, welches Passwort aus der Menge ausgewählt wurde. Wenn ich von der Sicherheit eines einzelnen Passwortes rede, dann meine ich also eigentlich die Sicherheit bzw. Größe der Menge möglicher Passwörter, aus der es gezogen wurde. Die gleich sicheren Passwörter vom Anfang setzen sich aus gängigen Wörterbuch-Wörtern zusammen. Das heißt, in wenigen hunderttausend Versuchen (Das ist nicht viel!) kann man schon drauf kommen. Da hilft es auch nicht, wenn man einzelne Zeichen vorhersehbar ersetzt oder noch ein Sonderzeichen ranhängt. Solche Abwandlungen werden bei Wörterbuch-Angriffen routinemäßig mit abgefrühstückt. hasenpups hat neun Zeichen. Deshalb habe ich danach mit kh2a879e3 ein neun Zeichen langes Passwort zufällig generiert, und zwar aus Kleinbuchstaben und Ziffern. Dieses Passwort ist sicherer als hasenpups und dessen Abwandlungen, weil man zum Erraten sämtliche neunstelligen Zeichenketten durchprobieren müsste und nicht nur solche, die Wörtern aus einer Wörterliste entsprechen. Das sind viel viel mehr. Im Gegensatz zu Wörterbuch-Passwörtern und mehr noch im Gegensatz zu aussprechbaren und gezielt ausgedachten statt ausgewürfelten Passwörtern kann man hier sogar richtig ausrechnen, wie sicher das Passwort ist, statt das nur ganz grob einzuschätzen. Und das Passwort dieSchoeneKatrineljeUndPifPafPoltrie entspricht einem Märchentitel der Brüder Grimm. Davon gibt es nur 251 Stück. Wenn das also deine Strategie ist, Passwörter zu generieren: Nein, tu es nicht!

Hier kommen jetzt ganz viele Zahlenspielereien, die du vielleicht spaßig findest, wenn du Spaß am Taschenrechner hast. Ist aber wirklich nicht wichtig, das nachzuvollziehen.

Überlegen wir mal kurz, wie sicher kh2a879e3 ist, also wieviele theoretisch mögliche Passwörter dieses Formats es gibt, aus denen dieses nur eines ist: Kleinbuchstaben (ohne Umlaute und ß) sind 26 verschiedene Zeichen, Ziffern 0–9 sind zehn Stück. Also haben wir eine Menge von 36 Zeichen, aus der wir auswählen können – für jedes der neun Zeichen einzeln. Wenn das Passwort ein Zeichen lang wäre, dann gäbe es 36 verschiedene Passwörter. Wenn es zwei Zeichen lang wäre, dann gäbe es 36 Möglichkeiten für das erste Zeichen und für jede dieser Möglichkeiten jeweils nochmal 36 Möglichkeiten für das zweite Zeichen, also 36 · 36 = 1296 verschiedene Passwörter aus zwei Zeichen. Mögliche Passwörter aus drei Zeichen gibt es 36 · 36 · 36 = 36³ = 46656 Stück. Und wenn das Passwort wie in diesem Fall neun Zeichen lang ist, dann sind wir schon bei 36⁹ = 101 559 956 668 416 theoretisch möglichen Passwörtern, von denen unseres nur eins ist. Also 100 Billionen, gerundet.

100 Billionen sind jetzt alle möglichen Passwörter. Wer versucht, dein Passwort zu erraten, muss aber nicht alle möglichen Passwörter durchprobieren, weil das richtige wahrscheinlich nicht gerade das letzte getestete ist. Nach 100 Billionen Versuchen hat man das Passwort mit 100%iger Wahrscheinlichkeit erraten. Nach schon 50 Billionen Versuchen hat man es in der Hälfte der Fälle, mit 50%iger Wahrscheinlichkeit, erraten. Mir wäre es lieb, wenn jemand höchstens eine 1%-Chance hat, mein Passwort zu erraten. Wenn ich mit Leuten kommuniziere, reicht es ja, wenn eins der Passwörter dieser Leute geknackt wird, damit unsere Kommunikation offenliegt. Da will ich nicht das schwächste Glied sein. 1% ist ein Hundertstel. Also braucht man 1 Billion Versuche, um das Passwort mit dieser Wahrscheinlichkeit erraten zu haben.

Schließt sich die Frage an: Wieviel ist 1 Billion? Je nach dem, wie genau das Knacken abläuft. Sagen wir mal, das wird auf einem handelsüblichen Computer-Prozessor gemacht. Der kann eine bestimmte Anzahl Elementarbefehle pro Sekunde ausführen. Die Aufgabe, ein mögliches Passwort auf Korrektheit zu prüfen, setzt sich aus mehreren Elementarbefehlen zusammen. Gehen wir aber mal konservativ davon aus, dass einer reicht. Das ist ganz schön pessimistisch gedacht, weil eine Passwortüberprüfung in Wirklichkeit sehr vieler Prozessortakte bedarf, aber lieber zu pessimistisch als zu optimistisch rechnen. Ein Prozessor mit 4 GHz kann 4 Milliarden Befehle pro Sekunde ausführen. Wenn der Prozessor, wie das heute üblich ist, eigentlich aus mehreren Prozessoren besteht, sagen wir 64 Stück (High-End-Rechner), und die alle jeweils zwei Befehle gleichzeitig ausführen können, dann sind wir bei 4 · 64 · 2 = 512. Also 512 Milliarden Befehle pro Sekunde. Upsi. Das ist schon die Hälfte von 1 Billion Passwörtern. Also in der Praxis braucht man wahrscheinlich schon länger als zwei Sekunden, um dieses Passwort mit 1%iger Wahrscheinlichkeit zu knacken, je nach dem, wie viele Befehle ein Prozessor ausführen muss, um ein Passwort zu testen. Das sind schon einige, aber es ist eine grobe Schätzung zur Orientierung. Wir müssen hier nur ganz ganz grob rechnen, denn: Wenn man zigtausend Elementarbefehle braucht, um ein Passwort zu testen, dann lässt man einfach zigtausend derartige Prozessoren gleichzeitig die Passwörter durchprobieren, und schon ist man wieder bei zwei Sekunden. Geht dann nur dementsprechend ins Geld. Bei den großen kommerziellen Cloud-Providern kann man sehr viel Rechenleistung für kurze Zeiten mieten, so dass man nicht tatsächlich abertausende Prozessoren kaufen, verschrauben, mit Strom versorgen und kühlen muss. Der vorgenannte Prozessor kostet in der Cloud gemietet schätzungsweise zirka einzwei Euro pro Stunde und in Zukunft eher weniger.

Das Gute ist aber, dass wir unser Passwort ganz einfach 36-mal so sicher machen können, indem wir es nur ein Zeichen länger machen. Und dann hilft uns das exponentielle Wachstum. Wenn das Passwort nun 10 statt 9 Zeichen lang ist, dann dauert das 1% wahrscheinliche Knacken schon 36 ·2 = 72 Sekunden. Ok. 11 Zeichen: 43 Minuten. Bei 12 Zeichen ist es ein Tag. Du merkst, wir nehmen Fahrt auf. Weiter geht’s: 13 Zeichen – ein Monat. Reicht das? Mir nicht. 14-Zeichen-Passwörter lassen sich in nicht unter drei Jahren mit 1%iger Wahrscheinlichkeit knacken. Vielleicht reicht dir das. Aber komm, weil es grad so schön war, gehen wir noch einen höher. 15 Zeichen. Dann landen wir bei 137 Jahren. Kann sein, dass das jemand durchrechnet. Aber wenn es dich nicht mehr gibt und alle Leute, mit denen du verschlüsselt kommuniziert hast, auch nicht, dann ist es vielleicht egal und die Geheimnisse von einst dürfen endlich ans Tageslicht.

Moment. Vielleicht wird dein Passwort gar nicht auf einem handelsüblichen Computer geknackt, sondern auf einem Supercomputer. Die Rechengeschwindigkeit von Supercomputern wird nicht in Hertz, sondern in FLOPS angegeben, Fließkommaoperationen pro Sekunde. Setzen wir das mal vereinfachend gleich und sagen, eine Passwortüberprüfung dauert genau eine Fließkommaoperation lang. Das ist genauso falsch wie das oben war, weil eine Passwortüberprüfung natürlich nicht nur eine Fließkommaoperation lang dauert. Aber es ist pessimistisch falsch. Deswegen erlauben wir uns das hier mal. Laut aktueller Liste der 500 schnellsten Supercomputer sind die schnellsten Supercomputer grad bei um die 1 000 000 000 000 000 000 = 10¹⁸ FLOPS. Die Geschwindigkeit der Supercomputer hat sich über Jahrzehnte zirka alle vier Jahre verzehnfacht. In letzter Zeit scheint die Kurve etwas abzuflachen. Sagen wir mal alle fünf Jahre verzehnfacht sich die Rechenleistung. Das rechnet sich eh leichter. Wenn jemand in 50 Jahren einen Supercomputer nutzt und die Entwicklung bis dahin genauso weitergeht, dann hat dieser Supercomputer nach 10-mal fünf Jahren 10¹⁰ · 10¹⁸ = 10²⁸ FLOPS. Also in einer Sekunde können dann 10²⁸ Passwörter durchprobiert werden. Wenn der Computer eine Minute läuft, dann sind es 60 · 10²⁸ und wenn er 50 Jahre läuft (ab dann, also 100 Jahre ab jetzt), dann sind es 50 · 366 · 24 · 60 · 60 · 10²⁸ = 1,6 · 10³⁷ Passwörter, die durchprobiert werden. Da die Wahrscheinlichkeit, dass da das richtige dabei ist, nicht größer als 1% sein soll, brauchen wir einen Pool von möglichen Passwörtern, der hundertmal so groß ist, also mindestens 1,6 · 10³⁹ mögliche Passwörter. Ein zufällig generiertes Passwort mit 25 Stellen sollte dann fast sicher genug sein, denn 36²⁵ ist annähernd 10³⁹.

Noch eine andere Überlegung. Das muss gar nicht ein einzelner Computer berechnen. Passwortknacken ist ja sehr gut parallelisierbar. Man kann das einfach auf 36 Computer aufteilen, indem man sagt, der erste probiert nur Passwörter, die mit a anfangen, der zweite nur die mit b anfangen usw. Man kann das auch noch weiter aufteilen auf noch mehr Computer. Wie sieht es mit dem weltweiten Bitcoin-Netzwerk aus? Da sieht man mal, wie viel Rechenkapazität die Menschheit als ganze zusammenschmeißen kann, wenn sie wirklich will und es um viel Geld geht. Bitcoin berechnet SHA256-Hashes. Ist jetzt egal, was das genau ist. Wir nehmen wieder an, dass eine Hashberechnung genauso kompliziert ist wie eine Passwortüberprüfung (womit wir tatsächlich sehr viel näher an der Realität sind als bei den bisherigen Annahmen). Das Ziel bei Bitcoin ist, dass alle zusammen – also die ganze Welt – im Schnitt alle zehn Minuten einen Hash finden, der einem bestimmten Muster entspricht. (Frag nicht.) Dafür, dass das nicht zu schnell und nicht zu langsam geht, wird fortlaufend die difficulty angepasst. Die gibt an, wie viele Hashes im Mittel durchprobiert werden müssen, damit ein passender gefunden wird. Die liegt aktuell bei 57 119 871 304 635, also zwischen 10¹³ und 10¹⁴, Tendenz leicht steigend. Gehen wir davon aus, dass die Difficulty nicht absehbar über 10¹⁷ steigen wird. Wenn ein weltweites Passwortknacknetzwerk im Mittel zehn Minuten braucht, um ein Passwort zu knacken, (also 50% der möglichen Passwörter nach zehn Minuten durchsucht hat) dann braucht es 20 Minuten, um das Passwort mit 100%iger Sicherheit zu finden. (Falls es die Passwörter systematisch durchtestet, was das reale Bitcoin-Netzwerk nicht tut. Es probiert wild und unkoordiniert die Hashes durch. Aber egal jetzt.) Und zwar eins aus 10¹⁷ möglichen Passwörtern. Wenn das aber nicht 20 Minuten, sondern 100 Jahre dauern soll, dann brauchen wir 5 · 24 · 366 · 100 · 10¹⁷ = 4,4 · 10²³ mögliche Passwörter. Nein, noch hundertmal so viele, weil die Knackwahrscheinlichkeit nicht bei 100%, sondern bei 1% liegen soll, also 4,4 · 10²⁵ mögliche Passwörter. Da kommen wir mit 16 Zeichen schon annähernd und mit 17 Zeichen gut hin, denn 36¹⁷ = 2,8 · 10²⁶.

Warum ist das jetzt wieder so wenig? Das weltweite Bitcoin-Netzwerk kann gar nicht doll viel schneller Passwörter ausrechnen als der 4-GHz-Prozessor zwei Absätze drüber? Doch, bestimmt. Nur ist eine SHA256-Berechnung wohl doch ein ganzes Stück aufwendiger als ein einzelner Elementarbefehl eines Prozessors. Die genauen Zahlen sagen also wirklich nicht so sehr viel aus. Es ist nur eine Überschlagsrechnung.

Solche parallelisierbaren Berechnungen werden üblicherweise auf speziellen Prozessoren ausgeführt, die sich unter anderem auf Grafikkarten befinden. Hier hat jemand mit einem mit mehreren guten Grafikkarten ausgestatteten Rechner mal testweise verschiedene Arten, Passwörter zu kodieren, durchgetestet, wie schnell die jeweils geknackt werden können. Stellt sich raus: Wenn du schlechte veraltete Software verwendest, die dein Passwort unsicher abspeichert, dann können auf die Weise bis zu hunderte Milliarden (10¹²) Passwortkandidaten pro Sekunde durchprobiert werden. Wenn wir pessimistisch annehmen, dass du so schlechte Software verwendest, außerdem dass die Grafikkarten-Technik sich weiterentwickelt (Die verwendete Grafikkarte ist mittlerweile schon nicht mehr die schnellste verfügbare.) und demnächst die tausendfache Geschwindigkeit möglich ist und auch dass böswillige Menschen das nicht als kleines Hobbyprojekt betreiben, sondern zehntausend solche Rechner haben, dann können also pro Sekunde 10¹⁹ Passwörter getestet werden. Wenn es 10⁷ Sekunden, also ein Jahr, dauern soll, alle durchzuprobieren, brauchen wir 10²⁶ Passwörter. Wenn es tausend Jahre dauern soll, ein hundertstel der Passwörter durchzuprobieren, dann brauchen wir 10³¹ mögliche Passwörter. Mit 20 Zeichen langen Passwörtern kommst du auf diese Anzahl.

Zusammengefasst: Wenn du dein Passwort aus einzelnen zufällig bestimmten Zeichen (Buchstaben und Ziffern) zusammensetzt, dann sind 10 Zeichen lange Passwörter eigentlich nicht sicher, aber besser als nix. 15 Zeichen lange Passwörter sind schon ordentlich sicher. Wenn du Extrasicherheit haben willst, dann nimm 20 Zeichen, und wenn du ein Freak bist, dann nimm 25. Alles darüber hinaus hat weniger mit Sicherheit als mit Rumposen zu tun. Aber wichtig: Das gilt nur, wenn das Passwort wirklich zufällig erzeugt wurde, aus einzelnen zufälligen Zeichen, nicht aus Silben oder Wörtern zum Beispiel. Du darfst es dir nicht ausdenken, denn Ausdenken ist nicht zufällig genug. Es ist auch nicht zufällig genug, wenn du einzelne Buchstaben aus einem Buch zusammen suchst, denn jede Sprache hat eine Vorliebe für bestimmte Buchstaben. Damit sind also nicht mehr alle Buchstaben in deinem Passwort gleich wahrscheinlich und dein Passwort ist unsicher. Es ist auch nicht zufällig genug, wenn du wild auf der Tastatur rumkloppst, sondern du brauchst einen Zufallsgenerator. Passwortmanager haben normalerweise eine Passwort-generieren-Funktion. Webseiten, die dir Passwörter ausspucken, sind aus naheliegenden Gründen absolut nicht zu empfehlen.

Ein Wort zu Passwortmanagern.

Passwortmanager sind sowieso äußerst empfehlenswert. Leg dir am besten einen zu, wenn du noch keinen benutzt. Dass der Passwortmanager frei ist, ist wichtig, weil freie Software zwar keine Garantie für Sicherheit bietet, aber eine Voraussetzung dafür ist. KeePassXC ist gut. Ein Passwortmanager ist auch deshalb sehr empfehlenswert, weil du bei verschiedenen Diensten, denen gegenüber du dich per Passwort authentifizierst, niemals dasselbe Passwort verwenden darfst.

Der Passwortmanager generiert dir für jeden Dienst ein neues sehr sicheres Passwort und speichert die alle in einer verschlüsselten Datenbank, die du mit deinem Hauptpasswort entsperrst. Dieses Hauptpasswort ist das einzige, das du dir merkst. Wichtig ist, dass du das niemals außerhalb deiner eigenen Computer eingibst, denen du vertraust. Also du darfst es zum Beispiel nie im Internet eingeben. Für deinen geheimen OpenPGP-Schlüssel kannst du zur Vereinfachung dasselbe Passwort verwenden wie für deinen Passwortmanager, wenn du dir sicher bist, dass dieses Passwort deinen eigenen Rechner niemals verlässt. (Also nicht aus Versehen als Loginpasswort bei deinem E-Mail-Provider eingeben zum Beispiel. Und auch nicht auf dem Smartphone eingeben, denn das ist kein vertrauenswürdiger Computer.) Das beste wäre aber wirklich, wenn du dein eines Passwort, das du dir merkst, nur für die Passwortdatenbank benutzt und das OpenPGP-Passwort im Passwortmanager gespeichert hast und dir nicht merkst.

Wichtig ist auch, dass du deine Passwortdatenbank in deine Backupstrategie mit aufnimmst. Wenn du diese Datei verlierst, dann hast du ein Problem.

Diese 15-20-25-Regel bezieht sich auf Passwörter, die aus 36 verschiedenen Zeichen aufgebaut werden können, also Ziffern und Kleinbuchstaben ohne Umlaute. Je mehr verschiedene Zeichen für ein Passwort infrage kommen, desto kürzer kann es bei gleicher Sicherheit sein. Aber ohne das jetzt vorzurechnen, behaupte ich (Du kannst es selber nachrechnen.): Die kürzeren Passwörter wiegen deren kompliziertere Eingabe nicht auf. Wenn du zum Beispiel noch Großbuchstaben dazu nimmst, dann hast du für jedes Zeichen nicht 36 Möglichkeiten, sondern 62. Wenn du dafür dein Passwort um ein paar Zeichen kürzer machst, dann musst du aber für jeden Großbuchstaben zwei Tasten drücken (die Umschalttaste noch dazu für Großschreibung) und kommst so auf mehr Tastenanschläge bei gleicher Sicherheit.

Ein 20 Zeichen langes zufällig generiertes Passwort merkt sich leichter als du denkst. Vor allem: Da du jetzt einen Passwortmanager benutzt, ist das das einzige Passwort, das du dir merken musst. Du hast nur dieses eine Passwort und du gibst es mindestens zehnmal pro Tag ein. Ich bin mir sicher, dass du es dir gut merken wirst. Mein Tipp zum Merken: Unterteile das Passwort in Fünfergruppen. Also fz7nc d7qc9 3ah8h 047ux. Die Leerzeichen musst du natürlich nicht mit eingeben. Die sind nur zur optischen Unterteilung. Fang vorne an; merke dir die erste Fünfergruppe, indem du sie ein paar mal eingibst. Das geht schnell. Nach weniger als zehn Eingaben hast du die auswendig. Dann nimm die zweite Fünfergruppe dazu und lerne die beide zusammen auswendig. Dann die ersten drei, und dann alle vier zusammen. Jeweils einige Male eingeben und du hast das intus. Mach dasselbe dann eine halbe Stunde später nochmal und guck drei Stunden später, ob du das Passwort noch kennst. Am nächsten Tag musst du vielleicht nochmal gucken, aber am übernächsten Tag gibt es keine Probleme mehr, du wirst sehen.

Es gibt auch Ansätze, mit Hilfe von Wortlisten „merkbarere“ Passwörter zufällig zu generieren. Vielleicht passt das für dich, aber ich bin kein Fan davon, weil das nur die Länge des Passwortes unnötig streckt. Kurzfristig (in den ersten einzwei Tagen) mag das ganz nett sein, wenn ich mir das Passwort ein bisschen leichter merken kann, aber auf lange Sicht freue ich mich mehr über ein genauso sicheres, das nur halb so lang ist, bei dem ich mich also auch nur halb so viel vertippe.

Wenn du dich dazu entscheidest, dein Passwort aus einzelnen Wörterbuch-Wörtern aufzubauen, damit du es dir leichter merken kannst, dann vergiss das, was ich oben geschrieben habe über die Länge von hinreichend sicheren Passwörtern. Denn die Länge von Passwörtern spielt ja selber eigentlich gar keine Rolle. Wichtig ist nur, wieviel Zufall du in die Erzeugung des Passwortes reingekippt hast (Fachsprache: Entropie), also wieviele theoretisch mögliche Passwörter es nach deiner Passworterzeugungsregel gibt, aus denen du eins ausgewählt hast. Wenn du für jedes einzelne Zeichen 36 Möglichkeiten hast und dein Passwort aus 15 unabhängig voneinander zufällig ausgewürfelten Zeichen aufbaust, dann fällt dabei eins von 36¹⁵ = 221 Trilliarden möglichen Passwörtern raus. Dementsprechend: Wenn du die oben verlinkte Diceware-Wörterliste verwendest und damit für jedes einzelne Wort 7776 gleichwahrscheinliche Optionen hast, dann kommst du mit sechs aneinandergehängten Wörtern auf 7776⁶ mögliche Passwörter, was ebenfalls 221 Trilliarden sind, also zwei so generierte Passwörter sind gleich sicher, wenn du sie auswürfelst (und nicht irgendwie „schöne“ oder „passende“ Wörter raussuchst). Das aus aussprechbaren Wörtern aufgebaute Passwort wird länger als 15 Zeichen sein. Es kann sogar unterschiedlich lang sein, je nach dem, aus welchen Wörtern es genau besteht, aber der reingesteckte Zufall ist immer derselbe.

Begehe nicht den Fehler, dir eine besonders ausgefuchste Passwortbildungsvorschrift auszudenken, bei der du gar keinen oder fast gar keinen Zufall reinsteckst. Zum Beispiel: Gucken, auf welcher Zahl von 1 bis 60 gerade der Sekundenzeiger steht, dein Lieblingsbuch auf dieser Seite aufschlagen und dort den letzten Satz als Passwort nehmen. Der Zufall ist dabei viel zu gering, denn es gibt insgesamt nur 60 verschiedene Passwörter. Das ist Quatsch.

Eine KI anzuweisen, ein Gedicht über Pferdemist zu schreiben, und das Ergebnis als Passwort zu verwenden, ist auch eine ganz schlechte Idee. Erstens ist es natürlich immer eine schlechte Idee, Passwörter von Websites o. ä. zu beziehen. Zweitens steckt die KI nur ganz ganz wenig Zufall in die Gedichterzeugung. Der erste Vers ist vielleicht noch ein bisschen zufällig. Die darauffolgenden Verse werden so gebildet, dass sie zu den jeweils vor ihnen stehenden Versen passen. Also fast kein Zufall.

Superkrasse Passworterzeugungsideen sind allesamt superscheiße. Du machst es dir damit viel zu kompliziert. Ein Passwort wirklich zufällig zu erzeugen, ist einfach und effizient. Mach einfach das.

Wenn du befürchtest, dein Passwort irgendwann doch mal zu vergessen, dann könntest du es an einem wirklich sicheren Ort ablegen. Oder besser noch aufgeteilt auf zwei oder drei Orte, so dass ein unbefugter Zugriff auf einen einzelnen Ort nur einen Teil deines Passwortes offenlegt, nicht gleich das ganze. Wenn du dir für den Anfang dein Passwort aufschreiben willst, bis du dir sicher bist, dass du es nicht mehr vergisst, dann schreib es bitte nicht digital auf, sondern mit einem Stift auf einem Zettel. Digitale Daten kannst du nämlich nicht wieder löschen, oder nicht so einfach wie analoge. Den Zettel verbrennst du dann, wenn du ihn nicht mehr brauchst, und behältst ihn bis dahin sicher bei dir. Du kannst es auch auf Klopapier schreiben. Das musst du nicht verbrennen. Das zerfällt im Wasser nach kurzer Zeit.

Wenn du zu lange überlegst, mit welchem Mantra du deinen Schlüssel sichern willst, bricht der Prozess ab und du musst den Schlüssel nochmal neu erzeugen. Beim zweiten Durchspielen der ganzen Fragen bist du aber bestimmt schon geübter und du kannst dir dann ja auch vorher überlegen, welches Mantra du benutzen willst. Nachdem du dein Mantra zweimal eingegeben hast, endet GnuPG mit ein paar abschließenden Bemerkungen:

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: /home/schnuffelchen/.gnupg/trustdb.gpg: trustdb created
gpg: directory '/home/schnuffelchen/.gnupg/openpgp-revocs.d' created
gpg: revocation certificate stored as '/home/schnuffelchen/.gnupg/openpgp-revocs.d/F096A0F52BDF836862827E448D631EC35A0B6427.rev'
public and secret key created and signed.

pub   rsa4096 2342-02-16 [C] [expires: 2342-02-30]
      F096A0F52BDF836862827E448D631EC35A0B6427
uid                      Schnuffelchen <schnuffelchen@pkx.be>

Hier steht, dass bestimmte Dateien und Verzeichnisse angelegt wurden, mit denen GnuPG arbeitet. Dann steht hier, dass ein Widerrufszertifikat erzeugt und in einer bestimmten Datei abgelegt wurde. Dazu sag ich gleich noch was. Und dann stehen da allgemeine Infos über deinen neuen Schlüssel. Es steht da, dass hier die Infos für den öffentlichen Schlüssel angezeigt werden (pub), welchen Algorithmus (hier RSA mit 4096 Bit Schlüssellänge) der Schlüssel verwendet, wann er erzeugt wurde, für welchen Einsatzzweck der Hauptschlüssel benutzt werden kann (das C steht für zertifizieren), wann er ungültig wird, darunter steht der Fingerabdruck und darunter steht, wem der Schlüssel gehört (uid steht für User-Identifikation).

Wo GnuPG seine Daten ablegt

Das neue OpenPGP-Schlüsselpaar ist jetzt in deiner lokalen GnuPG-Schlüsseldatenbank gespeichert. Welche Schlüssel du da so drin hast, kannst du mit den Kommandozeilenargumenten -k und -K nachgucken. Das kleine k zeigt öffentliche Schlüssel an und das große K zeigt geheime Schlüssel an. Gib einfach mal folgenden Befehl mit kleinem k ein:

gpg -k

Daraufhin sollten wieder ungefähr dieselben Infos über deinen öffentlichen Schlüssel angezeigt werden wie oben:

gpg: checking the trustdb
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: next trustdb check due at 2342-03-24
/home/schnuffelchen/.gnupg/pubring.kbx
-----------------------------------
pub   rsa4096 2342-02-16 [C] [expires: 2342-02-30]
      F096A0F52BDF836862827E448D631EC35A0B6427
uid           [ultimate] Schnuffelchen <schnuffelchen@pkx.be>

Die ersten Zeilen sagen, dass GnuPG hier einmal durch die Schlüsseldatenbank durchgegangen ist und geguckt hat, welche Schlüssel vertrauenswürdig sind. Das kannst du ignorieren. GnuPG macht das in regelmäßigen Abständen und zusätzlich immer dann, wenn neue Schlüssel dazugekommen sind. Wenn du denselben Befehl gleich nochmal ausführst, dann erscheinen die ersten vier Zeilen also nicht mehr.

Darunter (über den Bindestrichen) steht, in welcher Datei die öffentlichen Schlüssel abgespeichert sind, die GnuPG hier anzeigt. In deinem persönlichen Verzeichnis (das je nach Betriebssystem auch woanders liegen kann) gibt es ein GnuPG-Verzeichnis, das normalerweise .gnupg heißt. Der Punkt am Anfang des Namens hat bei allen Betriebssystemen außer Windows zur Folge, dass das Verzeichnis „versteckt“ ist. Also es ist ganz normal vorhanden, wird aber in der Standardansicht nicht angezeigt. Unter Windows kann das GnuPG-Verzeichnis zum Beispiel C:\Users\schnuffelchen\AppData\Roaming\gnupg sein. Du kannst in dieses Verzeichnis reingucken und dich vergewissern, dass deine öffentlichen Schlüssel vorhanden sind: Wenn in der Ausgabe von gpg -k die Datei pubring.kbx genannt wird, dann sollte die Datei vorhanden sein. Vielleicht heißt die Datei bei dir auch anders, wenn du eine wesentlich ältere GnuPG-Version verwendest. Dann heißt sie vielleicht pubring.gpg. Aber egal. Da ist dein öffentlicher Schlüssel drin und auch alle anderen öffentlichen Schlüssel, die du später einsammelst von anderen Leuten, werden in dieser Datei landen. Wenn in der Ausgabe von gpg -k kein Dateiname genannt wird, sondern da nur [keyboxd] steht, dann sind deine öffentlichen Schlüssel wahrscheinlich in der Datei public-keys.d/pubring.db in deinem GnuPG-Verzeichnis. Wichtig für dich zu wissen ist vor allem, dass diese Informationen in dem Verzeichnis .gnupg liegen oder wie auch immer das bei dir heißt. Wo genau das Verzeichnis liegt, kannst du auch mit dem Befehl gpg --version nachgucken: In der Ausgabe ist das dann als „Home“-Verzeichnis aufgeführt. Das heißt, dieses Verzeichnis musst du mit einem guten Backup sichern.

Um wieder zu der Ausgabe von gpg -k zurückzukommen: Was unter den Bindestrichen steht, kennst du schon von der Schlüsselerzeugung oben. Es steht hier nur eine Information zusätzlich dabei. In der uid-Zeile steht noch, dass du diesem Schlüssel (genauer: der einen User-ID von diesem Schlüssel) „ultimativ“ vertraust (weil es dein eigener Schlüssel ist).

Zu Vertrauen könnte man sicherlich ganz viel sagen, aber ich lass es, weil ich finde, dass das wirklich nicht wichtig ist. Ganz kurz: Zusätzlich dazu, dass du öffentliche Schlüssel anderer Leute aus vertrauenswürdigen Quellen beziehst und Fingerabdrücke abgleichst, um sicherzustellen, dass du wirklich die richtigen öffentlichen Schlüssel deiner Kommunikationspartner*innen hast, gibt es auch noch die Möglichkeit, Vertrauen über Bande herzustellen, und GnuPG kann dir dieses indirekte Vertrauen berechnen. Wenn du das benutzen willst, dann kannst du es später immer noch nachlesen.

Schauen wir mal weiter, was GnuPG abgespeichert hat. Neben deinen öffentlichen Schlüsseln ist in deinem GnuPG-Verzeichnis ein Verzeichnis namens private-keys-v1.d, in dem deine geheimen Schlüssel liegen (mit den jeweiligen Mantren verschlüsselt natürlich). Mit dem großen K als Kommandozeilenargument kannst du dir deine geheimen Schlüssel auflisten lassen:

gpg -K
/home/schnuffelchen/.gnupg/pubring.kbx
-----------------------------------
sec   rsa4096 2342-02-16 [C] [expires: 2342-02-30]
      F096A0F52BDF836862827E448D631EC35A0B6427
uid           [ultimate] Schnuffelchen <schnuffelchen@pkx.be>

Verwirrenderweise steht in der ersten Zeile auch wieder pubring.kbx, obwohl hier nicht die dort abgespeicherten öffentlichen Schlüssel, sondern die geheimen Schlüssel angezeigt werden, wie an dem Kürzel sec statt pub erkennbar ist.

Da du dir jetzt einen Überblick verschafft hast und weißt, dass alle wichtigen Dateien, die deine Schlüsselsammlung betreffen, in diesem GnuPG-Verzeichnis abgelegt sind, ist es wichtig, dass du dieses Verzeichnis (also .gnupg) in dein normales regelmäßiges Backup mit aufnimmst. Stell sicher, dass du dieses Verzeichnis mitsamt seinem Inhalt niemals verlierst, auch wenn dein Datenträger abraucht, dir dein Rechner abgezogen wird oder du eine Überschwemmung verursachst. Das GnuPG-Verzeichnis solltest du dezentral speichern, damit du das nicht verlierst. Wenn du mal aus Versehen irgendwas kaputt gemacht hast, einen Schlüssel gelöscht hast, den du noch brauchtest, oder ein ernsthaftes Problem hast und ein komplett neues System aufsetzt, dann kannst du einfach GnuPG installieren, ein eventuell vorhandenes Verzeichnis .gnupg löschen und dafür dein gebackupptes einsetzen und du wirst alle deine Schlüssel wieder haben.

Schlüssel nachbearbeiten

Wir müssen noch ein bisschen Feinschliff betreiben, um das neu erzeugte Schlüsselpaar wirklich benutzen zu können. Wenn du nach der Anleitung oben vorgegangen bist, dann hast du jetzt einen OpenPGP-Schlüssel mit einem Hauptschlüssel, der nur zum Zertifizieren benutzt werden kann, und ohne Unterschlüssel. Darauf aufbauend werden wir jetzt noch zwei Unterschlüssel erzeugen: einen zum Signieren und einen zum Verschlüsseln.

Zum Nachbearbeiten von Schlüsseln, die du in deinem Schlüsselbund gespeichert hast, gibt es das Kommandozeilenargument --edit-key. Dahinter gibst du als weiteres Argument an, welchen Schlüssel du bearbeiten willst. Das kann irgendein Teil einer User-ID sein, der den Schlüssel eindeutig bestimmt. Du kannst zum Beispiel die E-Mail-Adresse angeben, wenn du nur einen Schlüssel mit dieser E-Mail-Adresse hast. Wenn du ganz sicher sein willst, dass du den richtigen Schlüssel auswählst, dann kannst du auch den Fingerabdruck angeben. Also gib zum Beispiel ein:

gpg --edit-key schnuffelchen@pkx.be

Oder:

gpg --edit-key F096A0F52BDF836862827E448D631EC35A0B6427

Es reicht auch ein Teil einer User-ID; also zum Beispiel uff, wenn du nur einen Schlüssel hast, in dessen User-IDs uff vorkommt. Wenn du den Befehl abschickst, dann wird dir zuerst angezeigt, welchen Schlüssel genau du jetzt bearbeiten kannst, und dann hast du die Möglichkeit, GnuPG-spezifische Befehle auf diesen Schlüssel bezogen einzugeben:

gpg --edit-key uff
gpg (GnuPG) 2.3.8; Copyright (C) 2021 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

sec  rsa4096/8D631EC35A0B6427
     created: 2342-02-16  expires: 2342-02-30  usage: C   
     trust: ultimate      validity: ultimate
[ultimate] (1). Schnuffelchen <schnuffelchen@pkx.be>

gpg>

Aus dieser Schlüsselbearbeitungsansicht kommst du mit Enter Strg-D raus und zurück auf deine Kommandozeile. Damit wird alles abgebrochen. Wenn du deine Bearbeitungen speichern willst, dann gibst du stattdessen den Befehl save ein. (Unter Windows funktioniert Strg-D nicht. Da kannst du stattdessen Enter Strg-Z Enter probieren oder quit eingeben.) Aber erstmal bleiben wir hier noch in der Schlüsselbearbeitung.

Du kannst auch Schlüssel anderer Leute bearbeiten (in beschränktem Maße), von denen du nur den öffentlichen Schlüssel hast. In diesem Fall wird erkannt und angezeigt, dass das dein eigener Schlüssel ist, denn du hast den geheimen Schlüssel. Dadurch hast du mehr Möglichkeiten bei der Bearbeitung. Zum Beispiel kannst du mit dem Befehl addkey einen Unterschlüssel hinzufügen. Dabei wirst du wieder durch einen Fragebogen geleitet und wir gehen das hier mal zusammen durch. Also hinter der Eingabeaufforderung gpg> gib bitte ein:

addkey

Dir werden jetzt mögliche Algorithmen für den neu zu erzeugenden Unterschlüssel angeboten, wie du es schon gewohnt bist:

gpg> addkey
Please select what kind of key you want:
   (3) DSA (sign only)
   (4) RSA (sign only)
   (5) Elgamal (encrypt only)
   (6) RSA (encrypt only)
  (10) ECC (sign only)
  (12) ECC (encrypt only)
  (14) Existing key from card
Your selection?

Ok, nicht ganz so wie du es gewohnt bist, denn es fehlen ein paar Optionen. Das liegt daran, dass wir diesmal --expert nicht mit übergeben haben. Wenn du vorher stattdessen die komplette Befehlszeile

gpg --expert --edit-key uff

eingegeben hättest, dann würden dir hier auch wieder alle Optionen angeboten werden. Aber normalerweise solltest du das nicht brauchen.

Die Reihenfolge ist egal. Wir fangen jetzt mal an mit dem Unterschlüssel zum Signieren. Dafür können wir uns zwischen DSA, RSA und ECC entscheiden. Wie oben empfehle ich, nur RSA oder ECC zu verwenden. Gib also die Nummer 4 oder 10 ein.

Dir wird jetzt wieder wie oben bei der Schlüsselerzeugung die Frage nach der Schlüssellänge (RSA) bzw. der Kurve (ECC) gestellt. Lies dort nochmal nach, wenn du nicht mehr weißt, was du hier eingeben sollst.

Als nächstes erscheint wieder die Frage nach der Gültigkeitsdauer.

Your selection? 4
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (3072) 4096
Requested keysize is 4096 bits
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0)

Einerseits müssten wir uns diesmal darüber nicht so viele Gedanken machen, denn wenn der Hauptschlüssel abgelaufen ist, dann sind die Unterschlüssel auch nicht mehr verwendbar. Die Ungültigkeit des Hauptschlüssels wird quasi vererbt. Das heißt, du könntest hier theoretisch einfach den voreingestellten Wert 0 lassen, so dass dein Unterschlüssel immer genau dann gültig ist, wenn dein Hauptschlüssel gültig ist.

Andererseits kann es, wenn du später Poweruser wirst, den Fall geben, wo du den jetzt erzeugten Unterschlüssel nicht mehr weiter benutzen willst, den Hauptschlüssel aber schon. Wenn du dann den Widerruf deines alten Unterschlüssels nicht immer mitschleppen willst, sondern den alten Unterschlüssel einfach löschst (damit dein Schlüssel insgesamt nicht ins Unermessliche anwächst), dann wirst du dich freuen, damals ein Ablaufdatum für den Unterschlüssel gesetzt zu haben. Das ist jetzt vielleicht relativ hypothetisch; möglicherweise verstehst du es auch noch gar nicht. Das Thema Widerruf kommt ja auch erst später im Verlauf dieser Anleitung. Zur Vereinfachung kannst du jetzt einfach 0 eingeben und dir später dann für deine Poweruser-Zwecke einen neuen Hauptschlüssel erzeugen.

Wenn du das so bestätigst, dann wirst du nach dem Mantra deines geheimen Schlüssels gefragt, denn um die Existenz dieses neuen Unterschlüssels zertifizieren zu können, brauchst du deinen geheimen Hauptschlüssel.

Key is valid for? (0) ↵
Key does not expire at all
Is this correct? (y/N) y
Really create? (y/N) y

Dialogfenster mit der Aufforderung, die Passphrase für den geheimen Schlüssel einzugeben, und einem Eingabefeld für die Passphrase; der Schlüssel wird mit User-ID, der Angabe “4096-bit RSA key”, der Schlüssel-ID 8D63…6427 und Erzeugungsdatum 2342-02-16 eindeutig bestimmt

Sobald du das Mantra richtig eingegeben hast, wird begonnen, den neuen Unterschlüssel zu erzeugen. Du wirst dann darüber informiert, wie dein Schlüssel mit Unterschlüssel jetzt aussieht, und bekommst eine neue Eingabeaufforderung:

We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.

sec  rsa4096/8D631EC35A0B6427
     created: 2342-02-16  expires: 2342-02-30  usage: C   
     trust: ultimate      validity: ultimate
ssb  rsa4096/C3D5B3102A7689F0
     created: 2342-02-17  expires: never       usage: S   
[ultimate] (1). Schnuffelchen <schnuffelchen@pkx.be>

gpg>

Der Hauptschlüssel kann also, das sagt das C, zum Zertifizieren benutzt werden und der Unterschlüssel kann zum Signieren benutzt werden, wofür das S steht.

Gib jetzt noch einmal den Befehl addkey ein, um den zweiten Unterschlüssel zum Verschlüsseln zu erzeugen. In der ersten Frage wählst du eine der Verschlüsselungsoptionen aus, also Elgamal (5), RSA (6) oder ECC (12). Am besten beschränkst du dich auch hier auf RSA oder ECC. Wenn du alle Fragen durchgespielt hast, dann hast du zwei Unterschlüssel:

gpg> addkey
Please select what kind of key you want:
   (3) DSA (sign only)
   (4) RSA (sign only)
   (5) Elgamal (encrypt only)
   (6) RSA (encrypt only)
  (10) ECC (sign only)
  (12) ECC (encrypt only)
  (14) Existing key from card
Your selection? 6
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (3072) 4096
Requested keysize is 4096 bits
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0) ↵
Key does not expire at all
Is this correct? (y/N) y
Really create? (y/N) y
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.

sec  rsa4096/8D631EC35A0B6427
     created: 2342-02-16  expires: 2342-02-30  usage: C   
     trust: ultimate      validity: ultimate
ssb  rsa4096/C3D5B3102A7689F0
     created: 2342-02-17  expires: never       usage: S   
ssb  rsa4096/7FA7A47FD584585C
     created: 2342-02-17  expires: never       usage: E   
[ultimate] (1). Schnuffelchen <schnuffelchen@pkx.be>

gpg>

Das E zeigt an, dass dein zweiter Unterschlüssel zum Verschlüsseln verwendet werden kann. ssb steht übrigens für secret subkey, also dass das ein Unterschlüssel ist, zu dem du den geheimen Schlüssel hast.

Da du schon mal hier bist, könntest du auch gleich weitere Identitäten anlegen, falls du daran Bedarf hast. Ein OpenPGP-Schlüssel kann nicht nur eine User-ID (mit Namen, E-Mail-Adresse und Kommentar) enthalten, sondern beliebig viele.

Wenn du zum Beispiel mehrere E-Mail-Adressen hast, für die du denselben Schlüssel verwenden willst, dann kannst du die Adressen alle in den Schlüssel mit eintragen. Dazu dient der Befehl adduid:

gpg> adduid
Real name: Dr. Schnuff
Email address: baerbel.schnuff@flowerpower.enterprises
Comment: 
You selected this USER-ID:
    "Dr. Schnuff <baerbel.schnuff@flowerpower.enterprises>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o

sec  rsa4096/8D631EC35A0B6427
     created: 2342-02-16  expires: 2342-02-30  usage: C   
     trust: ultimate      validity: ultimate
ssb  rsa4096/C3D5B3102A7689F0
     created: 2342-02-17  expires: never       usage: S   
ssb  rsa4096/7FA7A47FD584585C
     created: 2342-02-17  expires: never       usage: E   
[ultimate] (1)  Schnuffelchen <schnuffelchen@pkx.be>
[ unknown] (2). Dr. Schnuff <baerbel.schnuff@flowerpower.enterprises>

gpg>

Dass das Vertrauen im Falle der neuen User-ID unbekannt sein soll, das muss dich nicht beunruhigen. Das ist nur vorübergehend, weil die neue User-ID gerade erst erstellt wurde. Später kannst du dich mit

gpg -K

versichern, dass das Vertrauen für beide User-IDs ultimativ ist.

Ein warnendes Wort sei mir an dieser Stelle noch gestattet: Obwohl es technisch geht, sieh bitte davon ab, für völlig verschiedene Einsatzzwecke denselben OpenPGP-Schlüssel mit verschiedenen User-IDs zu verwenden. Wenn du ein Dienstpostfach und ein Privatpostfach hast, dann kannst und solltest du für die beiden Postfächer unterschiedliche OpenPGP-Schlüssel verwenden, denn es hat sich in der Kryptographie als guter Stil herausgestellt, ein mögliches Desaster dadurch zu begrenzen, dass jeder einzelne Schlüssel nur möglichst wenige geheime Nachrichten verschlüsselt: Wenn zum Beispiel einer deiner beiden geheimen Schlüssel in falsche Hände gerät, dann ist nur entweder deine dienstliche oder deine private Kommunikation gebrochen, nicht beide auf einmal. OpenPGP-Schlüssel sind kostenlos, du solltest nicht mit ihnen geizen.

Mit dem Befehl save beendest du GnuPG und kommst wieder zur Kommandozeile zurück.

Nachrichten signieren

Da du jetzt einen signierfähigen Unterschlüssel hast, kannst du anfangen, deine Nachrichten an andere Leute zu signieren. Wir können das mal ausprobieren. Folgender Befehl erzeugt eine Signatur des eingegebenen Textes:

gpg -as

Wahrscheinlich hast du schon bemerkt, dass einbuchstabige Argumente (wie -k und -h) mit nur einem Bindestrich eingeleitet werden und mehrbuchstabige (wie --edit-key und --version) mit zwei Bindestrichen. Hier steht jetzt ein Bindestrich und zwei Buchstaben. Das bedeutet, das sind eigentlich zwei einzelne Argumente, die platzsparend zusammen geschrieben wurden. Statt gpg -as könntest du auch gleichbedeutend gpg -a -s schreiben.

-a hat zur Folge, dass die Ausgabe des Befehls nur aus Buchstaben, Zahlen und ganz wenigen normalen Sonderzeichen besteht. Wenn du -a weglässt, dann wird die Ausgabe des Befehls ganz schlimmer Kauderwelsch sein, den du nicht einfach als Text kopieren kannst. Oft ist es deswegen sinnvoll, -a mit anzugeben.

Mit dem Argument -s wird eine Nachricht signiert. Und zwar mit dem signierfähigen geheimen Schlüssel, den GnuPG zuerst findet. Wenn du sowieso nur einen hast, dann gibt es hier keine Missverständnisse. Falls du mehrere geheime Schlüssel erzeugt hast und GnuPG den falschen auswählt, dann gib zusätzlich das Argument -u an und dahinter einen Teil einer User-ID des richtigen Schlüssels oder den Fingerabdruck:

gpg -asu schnu

Wenn du den Befehl abschickst, dann passiert verwirrenderweise erstmal anscheinend gar nichts. GnuPG wartet still auf Eingaben. Du gibst jetzt hier deine Nachricht ein. Also tipp einfach irgendwas. Wenn du fertig bist, dann drückst du noch einmal die Enter-Taste, um eine neue Zeile zu beginnen, und drückst dann Strg-D, um die Eingabe deiner Nachricht abzuschließen (bzw. Strg-Z und noch einmal Enter unter Windows; das erwähne ich ab jetzt nicht immer nochmal). GnuPG fragt dich dann nach deinem Mantra (falls es nicht noch zwischengespeichert ist – das passiert manchmal, wenn du es vor nicht allzu langer Zeit schon mal eingegeben hast), berechnet die signierte Nachricht und gibt sie aus. (Wenn du diesen Eingabemodus abbrechen willst, ohne etwas zu signieren, dann kannst du auch hier jederzeit Strg-C drücken. Dann kommst du gleich wieder zurück zur Kommandozeile.)

gpg -asu schnuff
Hiermit bestätige ich, Schnuffelchen, dass ich den Schatz an Karlheinz übergeben habe.
Karlheinz darf damit machen, was er will.
Strg-D
-----BEGIN PGP MESSAGE-----

owGbwMvMwMF4+OpmAa2yzg+MpzuTGFJ4mo08MlOLcjNLFJJSi0sOLynJTE9VyCwu
0VEITs7IK01LS81JzkjN01FISSwuVshMzlBISc0DySWWVCkk5il4JxblZKRm5lUp
GDkYjMUUWZarKTapaIt9MdK4tAnmVlamFJ6W9aIyxchOcijIrtBLSmXg4hSAqZsx
…
F8bnj889uH3+b2ZI4bO1ehcXvjBdVvfORH/m4vlhi2tXRt6eN1lj9kHnhceEA09m
ftl4dYZYobd6Je/23mwOHikuz1V51f9KZqifPfK1LU3hzJo3E24xV3D+btjbwm20
XumUr7n5l/nb30fGqJ0FAA==
=TGHH
-----END PGP MESSAGE-----

Das, was GnuPG da ausgegeben hat, also der Teil von BEGIN PGP MESSAGE bis END PGP MESSAGE, ist die signierte Nachricht. Diesen Block von einem Haufen Zeichen kannst du irgendjemandem schicken oder irgendwo veröffentlichen. Alle, die deinen öffentlichen Schlüssel haben (und ziemlich sicher wissen, dass es wirklich deiner ist), können nachvollziehen, dass du den Text geschrieben hast, der da drin steht.

Du kannst das auch selber ausprobieren, ob die Überprüfung der Signatur funktioniert. Mit dem Argument -d kannst du OpenPGP-Nachrichten lesen. Das d steht eigentlich für decrypt, entschlüsseln, obwohl hier gar nichts entschlüsselt wird, weil du die Nachricht nicht verschlüsselt, sondern nur signiert hast, aber zumindest kannst du den Block komischer Zeichen so erstmal nicht lesen und -d übersetzt ihn in ein menschenlesbares Format und überprüft dabei die Signatur. Also gib folgenden Befehl ein:

gpg -d

Wieder wartet GnuPG still auf Eingaben. Diesmal wird eine Eingabe erwartet, die mit BEGIN PGP MESSAGE anfängt. Also kopiere den kompletten Block, der dir oben ausgegeben wurde, hier rein. Kopieren kannst du normalerweise einfach, indem du den Block komplett mit der Maus markierst und dann ⇧-Einfg drückst, also die Umschalttaste (Shift) gedrückt hältst und die Einfügentaste (Insert) drückst. Oder du fügst den markierten Text ein, indem du die mittlere oder die rechte Maustaste drückst oder die linke und rechte gleichzeitig. Probier mal ein bisschen aus oder belies dich, wie das funktioniert. Irgendwie muss es auch bei dir funktionieren. Wenn du den Block bis END PGP MESSAGE reinkopiert hast, dann beginnst du nochmal eine neue Zeile und drückst wieder Strg-D zum Beenden. GnuPG gibt dir dann den signierten Text lesbar aus und überprüft die Signatur. Falls du den öffentlichen Schlüssel hast, aber den hast du ja.

gpg -d
-----BEGIN PGP MESSAGE-----

owGbwMvMwMF4+OpmAa2yzg+MpzuTGFJ4mo08MlOLcjNLFJJSi0sOLynJTE9VyCwu
0VEITs7IK01LS81JzkjN01FISSwuVshMzlBISc0DySWWVCkk5il4JxblZKRm5lUp
GDkYjMUUWZarKTapaIt9MdK4tAnmVlamFJ6W9aIyxchOcijIrtBLSmXg4hSAqZsx
…
F8bnj889uH3+b2ZI4bO1ehcXvjBdVvfORH/m4vlhi2tXRt6eN1lj9kHnhceEA09m
ftl4dYZYobd6Je/23mwOHikuz1V51f9KZqifPfK1LU3hzJo3E24xV3D+btjbwm20
XumUr7n5l/nb30fGqJ0FAA==
=TGHH
-----END PGP MESSAGE-----
Strg-D
Hiermit bestätige ich, Schnuffelchen, dass ich den Schatz an Karlheinz übergeben habe.
Karlheinz darf damit machen, was er will.
gpg: Signature made Sat Feb 18 14:39:59 2342 CET
gpg:                using RSA key A7262182242B16F43228D2B2C3D5B3102A7689F0
gpg:                issuer "schnuffelchen@pkx.be"
gpg: Good signature from "Dr. Schnuff <baerbel.schnuff@flowerpower.enterprises>" [ultimate]
gpg:                 aka "Schnuffelchen <schnuffelchen@pkx.be>" [ultimate]

In diesem Fall hatte GnuPG an der Signatur absolut nichts zu beanstanden. Sie stimmte und GnuPG war sich auch sicher, dass der verwendete Schlüssel der richtige ist, weil du ihn vorher selbst erzeugt hattest.

Wenn du zwar den passenden öffentlichen Schlüssel hast, mit dem du eine Signatur verifizieren kannst, aber du den einfach nur irgendwo her hast, ohne sicher zu wissen, ob es der richtige ist, dann wird GnuPG trotzdem anzeigen, ob die Signatur an sich korrekt ist, dass du darauf aber nicht zu sehr vertrauen solltest, weil unklar ist, wer überhaupt den geheimen Schlüssel hat. Wenn du den passenden öffentlichen Schlüssel dagegen gar nicht hast, dann kann GnuPG die Signatur auch gar nicht verifizieren. Dir wird dann nur die signierte Nachricht im Klartext angezeigt, aber keine Aussage über die Signatur getroffen. Sobald du ein paar signierte Nachrichten bekommst, wirst du diese Fälle oft sehen.

In den meisten Fällen ist es sicherlich zu unpraktisch, den zu signierenden Text auf der Kommandozeile direkt eingeben zu müssen, Zeile für Zeile. Natürlich kannst du auch fertige Dateien signieren und die Signatur gleich in eine extra Datei schreiben lassen. Nimm zu Testzwecken einfach mal irgendeine Datei her, die du gerade rumliegen hast. (Zur Erinnerung: mit dem Befehl ls kannst du gucken, was du in dem aktuellen Verzeichnis so rumliegen hast, und mit cd kannst du in ein anderes Verzeichnis wechseln.) Statt -s schreibst du als Kommandozeilenargument -b. Das erzeugt eine abgetrennte Signatur in einer eigenen Signaturdatei und lässt die Originaldatei unangetastet. Zusätzlich gibst du mit dem Argument -o noch die Ausgabedatei an (also die Signaturdatei, die neu erzeugt wird) und ganz am Ende der Kommandozeile dann noch die Eingabedatei (also die zu signierende Datei). Zum Beispiel:

gpg -abo signatur.txt eingabedatei.jpeg

Zusätzlich zur vorher schon existierenden Eingabedatei eingabedatei.jpeg hast du jetzt noch die neu angelegte Datei signatur.txt, die die Signatur für eingabedatei.jpeg enthält. Wenn du beide Dateien hast, dann kannst du die Signatur überprüfen:

gpg --verify signatur.txt eingabedatei.jpeg

Es sollte wieder die übliche Ausgabe erscheinen, dass die Signatur stimmte:

gpg: Signature made Sat Feb 18 14:49:59 2342 CET
gpg:                using RSA key A7262182242B16F43228D2B2C3D5B3102A7689F0
gpg:                issuer "schnuffelchen@pkx.be"
gpg: Good signature from "Dr. Schnuff <baerbel.schnuff@flowerpower.enterprises>" [ultimate]
gpg:                 aka "Schnuffelchen <schnuffelchen@pkx.be>" [ultimate]

Denk mal darüber nach, was das bedeutet, wenn du eine signierte Nachricht bekommst und du die Signatur erfolgreich überprüfen kannst. Das bedeutet, dass die Person, der der geheime Schlüssel gehört, mit dem die Nachricht signiert wurde, die Nachricht wohl selbst signiert hat. Mehr nicht. Das ist eine nicht unbedingt besonders starke Aussage. Es bringt nichts, „Ja.“ zu signieren, ohne Kontext. Wenn du eine signierte Nachricht bekommst, dann kann die in einem ganz anderen Kontext gemeint gewesen sein; auch wenn sie an dich verschlüsselt ist, denn das kann jeder. Wie du gesehen hast, wird bei der Verifikation einer Signatur auch immer der Zeitpunkt mit ausgegeben, zu dem die Signatur erstellt wurde. Das kann bei der Bewertung der Bedeutung der Nachricht hilfreich sein. Aber ein einfaches „Ja.“ bedeutet trotzdem tatsächlich exakt gar nichts, wenn nicht ein Stück Kontext mitsigniert wurde. Lustige Angriffe auf zwischenmenschliche Kommunikationserwartungen sind möglich, wenn man nicht nur dem wörtlichen Inhalt einer Nachricht glaubt, sondern irrigerweise annimmt, die Nachricht wäre in einem bestimmten Kommunikationskontext authentisch. Wenn dir ein Stück Kontext mitgeschickt wird, dann beachte auch, ob die Signatur sich mit über diesen Kontext erstreckt. Es könnte zum Beispiel sein, dass du eine zweigeteilte Nachricht bekommst: Ein signiertes knappes „Ja.“ und dazu ein unsigniertes Zitat einer Frage von dir. In dem Fall kannst du nicht sicher annehmen, dass das signierte „Ja.“ die Antwort auf deine Frage ist, weil die nicht mitsigniert wurde. Wenn du GnuPG zusammen mit einem E-Mail-Client verwendest, musst du auf sowas achten. Ein guter E-Mail-Client zeigt dir unmissverständlich an, von wo bis wo genau sich der signierte Teil der Nachricht erstreckt.

Schlüssel importieren

Jetzt willst du sicherlich nicht die ganze Zeit nur deine selbst erzeugten Signaturen überprüfen, sondern vor allem die von anderen Leuten erzeugten. Dafür musst du deren öffentliche Schlüssel in deine eigene Schlüsselliste übernehmen, d. h. importieren.

Diese abgetrennten Signaturen, um die es im vorherigen Abschnitt ging, werden zum Beispiel oft verwendet, um Software zu signieren. Wenn du Programme aus dem Internet runterlädtst, die du auf deinem eigenen Rechner ausführen willst, dann willst du ja doch gerne wissen, dass das die Originalsoftware ist und nicht irgendeine Schadsoftware, die dir wer auch immer in böser Absicht untergeschoben hat. Deshalb solltest du bei sowas, wo ein gewisses Risiko eines Angriffs besteht, die OpenPGP-Signatur überprüfen (und dich doll wundern, wenn gar keine Signatur angeboten wird).

Nehmen wir mal das Beispiel Nextcloud her. Das ist eine Kollaborationssoftware, die du dir auf einem eigenen Webserver installieren könntest. Machen wir jetzt hier nicht, ist ja ein ganz anderes Thema. Aber falls du dir jemals Nextcloud runterlädtst, um das bei dir zu installieren, dann solltest du auf jeden Fall die Signatur überprüfen. Und das können wir jetzt hier mal testweise üben. Auf nextcloud.com/changelog-unsupported findest du die ganzen Downloadlinks zu den verschiedenen alten Nextcloud-Versionen. Du kannst mal ganz runterscrollen zu den uralten Versionen, die schon seit Jahren nicht mehr unterstützt werden. Die solltest du natürlich niemals mehr einsetzen heutzutage, aber die Downloads waren damals noch kleiner. Deshalb lad einfach eine alte Version runter. Die Dateien, die mit .tar.bz2 enden, sind kleiner als die Dateien, die mit .zip enden. Also lade zum Beispiel die Datei nextcloud-9.0.54.tar.bz2 runter. Und wenige Zeilen darunter neben „PGP“ stehen die dazugehörigen Signaturdateien. In diesem Beispiel lade außerdem noch die nextcloud-9.0.54.tar.bz2.asc runter.

Wenn du die beiden Dateien im gleichen Verzeichnis hast, dann kannst du auf der Kommandozeile in dieses Verzeichnis reingehen (mit cd Verzeichnis wechseln und mit ls (bzw. dir unter Windows) gucken, ob die Dateien da sind) und wie gewohnt die Signatur überprüfen (Dateinamen kannst du mit der Tab-Taste ⇥ (über ⇧ und ⇬) vervollständigen):

gpg --verify nextcloud-9.0.54.tar.bz2.asc nextcloud-9.0.54.tar.bz2
gpg: Signature made Wed Sep 28 15:53:03 2016 CEST
gpg:                using RSA key D75899B9A724937A
gpg: Can't check signature: No public key

Soso. GnuPG kann dir hier nur sagen, wann die Signatur erzeugt wurde und welcher OpenPGP-Schlüssel dafür verwendet wurde. Aber da du den angegebenen öffentlichen Schlüssel nicht hast, kann GnuPG überhaupt keine Aussage darüber treffen, ob die Signatur nun stimmt oder nicht. Du brauchst erstmal den öffentlichen Schlüssel, mit dem du die Signatur überprüfen kannst. Zum Glück ist der auch auf derselben Website verlinkt, von der du eben das Nextcloud-Archiv und die Signatur runtergeladen hast. Hinter „PGP“ steht in Klammern der Link zu der Datei nextcloud.asc. Lade die auch noch runter. Das ist der Schlüssel, den du importieren musst. Das geht mit dem Kommandozeilenargument --import und dahinter dem Namen der Datei, in der ein OpenPGP-Schlüssel drinsteht:

gpg --import nextcloud.asc
gpg: key D75899B9A724937A: public key "Nextcloud Security <security@nextcloud.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1

Der öffentliche Schlüssel von Nextcloud wurde jetzt in deine Schlüsseldatenbank aufgenommen. Das heißt, die Datei nextcloud.asc kannst du jetzt löschen. Der öffentliche Schlüssel, auf den GnuPG zugreifen kann, ist ja in dem GnuPG-Verzeichnis abgelegt. Du kannst mittels gpg -k (mit kleinem k) nachgucken, dass du den öffentlichen Schlüssel verfügbar hast. Bei gpg -K (mit großem K) wird er nicht mit aufgelistet, weil du nur den öffentlichen, nicht den geheimen Schlüssel dazu hast.

Jetzt kannst du nochmal den Befehl von vorhin aufrufen, um die Signatur zu überprüfen. (Die Pfeil-nach-oben-Taste reicht aus, um den Befehl wieder hervorzuholen. Du musst ihn nicht neu eintippen.)

gpg --verify nextcloud-9.0.54.tar.bz2.asc nextcloud-9.0.54.tar.bz2
gpg: Signature made Wed Sep 28 15:53:03 2016 CEST
gpg:                using RSA key D75899B9A724937A
gpg: Good signature from "Nextcloud Security <security@nextcloud.com>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 2880 6A87 8AE4 23A2 8372  792E D758 99B9 A724 937A

Wunderbar. Die Signatur stimmte. GnuPG sagt aber auch richtigerweise, dass das erstmal überhaupt gar nichts heißt. Wer auch immer dir ein falsches Nextcloud-Archiv untergeschoben hat, wird dir auch einfach eine falsche Signatur und einen falschen öffentlichen Schlüssel untergeschoben haben. Da du nicht wissen kannst, welcher der wirklich richtige echte öffentliche Schlüssel von Nextcloud ist, kannst du das letztlich nicht überprüfen.

Du könntest, wenn du Nextcloud-Entwickler*innen kennst oder auf einer Konferenz triffst, diesen Fingerabdruck, der dir hier angezeigt wird, mit denen persönlich abgleichen. (Bitte verwechsel nicht die Schlüssel-ID weiter oben in der Ausgabe (using RSA key D75899B9A724937A) mit dem Fingerabdruck. Der Fingerabdruck ist in diesem Fall 40 Zeichen (aus dem Zeichensatz 0–9 und A–F) lang. Das ist das alte Format. Im neuen Format ist der Fingerabdruck in Kurzform 50 Zeichen und in Langform 64 Zeichen lang. Die Schlüssel-ID reicht nicht zum Beweis, dass das der korrekte Schlüssel ist, weil es leicht ist, einen anderen Schlüssel mit der gleichen Schlüssel-ID zu finden. Die Schlüssel-ID ist in Kurzform 8 und in Langform 16 Zeichen lang. Du musst den kompletten Fingerabdruck abgleichen. Es reicht nicht, nur ein paar Zeichen daraus zu überprüfen. Denn es ist sehr einfach möglich, einen falschen Schlüssel zu erzeugen, dessen Fingerabdruck in einigen bestimmten Stellen mit dem korrekten Fingerabdruck übereinstimmt. Es ist aber praktisch unmöglich, einen falschen Schlüssel zu erzeugen, der genau den gleichen Fingerabdruck hat.)

Wenn dir das zu kompliziert ist, dann kannst du auch vorerst darauf vertrauen, dass dir dieses Mal niemand was Falsches andrehen wollte. Wenn du in drei Monaten die neue Version von Nextcloud runterlädtst, dann wirst du aber immer noch denselben öffentlichen Schlüssel in deiner Schlüsseldatenbank haben, den du heute importiert hast. Das heißt, wenn du heute den richtigen Schlüssel importiert hast, dann kann dir in Zukunft niemand mehr eine Fälschung eines Nextcloud-Archivs andrehen. Und wenn dir eine Angreifer*in tatsächlich eine Schadsoftware auf diese Weise andrehen will, dann muss sie fortan dauerhaft dabei bleiben, also alle Nextcloud-Signaturen und alle Nextcloud-Archive, die du jemals in Zukunft runterladen wirst, muss sie alle alle fälschen. Denn wenn du irgendwann einmal nicht mehr demselben falschen, sondern dem richtigen Nextcloud-Schlüssel begegnest, dann fällt der ganze Schwindel auf.

Das Verfahren, bei dem du eigentlich nicht weißt, ob der Schlüssel nun stimmt oder nicht, aber du dir sicher bist, immer denselben Schlüssel für die Signaturprüfung zu verwenden, der also entweder immer der richtige ist oder immer derselbe gefälschte, dieses Verfahren nennt man auch Trust on first use, kurz TOFU. Das ist nicht ganz optimal, wenn du auch den Fingerabdruck abgleichen könntest, aber durchaus auch legitim und besser als nichts. Es ist eben auch abhängig davon, welche Bedrohungen du für wie realistisch hältst und welche Verfahrenskorrektheit dir noch praktikabel erscheint.

Schlüssel signieren

Solange du nicht explizit ansagst, dass du dir sehr doll sicher bist, dass ein bestimmter öffentlicher Schlüssel in deiner Schlüsseldatenbank „echt“ ist, wird GnuPG immer diese Warnung ausgeben, dass es keinen Anhaltspunkt dafür gibt, anzunehmen, dass der Schlüssel „echt“ ist. „Echt“ heißt hier, dass die Person, die den dazu gehörenden geheimen Schlüssel hat, genau die Person ist, deren Name und E-Mail-Adresse in der User-ID (oder den verschiedenen User-IDs) angegeben ist. Und dass darüber hinaus keine weitere Person im Besitz des geheimen Schlüssels ist (dass der Schlüssel also nicht kompromittiert ist).

Nachdem du die Echtheit eines Schlüssels überprüft hast (indem du etwa die Person angerufen und nach dem Fingerabdruck gefragt hast), kannst du den öffentlichen Schlüssel der anderen Person mit deinem eigenen geheimen Schlüssel signieren (auch genannt zertifizieren). Was du damit aussagst, ist: „Mit meiner Unterschrift beglaubige ich, dass die Person, die in dieser User-ID angegeben ist, im Besitz des geheimen Schlüssels ist, dessen zugehörigen öffentlichen Schlüssel ich hier unterschreibe.“ Also die Signatur an einem Schlüssel gilt nicht pro Schlüssel, sondern pro User-ID. Bei einem Schlüssel mit mehreren User-IDs kannst du dich entscheiden, welche der User-IDs du beglaubigen willst.

Im Prinzip musst du Schlüssel anderer Leute nicht signieren. Du kannst dir auch merken, welche Schlüssel du für echt hältst und welche nicht. Bei vielen Kommunikationspartner*innen mit vielen Schlüsseln, die sich auch gelegentlich mal ändern, kann das schnell unübersichtlich werden. Deshalb signiere ruhig mal alle Schlüssel, deren Echtheit du überprüft hast – zum Beispiel indem du den Fingerabdruck abgeglichen hast.

Um das mit dem Signieren von Schlüsseln mal auszuprobieren, können wir bei dem Nextcloud-Beispiel von oben bleiben: Du kannst mal testweise den Nextcloud-Schlüssel, den du vorhin importiert hast, signieren, um dann festzustellen, dass keine Warnung mehr erscheint, dass der Schlüssel nicht vertrauenswürdig sei.

So kannst du einen Schlüssel signieren:

gpg --lsign-key security@nextcloud.com

Mit dem Argument --lsign-key kannst du eine lokale Signatur an diesem öffentlichen Schlüssel mit deinem geheimen Schlüssel erstellen. Es gibt auch das Argument --sign-key für eine einfache Signatur, aber es ist wichtig, dass du hier --lsign-key für eine nur lokale Signatur eingibst, weil das nur ein Beispiel ist und du ja nicht tatsächlich geprüft hast, dass der Schlüssel echt ist. Wenn du eine lokale Signatur erstellst, dann kann es nicht passieren, dass du die aus Versehen an andere Leute weitergibst, die dann irrtümlich glauben könnten, du hättest geprüft, dass der Nextcloud-Schlüssel echt ist. Im Zweifelsfall deshalb lieber immer --lsign-key eingeben.

gpg --lsign-key security@nextcloud.com

pub  rsa4096/D75899B9A724937A
     created: 2016-06-14  expires: never       usage: SC  
     trust: unknown       validity: unknown
sub  rsa4096/36B8EF1826F57923
     created: 2016-06-14  expires: never       usage: E   
[ unknown] (1). Nextcloud Security <security@nextcloud.com>


pub  rsa4096/D75899B9A724937A
     created: 2016-06-14  expires: never       usage: SC  
     trust: unknown       validity: unknown
 Primary key fingerprint: 2880 6A87 8AE4 23A2 8372  792E D758 99B9 A724 937A

     Nextcloud Security <security@nextcloud.com>

Are you sure that you want to sign this key with your
key "Schnuffelchen <schnuffelchen@pkx.be>" (8D631EC35A0B6427)

The signature will be marked as non-exportable.

Really sign? (y/N)

Nachdem du den Befehl abgeschickt hast, wird dir der Fingerabdruck des zu signierenden Schlüssels angezeigt, so dass du den jetzt gleich abgleichen könntest. Und dir wird angezeigt, mit welchem geheimen Schlüssel du diesen öffentlichen Schlüssel signieren würdest. Wenn du nur einen geheimen Schlüssel hast, wird das also immer der richtige sein. Wenn du mehrere geheime Schlüssel hast, dann musst du vorher den richtigen auswählen, indem du die Kommandozeilenargumente -u schnuffelchen übergibst.

Wenn alles soweit richtig ist, dann bestätigst du die Frage und gibst dein Mantra ein (falls es nicht noch gespeichert ist, nachdem du es kurz vorher schon eingegeben hattest):

Really sign? (y/N) y

Du wurdest jetzt nicht gefragt, welche User-IDs du signieren willst, weil es eh nur eine gibt in diesem Fall. Das ist meistens so. Deshalb spare ich mir jetzt detailliertere Ausführungen darüber, was ist, wenn es mehrere User-IDs an einem öffentlichen Schlüssel gibt. In dem Fall nutzt du den Schlüssel-bearbeiten-Modus mit --edit-key, wählst die zu signierenden User-IDs mit den GnuPG-Befehlen uid und uid * und uid 1 usw. aus und gibst dann den GnuPG-Befehl lsign ein. Das kriegst du durch Ausprobieren dann schon raus.

Jetzt kannst du nochmal gucken, was GnuPG sagt, wenn du wieder die Signatur überprüfst, die du vorhin schon mal überprüft hattest:

gpg --verify nextcloud-9.0.54.tar.bz2.asc nextcloud-9.0.54.tar.bz2
gpg: Signature made Wed Sep 28 15:53:03 2016 CEST
gpg:                using RSA key D75899B9A724937A
gpg: Good signature from "Nextcloud Security <security@nextcloud.com>" [full]

Also die gleiche Ausgabe wie vorhin, nur dass die Warnung fehlt, dass noch niemand Vertrauenswürdiges den Schlüssel signiert hat, denn jetzt hast du den Schlüssel selber signiert, also ist alles gut.

Dass der Nextcloud-Schlüssel wirklich deine Signatur trägt, kannst du mit dem Kommandozeilenargument --list-sigs (statt -k) überprüfen:

gpg --list-sigs nextcloud
pub   rsa4096 2016-06-14 [SC]
      28806A878AE423A28372792ED75899B9A724937A
uid           [  full  ] Nextcloud Security <security@nextcloud.com>
sig 3        D75899B9A724937A 2016-06-14  Nextcloud Security <security@nextcloud.com>
sig   L      8D631EC35A0B6427 2342-02-19  Schnuffelchen <baerbel.schnuff@flowerpower.enterprises>
sub   rsa4096 2016-06-14 [E]
sig          D75899B9A724937A 2016-06-14  Nextcloud Security <security@nextcloud.com>

Unter der uid-Zeile steht zuerst die Selbstsignatur mit dem Hauptschlüssel selbst und darunter deine Signatur. Das L steht für lokal.

Willst du die nur zu Testzwecken angelegte lokale Signatur jetzt wieder löschen?

Das kannst du machen, indem du mit --edit-key security@nextcloud.com den Schlüssel bearbeitest, mit dem GnuPG-Befehl uid * alle User-IDs auswählst (oder mit uid 1 die erste usw.) und dann den Befehl delsig eingibst, um für jede Signatur gefragt zu werden, ob sie gelöscht werden soll:

gpg --edit-key security@nextcloud.com
gpg (GnuPG) 2.3.8; Copyright (C) 2021 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.


pub  rsa4096/D75899B9A724937A
     created: 2016-06-14  expires: never       usage: SC
     trust: unknown       validity: full
sub  rsa4096/36B8EF1826F57923
     created: 2016-06-14  expires: never       usage: E
[  full  ] (1). Nextcloud Security <security@nextcloud.com>

gpg> uid *

pub  rsa4096/D75899B9A724937A
     created: 2016-06-14  expires: never       usage: SC
     trust: unknown       validity: full
sub  rsa4096/36B8EF1826F57923
     created: 2016-06-14  expires: never       usage: E
[  full  ] (1)* Nextcloud Security <security@nextcloud.com>

gpg> delsig
uid  Nextcloud Security <security@nextcloud.com>
sig!3        D75899B9A724937A 2016-06-14  [self-signature]
Delete this good signature? (y/N/q)↵
uid  Nextcloud Security <security@nextcloud.com>
sig!  L      8D631EC35A0B6427 2342-02-19  Schnuffelchen <schnuffelchen@pkx.be>
Delete this good signature? (y/N/q)y
Deleted 1 signature.

gpg> save

(Zum Überspringen einfach Enter drücken, zum Löschen y eingeben und Enter drücken.)

Damit ist die lokale Signatur weg. Das heißt, GnuPG weiß jetzt wieder nicht mehr, wie vertrauenswürdig der Nextcloud-Schlüssel ist:

gpg --verify nextcloud-9.0.54.tar.bz2.asc nextcloud-9.0.54.tar.bz2
gpg: Signature made Wed Sep 28 15:53:03 2016 CEST
gpg:                using RSA key D75899B9A724937A
gpg: Good signature from "Nextcloud Security <security@nextcloud.com>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 2880 6A87 8AE4 23A2 8372  792E D758 99B9 A724 937A

Wenn du eine User-ID an einem Schlüssel einer anderen Person signierst, dann sagst du damit aus, dass du überprüft hast, dass die Person, die behauptet, dass das ihr Schlüssel ist, mit dieser User-ID hinreichend identifiziert ist. Andere Leute, die die Person kennen, deren Name in der User-ID angegeben ist, können dann darauf vertrauen, dass du gesagt hast, dass das der echte Schlüssel von der Person ist. Deshalb könnte man dafür argumentieren, nur überprüfbare User-IDs zu signieren (also nicht mit irgendwelchen ad hoc ausgedachten Namen) und diese User-IDs auch wirklich zu überprüfen (also sich irgendwelche Dokumente oder so zeigen zu lassen). Aber wie streng du das wirklich handhaben willst, kannst du selbst entscheiden. Andere Leute wiederum werden selbst entscheiden, für wie ernstzunehmen sie deine Schlüsselsignaturen halten wollen.

Nachrichten verschlüsseln

Um eine Nachricht zu verschlüsseln, lege dir am einfachsten erstmal eine Datei mit der Nachricht an. Das muss auch kein Text sein. Du kannst alle möglichen Dateien verschlüsseln. Aber immer nur eine Datei auf einmal. Wenn du mehrere Dateien verschlüsseln willst, dann musst du die vorher mit einem anderen Programm zusammenpacken, zum Beispiel tar, zip oder was auch immer du für Archivierungsprogramme magst. Dann stößt du die Verschlüsselung der Datei an, indem du folgende Kommandozeile eingibst:

gpg -ae beispieldatei.jpeg

Damit wird die vorhandene Datei beispieldatei.jpeg verschlüsselt und die verschlüsselte Version in der neuen Datei beispieldatei.jpeg.asc gespeichert. Die Originaldatei wird nicht verändert und auch nicht gelöscht. Das Kommandozeilenargument -e bedeutet, dass eine Verschlüsselung stattfinden soll. Das Argument -a ist optional und bewirkt wieder, dass die verschlüsselte Nachricht nur aus halbwegs normalen Zeichen besteht, die man mit einem Texteditor angucken kann. Wenn das für dich kein Problem ist, dann kannst du -a auch weglassen. Damit wird die verschlüsselte Version ein bisschen kleiner. Also:

gpg -e beispieldatei.jpeg

Die verschlüsselte Version wird in diesem Fall dann nicht in beispieldatei.jpeg.asc, sondern in beispieldatei.jpeg.gpg gespeichert.

Es folgt ein ausführlicheres Beispiel. Du kannst dir das mal angucken. Darunter ist dann erklärt, was da passiert ist.

gpg -ae beispieldatei.jpeg
You did not specify a user ID. (you may use "-r")

Current recipients:

Enter the user ID.  End with an empty line: security@nextcloud.com
gpg: 36B8EF1826F57923: There is no assurance this key belongs to the named user

sub  rsa4096/36B8EF1826F57923 2016-06-14 Nextcloud Security <security@nextcloud.com>
 Primary key fingerprint: 2880 6A87 8AE4 23A2 8372  792E D758 99B9 A724 937A
      Subkey fingerprint: 2ED0 4032 9CAA F597 A1A1  47FD 36B8 EF18 26F5 7923

It is NOT certain that the key belongs to the person named
in the user ID.  If you *really* know what you are doing,
you may answer the next question with yes.

Use this key anyway? (y/N) y

Current recipients:
rsa4096/36B8EF1826F57923 2016-06-14 "Nextcloud Security <security@nextcloud.com>"

Enter the user ID.  End with an empty line: hostmaster@proton.me
gpg: error retrieving 'hostmaster@proton.me' via WKD: No data
No such user ID.

Current recipients:
rsa4096/36B8EF1826F57923 2016-06-14 "Nextcloud Security <security@nextcloud.com>"

Enter the user ID.  End with an empty line: hostmaster@proton.me
gpg: key 7A1CE1DE6C92452F: public key "hostmaster@proton.me <hostmaster@proton.me>" imported
gpg: Total number processed: 1
gpg:               imported: 1
gpg: 885303569878EBD2: There is no assurance this key belongs to the named user

sub  cv25519/885303569878EBD2 2021-02-18 hostmaster@proton.me <hostmaster@proton.me>
 Primary key fingerprint: B4BC 9ED5 7279 201D 437C  9725 7A1C E1DE 6C92 452F
      Subkey fingerprint: E780 6C60 6961 37D4 710B  5F29 8853 0356 9878 EBD2

It is NOT certain that the key belongs to the person named
in the user ID.  If you *really* know what you are doing,
you may answer the next question with yes.

Use this key anyway? (y/N) y

Current recipients:
cv25519/885303569878EBD2 2021-02-18 "hostmaster@proton.me <hostmaster@proton.me>"
rsa4096/36B8EF1826F57923 2016-06-14 "Nextcloud Security <security@nextcloud.com>"

Enter the user ID.  End with an empty line: schnuffelchen

Current recipients:
rsa4096/7FA7A47FD584585C 2342-02-16 "Schnuffelchen <schnuffelchen@pkx.be>"
cv25519/885303569878EBD2 2021-02-18 "hostmaster@proton.me <hostmaster@proton.me>"
rsa4096/36B8EF1826F57923 2016-06-14 "Nextcloud Security <security@nextcloud.com>"

Enter the user ID.  End with an empty line:

Gehen wir mal schrittweise durch, was da passiert ist. Die Kommandozeile sagt, dass du die Datei beispieldatei.jpeg verschlüsseln willst und das Ergebnis in der neuen Datei beispieldatei.jpeg.asc landen soll. Wenn du die Kommandozeile so abschickst, dann informiert dich GnuPG erstmal darüber, dass du auch das Argument -r angeben könntest, um Empfänger*innen deiner Nachricht aufzulisten (damit deren öffentliche Schlüssel aus deiner Schlüsseldatenbank zusammengesucht werden und die Nachricht mit diesen öffentlichen Schlüsseln verschlüsselt wird). Da du das nicht gemacht hast, wird dir hier gesagt, dass es noch keine Empfänger*innen gibt und du welche angeben kannst. Gibst du zum Beispiel als erstes security@nextcloud.com an (deren Schlüssel hast du ja noch aus dem Beispiel vorhin in deiner Schlüsseldatenbank), dann wird dir umgehend mitgeteilt, dass der passende Schlüssel gefunden wurde, aber nicht vertrauenswürdig ist, weil völlig unklar ist, ob es der richtige ist. Denn er ist nicht von dir signiert, falls du deine lokale Signatur an diesem Schlüssel vorhin gelöscht hast. Du kannst der Verwendung dieses Schlüssels zustimmen und du kennst die Unwägbarkeiten, die damit verbunden sind: möglicherweise liest jemand Unbefugtes deine an diesen Schlüssel verschlüsselten Nachrichten, falls das nicht der korrekte Schlüssel sein sollte.

Dann wird dir gesagt, dass „Nextcloud Security“ in die Liste der Empfänger*innen aufgenommen wurde, und du kannst die nächste Empfänger*in eingeben. Alle Leute, die einen der zugehörigen geheimen Schlüssel haben, können deine Nachricht entschlüsseln. Als zweite Empfänger*in könntest du zum Beispiel mal eine Adresse eingeben, deren öffentlichen Schlüssel du gar nicht hast. Es wird dann versucht, per WKD (siehe unten) den Schlüssel zu besorgen. Das dauert einen Moment. Bitte drück in dieser Zeit keine weiteren Tasten, sonst passieren anschließend seltsame Dinge. Wenn das wie in diesem Fall nicht klappt, dann kann das daran liegen, dass die Person ihren öffentlichen Schlüssel nicht per WKD zur Verfügung stellt. Es kann aber auch sein, dass einfach nur der Webserver, von dem der Schlüssel geholt wird, zu lange zum Antworten gebraucht hat. Also kannst du bei der darauffolgenden Frage nach der nächsten Empfänger*in mit der Pfeil-nach-oben-Taste einfach nochmal dieselbe Adresse angeben. In diesem Fall hat es beim zweiten Versuch geklappt. Der Schlüssel wurde importiert und er ist ebenso nicht vertrauenswürdig wie der davor. Dir wird aber der Fingerabdruck angezeigt (der vom Hauptschlüssel ist der relevante). Du könntest ihn abgleichen, wenn du den Fingerabdruck auf einem manipulationssicheren Kanal bekommen hast.

Wenn du Nachrichten verschlüsselst, dann können nur die Leute diese Nachrichten entschlüsseln, die einen der geheimen Schlüssel haben, deren öffentliche Schlüssel zum Verschlüsseln verwendet wurden. Das heißt: Die Nachrichten, die du an andere Leute verschlüsselst, kannst du selber nicht mehr entschlüsseln. Du hast ja die geheimen Schlüssel der anderen Leute nicht. Um selber deine an andere Leute verschlüsselten Nachrichten auch noch lesen zu können, kannst du sie zusätzlich an dich selbst verschlüsseln. Also gib deinen eigenen Namen als Empfänger*in mit an. In diesem Fall gibt es keine Warnung, dass der Schlüssel nicht vertrauenswürdig genug sei, denn deinem eigenen Schlüssel vertraust du ja.

Wenn du die Frage nach der nächsten Empfänger*in ohne eine Eingabe mit Enter abschließt, dann verschlüsselt GnuPG die Nachricht an alle, schreibt das Ergebnis in die Datei beispieldatei.jpeg.asc und beendet sich. Du kannst jetzt nachgucken, dass die neue Datei existiert und könntest die verschicken.

Dein Mantra wird beim Verschlüsseln nicht abgefragt, denn du brauchst dafür deinen geheimen Schlüssel nicht. Du brauchst nur die öffentlichen Schlüssel der anderen Leute (und ggf. deinen eigenen), die ja unverschlüsselt in deiner Schlüsseldatenbank liegen.

Du kannst jetzt mal gucken, ob du die Datei selber wieder entschlüsselt kriegst. Wenn du sie an dich selbst mit verschlüsselt hast, dann sollte das gehen. Wenn nicht, dann wird das nicht gehen. Gib dazu ein:

gpg -o beispieldatei_neu.jpeg -d beispieldatei.jpeg.asc

Das Argument -d bedeutet, dass die übergebene Datei beispieldatei.jpeg.asc entschlüsselt und das Ergebnis direkt auf der Kommandozeile ausgegeben wird. Das mag für relativ kurzen einfachen Text manchmal noch in Ordnung sein. Sobald die Datei aber nicht nur Text enthält oder länger wird, willst du das Ergebnis der Entschlüsselung bestimmt in eine Datei schreiben lassen. Dazu dient das Argument -o mit dem Namen der anzulegenden Datei dahinter.

gpg -o beispieldatei_neu.jpeg -d beispieldatei.jpeg.asc
gpg: encrypted with rsa4096 key, ID 36B8EF1826F57923, created 2016-06-14
      "Nextcloud Security <security@nextcloud.com>"
gpg: encrypted with cv25519 key, ID 885303569878EBD2, created 2021-02-18
      "hostmaster@proton.me <hostmaster@proton.me>"
gpg: encrypted with rsa4096 key, ID 7FA7A47FD584585C, created 2342-02-16
      "Schnuffelchen <baerbel.schnuff@flowerpower.enterprises>"

Die Datei beispieldatei_neu.jpeg wurde nun angelegt und sollte mit der Datei beispieldatei.jpeg identisch sein.

Wahrscheinlich willst du oft Signieren und Verschlüsseln verbinden: Eine Nachricht soll erst mit deinem eigenen geheimen Schlüssel signiert werden und das Ergebnis soll dann verschlüsselt werden. Du kannst das ganz problemlos beides gleichzeitig machen, indem du sowohl -s für Signieren als auch -e für Verschlüsseln auf der Kommandozeile angibst (und optional noch -a):

gpg -ase beispieldatei.jpeg

Schlüssel verteilen

Dein eigener öffentlicher Schlüssel muss irgendwie anderen Leuten zugänglich gemacht werden, damit sie ihn importieren können, um dann Nachrichten an dich zu verschlüsseln, deine signierten Nachrichten zu verifizieren und deinen Schlüssel zu signieren, wenn sie sicher sind, dass du wirklich die in der User-ID angegebene Person bist.

Dein Schlüssel liegt in diesem GnuPG-Verzeichnis, in einem GnuPG-eigenen Datenformat. Um ihn zu verteilen, kannst du ihn exportieren, das heißt in ein standardisiertes Format überführen, aus dem andere Leute ihn bei sich importieren können. Das GnuPG-Kommandozeilenargument dazu heißt --export. Und du solltest -a mit dazu angeben, um den Schlüssel in einem vernünftig kopierbaren Format zu erhalten:

gpg -a --export schnuffel
-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBGQLlKcBEADGQr1CRYgta1BbxLFSjxvkRn9tbLPqBmJohK7+MV6/O8v9HGGl
x2F9JNZBkIJWnEHxg2MBQegupIyI1tHMiYa+mzq21IeVajxqeMRVB19Bfmjrflk/
SYBQ2a9umpuZcHQN+3tbOjjyxRpuqD6/2rG1Wgi9mLoEC+kdV5zp6ifHAxfq7/0E
x6CIfQQBTWcvEP0pbyOhMxscLSKnA80SevI0c4Tnh5zZHj2DfEbSbOvQGsGUniC+
W+GNQ1ke1n+y5UvgEMHdUGFQy8HfLiVrUFMGNWWCU1gnJO8n3jWE5HpIe1tG0rAq
kyy2VKKgJPtQ7OI20hOYCU/8B144mJJn5TQ7HZ8mAIX24rhK5u/B6sagHzlxM1YI
…
2V0iNjtGVpE6cFOEi8K9N2mRT+cx9uqXIfpSteJIeZ6i1AT9YN/rvs3Uy8MXJ/0J
HgCO8VaHZmrE0BPZwBWzvI4Zhzuhdd9stzFKatj/uE8N2A8CWJ4jgEWhq3MebFjZ
JhyfWOlquBptYm1atJa0B5wRCI0l7jXUajCLnApmcHuSpeA/IWiz9ihUN1DiOG3S
icS2kszA8gGTjqqOvegdQmaxl9Zbm2QyBmlJnXK+ipdlGR15pFb0uqVBt+IZznqU
5/MThfnrOHzGOMH0jhISOJfPPyabeYAhQ/FZ
=CWf5
-----END PGP PUBLIC KEY BLOCK-----

Das, was dir hier ausgegeben wird, ist dein öffentlicher Schlüssel. Du kannst ihn rauskopieren und irgendwas damit machen: ihn irgendwo hinkopieren, wo Leute ihn abholen können. Du kannst ihn auch gleich in eine Datei schreiben, indem du zusätzlich das Kommandozeilenargument -o und einen Dateinamen angibst:

gpg -ao schnuffelchensschluessel.key --export schnuffel

Dasselbe, was gerade eben ausgegeben wurde, steht jetzt in der Datei schnuffelchensschluessel.key drin.

Nochmal gucken, ob es wirklich geklappt hat:

gpg --show-key schnuffelchensschluessel.key
pub   rsa4096/8D631EC35A0B6427 2342-02-16 [C] [expires: 2342-02-30]
      Key fingerprint = F096 A0F5 2BDF 8368 6282  7E44 8D63 1EC3 5A0B 6427
uid                            Schnuffelchen <baerbel.schnuff@flowerpower.enterprises>
uid                            Schnuffelchen <schnuffelchen@pkx.be>
sub   rsa4096/C3D5B3102A7689F0 2342-02-17 [S]
sub   rsa4096/7FA7A47FD584585C 2342-02-17 [E]

Hat geklappt. Der öffentliche Schlüssel ist in der Datei. Du könntest die Datei weitergeben. Achtung: In der Datei ist eine Momentaufnahme deines Schlüssels. Das ist das, was das Wort „exportieren“ ausdrückt. Wenn du deinen Schlüssel später bearbeitest (Ablaufdatum änderst oder so), dann verändert sich nicht auf magische Weise der Inhalt dieser exportierten Schlüsseldatei. Du musst deinen Schlüssel dann neu exportieren und weitergeben.

Eine Alternative zum Dateien-Rumschicken sind Schlüsselserver. Schlüsselserver sind von der Idee her das schwarze Brett im Internet, wo alle ihre Schlüssel ranpinnen können, damit alle alle Schlüssel auffinden können. Leider ist die allgemeine Schlüsselserver-Situation zur Zeit unbefriedigend. In älteren Anleitungen findest du vielleicht noch den Hinweis auf die SKS-Schlüsselserver. Das war eine gute Sache, aber die sind derzeit im Wesentlichen dysfunktional. Neben vereinzelten noch laufenden SKS-Schlüsselservern gibt es Hagrid- und Hockeypuck-Schlüsselserver. Die funktionieren alle unterschiedlich und sie reden zum Teil nicht miteinander. Das heißt, wenn du einen Schlüssel von jemand anderem bekommen willst, musst du auf mehreren Schlüsselservern nachgucken, weil die ihre Schlüsseldatenbanken heutzutage nicht mehr automatisch untereinander austauschen. Und wenn du deinen Schlüssel unters Volk werfen willst, dann musst du ihn auf mehreren Schlüsselservern hochladen.

Lies hier gerne mehr über die Bedienung von Schlüsselservern, wenn dich das interessiert.

Der Standard-Schlüsselserver, den GnuPG voreingestellt hat, ändert sich von GnuPG-Version zu GnuPG-Version gelegentlich mal. Zur Zeit ist es der Hockeypuck-Schlüsselserver keyserver.ubuntu.com. Der hat auch ein Webinterface wie die meisten Schlüsselserver, aber das solltest du nicht brauchen, weil du ihn direkt über GnuPG auf der Kommandozeile bedienen kannst. Wenn du einen Schlüssel brauchst, dann kannst du auf dem voreingestellten Schlüsselserver danach suchen, indem du GnuPG das Kommandozeilenargument --search-keys und danach den Fingerabdruck oder die Schlüssel-ID (Kurzform des Fingerabdrucks) oder eine E-Mail-Adresse oder einen anderen Teil einer User-ID übergibst:

gpg --search-keys info@g10code.com
gpg: data source: https://162.213.33.8:443
(1)	g10 Code GmbH <info@g10code.com>
	media@gnupg.org
	  2048 bit RSA key B3671B936BA8BCB2, created: 2014-01-02
Keys 1-1 of 1 for "info@g10code.com".  Enter number(s), N)ext, or Q)uit > 1
gpg: key B3671B936BA8BCB2: public key "g10 Code GmbH <info@g10code.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1

Du kannst auch nur einen Teil einer E-Mail-Adresse eingeben und bekommst dann mehr irrelevante Suchergebnisse. Wichtig zu beachten ist, dass ein Suchergebnis auf einem Schlüsselserver nicht heißt, dass das der richtige Schlüssel ist. Schlüsselserver sammeln Daten, die irgendjemand da reingekübelt hat. Ein Schlüssel, den du auf einem Schlüsselserver gefunden hast, ist von der Datenqualität her vergleichbar mit einem Zettel, den du auf der Straße gefunden hast: Es ist in beiden Fällen nicht ausgeschlossen, dass die Information korrekt ist. Der Sinn dessen ist also, dass du auf diese Weise überhaupt erstmal den gesuchten Schlüssel bekommst. Danach musst du dann aber noch den Fingerabdruck abgleichen.

Wenn deine GnuPG-Version einen anderen Standard-Schlüsselserver voreingestellt hat und du keyserver.ubuntu.com verwenden willst, dann kannst du den Schlüsselserver auf der Kommandozeile mit angeben, damit der angefragt wird:

gpg --keyserver hkps://keyserver.ubuntu.com --search-keys security@nextcloud.com

Achte darauf, dass Schlüsselserver meistens das Protokoll hkps: verwenden (das ist kein Schreibfehler). Ein anderer möglicher Schlüsselserver, den du verwenden kannst (und der ganz anders funktioniert), ist keys.openpgp.org:

gpg --keyserver hkps://keys.openpgp.org --search-keys security@nextcloud.com

Wenn du das Anonymisierungsnetzwerk Tor benutzt (was in jedem Fall empfehlenswert ist), dann kannst du von keys.openpgp.org auch den Onion-Service (mit hkp:) benutzen:

gpg --keyserver hkp://zkaan2xfbuxia2wpf7ofnkbz6r5zdbbvxbunvp5g2iebopbfc4iqmbad.onion --search-keys security@nextcloud.com

Der Schlüsselserver keys.openpgp.org ist insofern speziell, als du da nur nach kompletten E-Mail-Adressen suchen kannst, aber nicht nach Teilen von User-IDs. Und die Suche nach Fingerabdrücken oder Schlüssel-IDs ist möglich, aber sinnlos, weil der Schlüssel dir dann nur ohne User-IDs angeboten wird.

Oder du benutzt einen der noch existierenden SKS-Schlüsselserver, zum Beispiel:

gpg --keyserver hkps://sks.hnet.se --search-keys security@nextcloud.com

Wahrscheinlich musst du ein bisschen gucken, wo du deinen gesuchten Schlüssel findest, und ggf. die Person, der er gehört, mal fragen, wo ihr Schlüssel denn auffindbar wäre.

Umgekehrt willst du vielleicht deinen eigenen Schlüssel auf den Schlüsselservern veröffentlichen. Es ist wichtig, dass du dir gut überlegst, ob du das wirklich willst, denn einen Schlüssel vom Schlüsselserver löschen, ist je nach Schlüsselserver schwierig bis gar nicht möglich. Deshalb: Überleg dir, ob die E-Mail-Adresse da drin wirklich eine ist, die du unwiederbringlich öffentlich machen willst. Und stell sicher, dass dein Schlüssel ein vernünftiges Ablaufdatum hat (nicht zu weit entfernt). Wenn du das klar hast, dann kopier dir erstmal den Fingerabdruck deines Schlüssels, den du hochladen willst:

gpg -K
/home/schnuffelchen/.gnupg/pubring.kbx
-----------------------------------
sec   rsa4096 2342-02-16 [C] [expires: 2342-02-30]
      F096A0F52BDF836862827E448D631EC35A0B6427
uid           [ultimate] Schnuffelchen <schnuffelchen@pkx.be>

Und dann gib das Kommandozeilenargument --send-keys mit dem Fingerabdruck dahinter an:

gpg --send-keys F096A0F52BDF836862827E448D631EC35A0B6427
gpg: sending key 8D631EC35A0B6427 to hkps://keyserver.ubuntu.com

Das Gleiche kannst du dann noch mit beliebigen anderen Schlüsselservern wiederholen, um deinen Schlüssel gleich breit zu streuen, damit alle ihn schnell finden:

gpg --keyserver hkps://sks.hnet.se --send-keys F096A0F52BDF836862827E448D631EC35A0B6427

gpg --keyserver hkp://zkaan2xfbuxia2wpf7ofnkbz6r5zdbbvxbunvp5g2iebopbfc4iqmbad.onion --send-keys F096A0F52BDF836862827E448D631EC35A0B6427

Bei dem hier zuletzt aufgeführten Hagrid-Schlüsselserver (keys.openpgp.org) ist zu beachten, dass dort im Gegensatz zu den anderen Schlüsselservern dein Schlüssel nicht sofort mit User-ID abrufbar ist, sondern dir erst eine E-Mail-Nachricht zugestellt wird mit einem Weblink, den du aufrufen musst, bevor die User-ID freigeschaltet wird. Damit soll auf diesem Schlüsselserver das Problem der Fake-Schlüssel reduziert werden.

Technisch ist es möglich, dass du alle öffentlichen Schlüssel, die du hast, auf irgendwelche Schlüsselserver hochlädst. Um einen Schlüssel zu veröffentlichen, brauchst du nicht den dazu gehörenden geheimen Schlüssel. Technisch ist es möglich, dass du Schlüssel anderer Leute veröffentlichst. Bitte mach das nicht. Wenn du einen Schlüssel einer anderen Person von einem bestimmten Schlüsselserver bekommen hast, dann mit dieser Person den Fingerabdruck abgeglichen hast, dich der Identität der Person versichert hast und den Schlüssel signiert hast, dann kannst du den von dir signierten öffentlichen Schlüssel dieser Person auf demselben Schlüsselserver veröffentlichen, damit andere Leute auch sehen können, dass du den Schlüssel signiert hast, was deren Einschätzung von der Vertrauenswürdigkeit des Schlüssels beeinflussen könnte. Aber das ist ein ziemlicher Sonderfall. Im Allgemeinen ist es übergriffig und unhöflich, Schlüssel fremder Leute ohne deren Einverständnis zu veröffentlichen.

GnuPG macht es leider nicht so einfach, Schlüsselserver zu bedienen. Oft wirft GnuPG sehr wenig aussagekräftige Fehlermeldungen, die keinen Anhaltspunkt dafür geben, worin jetzt genau das Problem bestand und wie es zu beheben sein könnte:

gpg --keyserver hkps://keys.htu.at --send-keys 8D631EC35A0B6427
gpg: sending key 8D631EC35A0B6427 to hkps://keys.htu.at
gpg: keyserver send failed: General error
gpg: keyserver send failed: General error

gpg --keyserver hkp://keys.htu.at --send-keys 8D631EC35A0B6427
gpg: sending key 8D631EC35A0B6427 to hkp://keys.htu.at
gpg: keyserver send failed: End of file
gpg: keyserver send failed: End of file

gpg --keyserver hkps://sks.ygrek.org --send-keys 8D631EC35A0B6427
gpg: sending key 8D631EC35A0B6427 to hkps://sks.ygrek.org
gpg: keyserver send failed: No data
gpg: keyserver send failed: No data

gpg --keyserver hkps://zuul.rediris.es --send-keys 8D631EC35A0B6427
gpg: sending key 8D631EC35A0B6427 to hkps://zuul.rediris.es
gpg: keyserver send failed: No keyserver available
gpg: keyserver send failed: No keyserver available

gpg --keyserver hkps://tippfehler.example.com --send-keys 8D631EC35A0B6427
gpg: sending key 8D631EC35A0B6427 to hkps://tippfehler.example.com
gpg: keyserver send failed: No name
gpg: keyserver send failed: No name

Manchmal geht es dann, wenn du es wann anders probierst, mit einem anderen Schlüsselserver oder mit hkp: statt hkps:, das unverschlüsselt und nicht authentifiziert ist, was in dem Fall kein allzu signifikantes Problem darstellen sollte. Aber ganz ehrlich: Du bist nicht allein verantwortlich dafür, die Kaputtheit der Welt zu lösen. Wenn es nicht geht, dann geht es nicht. Du musst deinen Leuten nur sagen können, wo sie deinen Schlüssel finden können.

Eine deutlich einfachere (aber auch voraussetzungsreichere) Variante, an Schlüssel zu kommen, ist WKD (web key directory). Damit wird nicht wild auf irgendwelchen Schlüsselservern gesucht, sondern der Schlüssel für die Adresse beispieladresse@beispieldomain.fun an einer bestimmten URL unter einer Subdomain von https://beispieldomain.fun runtergeladen. Wenn du mit GnuPG eine Nachricht an eine E-Mail-Adresse verschlüsseln willst, zu der du noch keinen Schlüssel hast, dann holt sich GnuPG den Schlüssel automatisch per WKD. Du kannst das aber auch selber anstoßen:

gpg --locate-keys postmaster@proton.me
gpg: key C3860937D651021D: public key "postmaster@proton.me <postmaster@proton.me>" imported
gpg: Total number processed: 1
gpg:               imported: 1
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   4  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 4u
gpg: next trustdb check due at 2342-04-08
pub   ed25519 2022-05-03 [SC]
      740E47C8D4695B8A6B30670CC3860937D651021D
uid           [ unknown] postmaster@proton.me <postmaster@proton.me>
sub   cv25519 2022-05-03 [E]

Das steht jetzt zwar nicht explizit da, wo der Schlüssel, der hier importiert wurde, auf einmal herkam – GnuPG unterschlägt da leider interessante Informationen – aber der wurde per WKD bezogen. Wenn dir eine Adresse unterkommt, die auf @proton.me endet, dann ist die Wahrscheinlichkeit hoch, dass du den Schlüssel per WKD bekommen kannst. Ob ein Schlüssel für eine bestimmte E-Mail-Adresse per WKD angeboten wird, hängt davon ab, ob die Person, die die Domain (das nach dem @) betreibt, da Bock drauf hat. Bei protonmail.com und proton.me: Ja. Bei mailbox.org: Ja. Bei posteo.de: Im Prinzip ja, aber als Posteo-Kund*in wird es einem schwergemacht, das zu nutzen. Bei riseup.net: Als ich zuletzt geguckt habe, leider immer noch nein, aber vielleicht wird’s ja irgendwann nochmal was. Bei gmx.net, gmail.com und sonstigem Geschrappel: Ausgeschlossen. Bei Leuten, die eine eigene E-Mail-Domain verwenden (richy@familie-hasenpups.de), hängt es von den Leuten selber ab, ob sie ihren Schlüssel per WKD anbieten. Also: ausprobieren und im Zweifelsfall die Person fragen, wo man denn ihren Schlüssel her bekäme, wenn du ihn selber nicht findest.

Du kannst deinen eigenen Schlüssel auch per WKD anbieten. Dazu musst du entweder selbst die Kontrolle über die Domain(s) deiner E-Mail-Adresse(n) haben oder bei einem E-Mail-Provider sein, der die Bereitstellung von Schlüsseln via WKD erlaubt. Für den zweiten Fall guck mal in der Dokumentation deines E-Mail-Providers nach oder frage bohrend nach, wenn der das noch nicht anbietet. Je mehr Kund*innen WKD nachfragen, desto eher wird das mal angeboten. Der erste Fall erfordet etwas technisches Verständnis über Domains und optional Webserver (oder Freund*innen, die das für dich erledigen können).

Hier sind ein paar Gedanken zum Thema eigene Domain und WKD.

Es gibt Anleitungen, die eher für Web-Profis geeignet sind. Der Schlüsselserver keys.openpgp.org bietet auch WKD as a service an. Wenn du deine E-Mail-Domain selber unter Kontrolle hast, aber nicht den Aufwand betreiben willst, deinen Webserver zu konfigurieren, dann kannst du das Angebot nutzen. Du kannst es auch nutzen, wenn du Geld sparen willst: Eine .de-Domain kostet weniger als 5 € im Jahr. Das (und ein E-Mail-Provider, der es dir erlaubt, deine eigene Domain aufzuschalten, statt nur die vom E-Mail-Provider angebotenen E-Mail-Domains zu nutzen (bei Tutanota für 1 € im Monat, bestimmt bei einigen anderen auch möglich, mit dem Hilfsdienst ImprovMX (Vorsicht, schlimmer Tracking-Link) kostenlos nachrüstbar)) ist alles, was du für WKD as a service brauchst.

Wenn du nicht WKD as a service nutzen willst, sondern deinen Schlüssel selbst per WKD ausliefern willst, dann brauchst du zusätzlich zur Domain noch Webspace, der etwas mehr kostet (dreivier € pro Monat schätzungsweise). Vielleicht lohnt sich das nicht, wenn WKD dein einziger Anwendungsfall dafür ist, aber du kannst ihn dir vielleicht mit anderen Personen in deinem Umfeld teilen. Die Kommunikationsinfrastruktur ein bisschen mehr in die eigene Hand zu nehmen, statt sie sich „kostenlos“ gegen deine großzügige Datenspende bei irgendwelchen Werbe-Drecksbuden zu holen (Es gibt nichts geschenkt. Schon gar nicht im Internet.), macht Dinge langfristig einfacher und ist dir vielleicht eine geringe einstellige Anzahl Kröten pro Monat wert, wenn du nach der Lektüre dieser Anleitung ein bisschen sicherheitsbewusster geworden bist.

Kurzum mein Tip: Besorg dir bei einem Dienst wie INWX oder Tecspace eine Domain und bei einem Dienst wie Uberspace Zugang zu einem vorkonfigurierten Mailserver und Webserver. Alles zusammen kommst du bei zwei bis sechs Euro im Monat raus. Wie du dann die Domain für Web und E-Mail konfigurierst und wie du dir eine E-Mail-Adresse ich@meinedomain.de einrichtest, steht alles lang und breit in der Uberspace-Anleitung. Auch wie du auf Uberspace WKD einrichtest, ist dort ausführlich beschrieben. Das ist die beste Lösung; zwar im Prinzip Overkill für einfach nur eine E-Mail-Adresse, aber vielleicht motiviert dich das, dann noch mehr mit deiner selbstverwalteten Infrastruktur zu machen. Im engeren Sinne brauchen tust du das natürlich nicht. OpenPGP funktioniert auch ohne WKD, also kein Stress.

Schlüssel und andere Dinge widerrufen

Wenn du aufhören willst, deinen OpenPGP-Schlüssel zu benutzen, warum auch immer, dann denkst du vielleicht, dass es eine gute Idee wäre, einfach aufzuhören, ihn zu benutzen, ihn lokal bei dir zu löschen und fortan einen neu erzeugten OpenPGP-Schlüssel zu verteilen. Das ist aber nicht die beste Idee. Die anderen wissen ja erstmal nicht, dass dein alter Schlüssel nicht mehr verwendet werden soll. Er ist erstmal noch gültig, so lange, bis er abgelaufen ist. (Unter anderem deshalb solltest du ein vernünftiges Ablaufdatum wählen.) Wenn der Grund dafür, dass du dir ein neues Schlüsselpaar generiert hast, der ist, dass du unachtsam warst und eventuell jemand anderes deinen bisherigen geheimen Schlüssel hätte abgreifen können, dann bringt es auch nicht so schrecklich viel, das Ablaufdatum abzuwarten. Denn eine andere Person im Besitz des geheimen Schlüssels könnte auch einfach das Ablaufdatum nach hinten schieben oder den Schlüssel unendlich lange gültig machen (falls der kompromittierte Schlüssel zertifizierungsfähig war). Einen Schlüssel zu löschen, bringt auch nicht so viel, denn das Internet vergisst nicht. Von Schlüsselservern kriegst du den Schlüssel höchstwahrscheinlich sowieso nicht mehr weggelöscht. Also freunde dich damit an, dass er da ist.

Was du machen kannst, ist: Mithilfe deines (alten) geheimen Schlüssels eine neue Signatur an deinen Schlüssel packen, die sagt: „Bitte diesen Schlüssel nicht mehr verwenden!“ In dem ganzen OpenPGP-Ökosystem werden beim Schlüsselaustausch ja immer nur Signaturen an Schlüssel angefügt, nie gelöscht. Das heißt, dass eine bösartige Person, die dir deinen alten geheimen Schlüssel abgenommen hat, zwar alles Mögliche mit diesem Schlüssel machen kann (deine alten verschlüsselten Nachrichten lesen zum Beispiel, Signaturen von dir fälschen usw.), aber den von dir verteilten Widerruf dieses Schlüssels kann sie nicht rückgängig machen. Alle Leute, die dein Widerrufszertifikat einmal bekommen haben, werden deinen alten Schlüssel fortan nicht mehr benutzen.

Vielleicht erinnerst du dich, dass GnuPG vorhin, als du ein neues Schlüsselpaar erzeugt hast, am Ende mit unter anderem diesen zwei Zeilen geantwortet hat:

gpg: directory '/home/schnuffelchen/.gnupg/openpgp-revocs.d' created
gpg: revocation certificate stored as '/home/schnuffelchen/.gnupg/openpgp-revocs.d/F096A0F52BDF836862827E448D631EC35A0B6427.rev'

Das bedeutet: Direkt bei der Erstellung eines Schlüsselpaares signiert GnuPG automatisch – ohne dass du das extra bestätigen müsstest – mit deinem neu erstellten geheimen Schlüssel eine Kopie des öffentlichen Schlüssels mit angehängtem Widerruf eben dieses Schlüssels und speichert das Ergebnis in einer Textdatei. In der Datei steht also einfach dein öffentlicher Schlüssel drin; ungefähr das Gleiche, was du auch bekommst, wenn du

gpg -ao dateiname.txt --export schnuffel

eingibst. Nur in diesem Fall ist eine zusätzliche Signatur dran, die sagt, dass der Schlüssel nicht mehr benutzbar sein soll. Wenn du die Datei bei dir lokal importierst mit

gpg --import /home/schnuffelchen/.gnupg/openpgp-revocs.d/F096A0F52BDF836862827E448D631EC35A0B6427.rev

dann ist der Schlüssel bei dir lokal nicht mehr benutzbar. Wenn du die Datei auf Schlüsselservern hochlädtst und deinen so widerrufenen Schlüssel per WKD veröffentlichst, dann verteilt sich die Widerrufssignatur auf der ganzen Welt. Alle Leute werden sie bekommen, falls sie jemals versuchen, deinen Schlüssel irgendwie zu aktualisieren, was sie einst tun müssen, wenn du ein vernünftiges Ablaufdatum eingestellt hast.

Du kannst von Schlüsseln, deren geheimen Schlüssel du hast, jederzeit ein Widerrufszertifikat erzeugen. Das automatisch erzeugte Widerrufszertifikat brauchst du nicht unbedingt:

gpg --gen-revoke schnuffel

sec  rsa4096/8D631EC35A0B6427 2342-02-16 Schnuffelchen <baerbel.schnuff@flowerpower.enterprises>

Create a revocation certificate for this key? (y/N) y
Please select the reason for the revocation:
  0 = No reason specified
  1 = Key has been compromised
  2 = Key is superseded
  3 = Key is no longer used
  Q = Cancel
(Probably you want to select 1 here)
Your decision? 1
Enter an optional description; end it with an empty line:
> Das passiert mir nicht nochmal.
> ↵
Reason for revocation: Key has been compromised
Das passiert mir nicht nochmal.
Is this okay? (y/N) y
ASCII armored output forced.
-----BEGIN PGP PUBLIC KEY BLOCK-----
Comment: This is a revocation certificate

iQJVBCABCAA/FiEE8Jag9Svfg2hign5EjWMew1oLZCcFAmQ0PYQhHQJEYXMgcGFz
c2llcnQgbWlyIG5pY2h0IG5vY2htYWwuAAoJEI1jHsNaC2QnAt0QAKgye3RU33CR
…
4cj25J1owfSQ3+4Fmlz5AOovOujIhcCGA3DvHBgUCWfhO+OVcFz312wDJ1MUJNSY
8wp8W8uvwf6+6+jcMt8GJzIzVNDUCfmIenKqZrLJklrv7EtqHgJ6237J+JLMso1K
FiPUBXmpVXw0oCuPzOTEMR88xZC5/kNZ
=Dke5
-----END PGP PUBLIC KEY BLOCK-----
Revocation certificate created.

Please move it to a medium which you can hide away; if Mallory gets
access to this certificate he can use it to make your key unusable.
It is smart to print this certificate and store it away, just in case
your media become unreadable.  But have some caution:  The print system of
your machine might store the data and make it available to others!

Wenn du das gemacht hast, dann kannst du dein neues Widerrufszertifikat lokal importieren:

gpg --import
-----BEGIN PGP PUBLIC KEY BLOCK-----
Comment: This is a revocation certificate

iQJVBCABCAA/FiEE8Jag9Svfg2hign5EjWMew1oLZCcFAmQ0PYQhHQJEYXMgcGFz
c2llcnQgbWlyIG5pY2h0IG5vY2htYWwuAAoJEI1jHsNaC2QnAt0QAKgye3RU33CR
…
4cj25J1owfSQ3+4Fmlz5AOovOujIhcCGA3DvHBgUCWfhO+OVcFz312wDJ1MUJNSY
8wp8W8uvwf6+6+jcMt8GJzIzVNDUCfmIenKqZrLJklrv7EtqHgJ6237J+JLMso1K
FiPUBXmpVXw0oCuPzOTEMR88xZC5/kNZ
=Dke5
-----END PGP PUBLIC KEY BLOCK-----
Strg-D
gpg: key 8D631EC35A0B6427: "Schnuffelchen <baerbel.schnuff@flowerpower.enterprises>" revocation certificate imported
gpg: Total number processed: 1
gpg:    new key revocations: 1
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   5  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 5u
gpg: next trustdb check due at 2342-04-15

Lokal bei dir gilt dein Schlüssel damit als widerrufen und nicht mehr benutzbar. Solange du den Widerruf nicht veröffentlichst, werden alle anderen aber nichts davon erfahren.

Lokal kannst du deinen Widerruf rückgängig machen, indem du deinen nicht widerrufenen Schlüssel aus deinem Backup wiederherstellst. Einen veröffentlichten Widerruf rückgängig zu machen, ist im Allgemeinen nicht möglich.

Du kannst also jederzeit ein Widerrufszertifikat erzeugen. Wofür braucht man dann überhaupt das bei der Schlüsselerzeugung automatisch generierte Widerrufszertifikat? Das frage ich mich auch. Am ehesten dann, wenn du dein Mantra vergessen hast oder wegen schlechten Backups keinen Zugriff mehr auf deinen geheimen Schlüssel hast. Obwohl du bei mangelhaftem Backup sicherlich auch keinen Zugriff mehr auf das vorab erzeugte Widerrufszertifikat haben dürftest. Also eigentlich nur dann, wenn du dein Mantra vergessen hast. Das passiert dir vielleicht am Anfang, wenn du es noch nicht tausendmal eingegeben hast. Deshalb empfehle ich für den Anfang eine sehr kurze Gültigkeitsdauer. Dann brauchst du auch kein Widerrufszertifikat, sondern kannst einfach das Ablaufdatum abwarten.

Meiner Meinung nach brauchst du dieses vorab generierte Widerrufszertifikat nicht. Es richtet nur potenziell Schaden an, wenn es da so rumliegt: Wer dir Böses will, könnte es veröffentlichen, und dann hast du den Stress, dass du einen neuen Schlüssel verteilen und dir neues Vertrauen etablieren musst. Meine Empfehlung also lautet: Wenn du grad keine Ahnung hast, was du mit diesem Widerrufszertifikat unter .gnupg/openpgp-revocs.d/ anfangen sollst, dann lösche es am besten. So macht es dir später keinen Ärger.

Du kannst nicht nur deine Schlüssel widerrufen. Du kannst auch deine User-IDs widerrufen (aus denselben Gründen wie oben besser widerrufen statt einfach löschen, weil sie durch bloßes Löschen nicht weltweit verschwinden werden), wenn du zum Beispiel eine bestimmte E-Mail-Adresse nicht mehr benutzt. Du kannst auch einzelne Unterschlüssel widerrufen, und auch von dir selbst erstellte Signaturen – sowohl an deinem eigenen Schlüssel als auch an anderer Leute Schlüsseln. Ich gehe da jetzt nicht weiter drauf ein, weil du das für den Anfang höchstwahrscheinlich nicht brauchst. Wenn es dich näher interessiert, kannst du das selber in der GnuPG-Manpage nachlesen und damit rumexperimentieren. Wenn du geübter im Umgang mit OpenPGP und Kryptographie im Allgemeinen wirst, dann wirst du sicherlich feststellen, dass es immer gut ist, Schlüssel oft zu wechseln, damit eventuelle Kompromittierungen nicht ganz so schlimm sind. Das heißt, du wirst wahrscheinlich oft deine Unterschlüssel widerrufen und neu erzeugen wollen und du wirst vielleicht auch deinen Hauptschlüssel widerrufen und den neu erzeugten Hauptschlüssel mit dem alten signieren wollen.

E-Mail-Clients

Du hast jetzt einen ganzen Haufen darüber gelernt, wie OpenPGP an sich funktioniert. Du kannst es mithilfe von GnuPG auf der Kommandozeile anwenden. Bekanntlich wird OpenPGP oft zusammen mit E-Mail benutzt. Vielleicht fragst du dich, wie das zusammenhängt, weil bis jetzt in dieser ganzen Anleitung noch keine einzige E-Mail-Nachricht verschickt wurde.

OpenPGP musst du nicht zusammen mit E-Mail verwenden. Es ist nur ein Datenformat. Du kannst deine OpenPGP-gesicherten Nachrichten über SMS, Brieftauben oder Forumsbeiträge mit anderen Leuten austauschen. Du kannst auch über OpenPGP-signierte Zettel in der Küche mit deinen Mitbewohnis kommunizieren.

Aber stimmt schon: Der klassische Anwendungsfall ist E-Mail. Und da funktioniert es ebenso wie in allen anderen Anwendungsfällen ziemlich direkt und geradeaus: Du schreibst einen Text, signierst und verschlüsselst den auf der Kommandozeile mithilfe von GnuPG und verschickst das Ergebnis per E-Mail. Die Empfänger*in benutzt auch GnuPG oder eine andere OpenPGP-Software und kann den Prozess rückabwickeln. Fertig.

Es gibt Programme – sog. E-Mail-Clients –, die die Verarbeitung von E-Mail-Nachrichten auf verschiedene Weise erheblich vereinfachen können. Eine Vereinfachung, die in solchen E-Mail-Clients eingebaut sein kann, ist die Automatisierung dieses Prozesses: signieren, verschlüsseln, in E-Mail-Nachricht reinkopieren, aus E-Mail-Nachricht rauskopieren, entschlüsseln, Signatur verifizieren. Das will man nicht immer händisch erledigen. Ein E-Mail-Client ist dabei eine große Hilfe, aber strenggenommen nicht unbedingt notwendig. Weil ich davon ausgehe, dass du es kaum länger als ein paar Tage durchhalten wirst, deine E-Mail-Kryptographie ohne E-Mail-Client abzuwickeln, empfehle ich dir die Installation eines solchen, falls du nicht eh schon einen hast, der OpenPGP kann.

Hier kannst du mehr über E-Mail-Clients erfahren, wenn du willst.

Es gibt, wie du dir denken kannst, Fantastilliarden von E-Mail-Clients, einer schlimmer als der andere. Mir fallen folgende ein, die ich für erwähnenswert halte (nicht-abschließende Auflistung):

KMail: Das ist ein auf Bedienkomfort für Anfänger*innen optimierter E-Mail-Client, der die Fähigkeiten von GnuPG gut ausnutzt; auch WKD, was nicht selbstverständlich ist. Möglicherweise hast du KMail schon installiert, wenn du KDE Plasma als Desktopumgebung benutzt, was durchaus sein könnte, wenn du ein freies Betriebssystem hast. Guck einfach mal nach, ob du es im Anwendungsmenü findest oder was passiert, wenn du auf der Kommandozeile kmail eingibst. Da KMail tief im KDE-Plasma-System verankert ist, lässt es sich möglicherweise schlecht nachinstallieren, wenn du es nicht sowieso schon hast. Aber probier es gerne mal aus. Hier ist eine englische Kurzeinführung in die OpenPGP-Nutzung mit KMail. Die deutsche Version davon wurde anscheinend automatisch übersetzt und hat ein paar sinnentstellende Fehler. Ein Nachteil von KMail ist auf jeden Fall, dass es ein echter Batzen ist. Es ist der Sicherheit in der Regel nicht zuträglich, wenn eine Software übermäßig viele Automatismen hat, die du nicht bewusst selbst aktiviert hast, sondern die quasi im Lieferumfang enthalten sind.
Evolution: Ebenso wie KMail kommt Evolution mit einer gut klickbaren Oberfläche. Der wesentliche Unterschied ist, dass Evolution nicht in den KDE-Plasma-Desktop, sondern in den Gnome-Desktop fest integriert ist. Es kann also sein, dass du Evolution eh schon hast, falls du Gnome hast. Du kannst mal gucken, ob der Befehl evolution auf der Kommandozeile etwas tut. Wenn du Gnome gar nicht hast, dann ist auch das Schwergewicht Evolution schwer nachzuinstallieren, weil es zig Abhängigkeiten nach sich zieht, aber probieren geht über studieren. Die offizielle Anleitung ist gut und knackig. Der gleiche Nachteil, der auf KMail zutrifft, gilt auch für Evolution.
Claws Mail: Das ist ein leichtgewichtigerer E-Mail-Client, dessen Oberfläche grob an die vorgenannten erinnert, aber etwas in die Jahre gekommen aussieht. Claws Mail versucht, nichts wegzuautomatisieren, worüber du vielleicht die Kontrolle behalten willst. Wenn dir Sicherheit wichtiger ist als ein modernes Layout und fette Features, dann ist das vielleicht was für dich. Zusätzlich zu Claws Mail selbst musst du noch die drei Plugins PGP/Core, PGP/Inline und PGP/MIME installieren, die unter einem Paketnamen wie claws-mail-pgp oder so ähnlich in deinem Paketmanager zu finden sein könnten und auf der Programmoberfläche von Claws Mail dann noch aktiviert werden müssen.
Sylpheed: Aus Sylpheed ist Claws Mail entstanden. Sylpheed ist noch schlichter gehalten als Claws Mail, wird aber anscheinend nicht mehr weiterentwickelt. Da Software tendenziell umso unsicherer wird, je komplexer sie ist, und Sylpheed hinsichtlich Komplexität eher am unteren Ende zu verorten ist, dürfte das trotzdem sicher genug sein, weil es die ganzen potenziell gefährlichen Features moderner erscheinender E-Mail-Clients einfach gar nicht erst hat. Auf der Sylpheed-Website steht, dass die GnuPG-Integration ganz einfach funktionieren soll.
Mutt: Wenn dir die Kommandozeile zusagt, dann könnte Mutt etwas für dich sein. Mutt läuft nämlich im Textmodus auf der Kommandozeile und lässt sich mit der Tastatur bedienen. Nachteil von Mutt ist, dass am Anfang die Lernkurve ein bisschen steil ist, je nach deinem Vorwissen. Es gibt aber viele Anleitungen und Beispielkonfigurationen. Vorteil von Mutt ist, dass man damit tatsächlich so ziemlich alles machen kann. Volle Kontrolle über alles, was passiert, gibt es bei Mutt. Und du bist dann zwangsläufig ein E-Mail-Profi und auch als solcher zu erkennen.
K-9 Mail: Das ist ein E-Mail-Client für Android. Da wir hier noch in der Laptop-/Desktop-Sektion sind, lass uns im Abschnitt „Lobotomierte Computer“ darüber reden.
kommerzielle wie Microsoft Outlook, Apple Mail usw.: Ja, auch solche unfreien Schlachtschiffe, die ein beträchtliches Vorstrafenregister an schweren Sicherheitsproblemen hinter sich herziehen, lassen sich im Prinzip mit inoffiziellen Plugins GnuPG-kompatibel hinwurschteln. Aber sollte man? Wohl nur, wenn du ganz ganz dringende unabwendbare Gründe hast, genau eines dieser Horrorprogramme unbedingt benutzen zu müssen.
Thunderbird: Viele Leute benutzen Thunderbird. Wohl vor allem aus Tradition. Ich möchte an dieser Stelle einmal dringlichst davon abraten, jetzt neu mit Thunderbird anzufangen, denn die OpenPGP-Unterstützung ist eine unfassbare Vollkatastrophe. Sehr häufig findet man noch veraltete Verlautbarungen und Anleitungen. Wenn Thunderbird im Zusammenhang mit dem Plugin Enigmail erwähnt wird, dann ist diese Aussage veraltet. Seit 2020 geht Thunderbird komplett eigene Wege, unterstützt das Plugin Enigmail nicht mehr und erfindet OpenPGP neu – und zwar in schlecht, unsicher und unbenutzbar. Eine Abhandlung darüber, was an Thunderbird alles kaputt ist, spare ich mir hier. Benutz es einfach nicht, um die Nerven deiner Kommunikationspartner*innen zu schonen, und deine eigenen auch.

Ich gehe jetzt nicht im Detail darauf ein, wie die einzelnen E-Mail-Clients einzurichten sind. Wahrscheinlich findest du dazu Anleitungen. Zusätzlich zur Dokumentation des E-Mail-Clients brauchst du auch noch Infos von deinem E-Mail-Provider. Die erste Maßnahme nach der Installation des E-Mail-Clients ist nämlich, dass du deinem E-Mail-Client ein paar Daten gibst, wie E-Mail-Nachrichten abzurufen und zu verschicken seien. Von deinem E-Mail-Provider brauchst du die Information, unter welchem Domainnamen der Postausgangsserver (SMTP-Server) erreichbar ist, wie du den Posteingangsserver (POP3- oder IMAP-Server, je nach dem, was dir lieber ist) erreichst, ob jeweils TLS direkt unterstützt wird oder du STARTTLS in deinem E-Mail-Client konfigurieren musst und wie dein Loginname lautet (meistens deine komplette E-Mail-Adresse oder nur der Teil vor dem @, manchmal aber auch etwas ganz anderes).

Wenn dein E-Mail-Client dich nicht sofort mit einem Kontoeinrichtungs-Assistenten begrüßt, dann musst du mal gucken, wie du ein neues E-Mail-Konto in diesem Programm anlegen kannst, wo du dann diese ganzen Daten von deinem E-Mail-Provider eingibst.

Oft hast du die Wahl zwischen POP3 und IMAP als Methode, um eingehende E-Mail-Nachrichten von deinem E-Mail-Server abzurufen. Weil das OpenPGP-relevant sein kann, will ich dazu auch noch einen Satz schreiben.

POP3 ist ein sehr einfaches Protokoll, das nur auf dem Server liegende Nachrichten auflisten, von dir benannte Nachrichten runterladen und von dir benannte Nachrichten auf dem Server löschen kann. Also eigentlich nur die drei Befehle: auflisten, runterladen, löschen. E-Mail-Clients werden in der Standardeinstellung in der Regel alle noch nicht runtergeladenen Nachrichten runterladen und die runtergeladenen Nachrichten dann auf dem Server löschen. Wenn du erstmal nur ausprobieren willst und vielleicht noch parallel einen anderen E-Mail-Client benutzt (z. B. den Webmail-Client deines E-Mail-Providers), dann ist der Teil mit dem Löschen vielleicht zu invasiv. Also guck sicherheitshalber vor dem ersten E-Mail-Abruf mit deinem neuen E-Mail-Client nochmal in der Konfiguration nach, ob das Häkchen vor „Nachrichten nach Abruf auf dem Server löschen“ oder so ähnlich nicht gesetzt ist.

IMAP kann mehr als POP3. IMAP kann Ordner. Wenn du lokal in deinem E-Mail-Client eine Nachricht in einen anderen Ordner verschiebst, dann ist sie auch auf dem Server verschoben. Du hast also in jedem E-Mail-Client die gleiche Ansicht auf dein Postfach. Das ist eigentlich nur dann relevant, wenn du mehrere E-Mail-Clients benutzt (weil du z. B. mehrere Geräte hast). Nachteil von IMAP ist, dass du eigentlich immer eine funktionierende Verbindung zu deinem E-Mail-Server brauchst, um E-Mail-Nachrichten lesen zu können (es sei denn, dein E-Mail-Client findet irgendeinen Supertrick, um Nachrichten doch offline zu speichern und nur bei bestehender Internetverbindung mit dem Server abzugleichen). Problematisch an IMAP im Zusammenhang mit OpenPGP ist, dass du wahrscheinlich auch einen Ordner für gesendete Nachrichten und einen Ordner für Entwürfe hast, deren Inhalt eben auch an deinen E-Mail-Provider übermittelt werden. Selten im Gesendet-Ordner, etwas häufiger im Entwürfe-Ordner, liegen Nachrichten gerne mal im Klartext, bevor sie verschlüsselt und rausgeschickt werden. Sei dir dieses Problems auf jeden Fall bewusst und hab deine Konfiguration im Griff, wenn du IMAP benutzt.

Zusammengefasst: IMAP kann mehr, viele Leute finden das komfortabler. Es ist aber auch komplexer und schwerer zu bändigen. Wenn du Sicherheitsanforderungen hast und einfaches POP3 dir reicht, dann nimm lieber das. Da geht weniger kaputt.

Nachdem du das gemacht und erfolgreich getestet hast, kannst du mal gucken, wie in deinem E-Mail-Client zu einem bestimmten E-Mail-Konto die OpenPGP-Unterstützung aktiviert werden kann. Das funktioniert wohl je nach Programm mehr oder weniger automatisch.

Nicht stolpern

Rein mathematisch ist OpenPGP sicher. Auch die NSA kommt nicht an deine Daten ran und kann deine Signaturen nicht fälschen, wenn du hinreichend starke OpenPGP-Schlüssel verwendest. Aktuelle Kryptographie wird nicht mathematisch gebrochen, aber Kryptographie wird gebrochen; und zwar aufgrund des menschlichen Faktors. Ich will in diesem Abschnitt ein paar Hinweise dazu geben, wie du es vermeidest, dir selbst ins Knie zu schießen und deine ganze technisch ausgefeilte Kryptographie wertlos zu machen.

Vermeide „Vereinfachungen“

Sehr wahrscheinlich ist die Bedienung von GnuPG nicht perfekt. Für ein Kommandozeilenwerkzeug ist es schon ziemlich gut, aber auf keinen Fall perfekt. Wenn du gerne mit der Maus und einem großen bunten Monitor mit deinem Computer interagierst, oder mit einem Touch-Display, oder mit noch anderen Ein- und Ausgabemedien, dann wirkt GnuPG für dich wahrscheinlich sogar relativ feindlich. Wenn du es nicht gewohnt bist, Referenzhandbücher zu lesen, sondern erwartest, dass die nächsten Interaktionsmöglichkeiten von deiner Software auf deinem Bildschirm angeboten werden, dann wirkt ein Programm wie GnuPG auf dich vielleicht abschreckend, wo man genau eingeben muss, was man erreichen will. Das „Komplizierte“ an GnuPG ist wahrscheinlich genau das: dass diese Art, mit deinem Computer zu interagieren, für dich neu ist und du dich schwer daran gewöhnen kannst. Das „Komplizierte“ an GnuPG ist aber nicht, dass man da so viele Sachen gefragt wird und informierte Entscheidungen fällen muss. Das ist nicht kompliziert, sondern das ist angemessen komplex. Es entspricht ziemlich genau der Komplexität von asymmetrischer Kryptographie selbst. Das heißt: Um OpenPGP gut und sicher anwenden zu können, musst du verstehen, was du da tust; und GnuPG nimmt dir die Pflicht zum Verstehen nicht ab, sondern bildet die Komplexität der Sache in der Bedienoberfläche ab. Man kann diese Oberfläche an verschiedene Bedürfnisse anpassen, man kann sie bunter, klickbarer, moderner aussend machen, man kann sie besser in verschiedene Sprachen übersetzen, man kann häufige Aktionen automatisieren. Aber man kann nicht real existierende Komplexität vor der Anwender*in verstecken, ohne damit Sicherheit einzubüßen, denn wenn eine komplexe Sache unterkomplex dargestellt wird, dann hast du nicht mehr zu jeder Zeit die volle Kontrolle darüber, was gerade passiert. Durch so etwas entstehen überraschende Sicherheitslecks.

Deshalb habe ich so viel über die Bedienung von GnuPG auf der Kommandozeile geschrieben. Wenn du eine andere Software verwendest, die intern auf GnuPG aufsetzt, dir aber ein bisschen besser bedienbar erscheint, dann kannst du immer noch auf die Kommandozeile ausweichen, wenn du mal den Überblick verloren hast und gucken willst, was gerade wirklich vor sich geht.

Zur Schlüsselverwaltung kannst du zum Beispiel optional graphische Programme wie Kleopatra, KGpg (beide in KDE Plasma integriert) und Seahorse (in Gnome integriert) benutzen, die dir einfach nur eine graphische Oberfläche bieten, hintenrum aber ganz normal GnuPG benutzen. (Möglicherweise ist eins dieser Programme in deinem Betriebssystem schon vorinstalliert.) Auf einen Teil der Funktionalität von GnuPG kannst du also auch über diese graphischen Werkzeuge zugreifen. Wenn du eigentlich verstehst, wie deine Kryptographie funktioniert, und du benutzt ein Programm, das dir deinen Umgang damit vereinfacht, dann ist dagegen nichts einzuwenden. Auch manche E-Mail-Clients wie KMail und Evolution haben eine Schlüsselverwaltung eingebaut, mit der du sicherlich viele Sachen erledigen kannst, ohne auf die Kommandozeile angewiesen zu sein – unter der Voraussetzung, dass du verstehst, welche Fragen dich diese Werkzeuge nicht fragen, sondern sich selbst mit Standardantworten beantworten, und unter der Voraussetzung, dass du mit diesen Standardantworten einverstanden bist.

Ich warne vor Thunderbird, weil es mit diesem E-Mail-Client sehr schwer ist, noch die Kontrolle darüber zu behalten, was gerade kryptotechnisch passiert. Wer sich wirklich gut auskennt und Thunderbird in seiner Tiefe verstanden hat und OpenPGP auch gut verstanden hat, kann Thunderbird mit ein paar Anpassungen sicherlich dennoch benutzen. Diese Leute sind aber nicht die Zielgruppe von Thunderbird, sondern die Zielgruppe sind die, die fast nichts verstanden haben und wollen, dass es „einfach geht“. Und damit ist die Kryptographie dann kaputt.

Mozilla, die Leute hinter Thunderbird, dachten sich wohl so: Schlüssel signieren? Versteht keine Sau, was das tut und soll. Immer das Mantra eingeben müssen, wenn man Zugriff auf den geheimen Schlüssel braucht? Viel zu kompliziert, will niemand. Neues Schlüsselpaar erzeugen, wenn man noch keins hat? Da werden viel zu viele komische Fragen gestellt, auf die die Leute keine Antwort haben. Lass uns das alles aus der Bedienoberfläche rausschmeißen, was die Leute uninteressant und abschreckend finden! Vielleicht benutzen sie dann OpenPGP falsch und unsicher, aber zumindest benutzen sie es!! Und es gibt einen Knopf mit Schlösschen drauf, der sagt, dass es sicher sei!!! Das sieht doch gut aus!!!!

Wenn du deine eigene Kryptographie, mit der du nur deine eigenen Daten verschlüsselst, kaputt machst, dann ist das natürlich deine Sache, aber bei OpenPGP geht es ja um Kommunikation. Das heißt, du müsstest alle deine Kommunikationspartner*innen (in spe) fragen, ob sie gestatten, dass du Thunderbird oder andere inhärent unsichere Software benutzt. Vielleicht ist dir selbst das alles nicht so wichtig und du denkst irrtümlich, du hättest eh nichts zu verbergen. Aber deinem öffentlichen Schlüssel sieht man das nicht unbedingt an, dass du Thunderbird benutzt (es gibt ein paar Indizien). Vielleicht schickt dir jemand eine wirklich geheime Information, die nur für dich bestimmt ist, in der Erwartung, dass OpenPGP ja sicher ist (was es an sich ist). Wenn aber dein geheimer Schlüssel, mit dem der Inhalt dieser Nachricht offenliegt, irgendwann einmal unverschlüsselt in der Apple-Cloud oder so landet oder gelandet ist, weil Thunderbird, dann hast du ein ernsthaftes Problem verursacht, das du vermieden hättest, wenn du erst gar nicht mit OpenPGP angefangen hättest. Dann hätte diese Person dir diese Nachricht nämlich nicht geschickt.

Aber ich will nicht so viel immer nur auf Thunderbird rumhacken, weil das nur eine von ganz vielen Katastrophen ist. Jeder E-Mail-Client, der beim Anzeigen von E-Mail-Nachrichten mehr macht als sie einfach nur anzuzeigen, ist generell unsicher und in Bezug auf OpenPGP ganz besonders untauglich. Eine E-Mail-Nachricht besteht aus Text. Wenn der angezeigt wird, dann passiert nichts, außer dass der Text angezeigt wird. Es wird keine Empfangs- oder Lesebestätigung geschickt, es wird kein Programm gestartet, es wird keine Verbindung zu einem Webserver aufgenommen, nichts. Wenn doch, dann ist kaputt.

Faustregel: Vermeide Software, die so komplex ist, dass du sie nicht verstehst (auch wenn sie damit irgendwelche vermeintlichen „Vereinfachungen“ erreichen will), denn Überkomplexität ist der Feind von IT-Sicherheit. Was du verstehst, kann dir weniger leicht auf die Füße fallen.

Der Schlüsselaustausch lässt sich ebenfalls nicht weiter „vereinfachen“, ohne Sicherheit einzubüßen. Du kennst die Möglichkeiten, öffentliche Schlüssel per E-Mail-Versand, per Schlüsselserver oder per Webserver (WKD) zu verteilen. Du weißt, dass alle diese Möglichkeiten keine Garantie bieten, dass das der richtige Schlüssel ist, der bei der Empfänger*in angekommen ist. Höchstens WKD ist vielleicht ein bisschen sicherer, weil dann der Kreis an Personen, die den Schlüssel fälschen könnten, ein bisschen mehr eingeschränkt ist als bei den anderen beiden Möglichkeiten. Dir per E-Mail oder per Schlüsselserver einen falschen Schlüssel zukommen lassen – das kann wirklich jeder. Na gut. Im Falle des Schlüsselservers wirst du vielleicht stutzig, wenn da mehrere gültige Schlüssel liegen und du dich für einen entscheiden musst. Und du musst überhaupt erstmal auf dem Schlüsselserver nachgucken, damit dir auf diesem Wege jemand einen falschen Schlüssel unterschieben kann. Also ist das auch noch ein bisschen unwahrscheinlich. Aber wirklich jeder jeder kann dir eine E-Mail-Nachricht unter falscher Absenderangabe schicken, wo drin steht: „Hi. Ich hab nen neuen Schlüssel. Siehe Anhang. Ciao.“ (Am besten unsigniert oder mit dem neuen Schlüssel signiert, haha!) Wenn du das dann einfach so glaubst, obwohl der bisherige Schlüssel dieser Person noch gültig ist und nicht widerrufen wurde, dann ist dein Verfahren kaputt. Du darfst das nicht einfach so glauben. (Leute, die gelegentlich solche „Hier ist mein neuer Schlüssel.“-Nachrichten verschicken, sind oft Thunderbird-Benutzer*innen, denn Thunderbird bekommt von Zeit zu Zeit nen Rappel und löscht alle geheimen Schlüssel. Wenn die Leute dann kein Backup haben, dann war’s das.)

Witzigerweise gibt es eine OpenPGP-„Vereinfachung“, deren ganzes Konzept nur darin besteht, unsigniert per E-Mail verschickte öffentliche Schlüssel unhinterfragt zu übernehmen. Das Verfahren nennt sich Autocrypt und wer es einsetzt, ist eine Gefahr für die öffentliche Sicherheit. Wenn dein E-Mail-Client Autocrypt unterstützt und per Standardeinstellung aktiviert hat (das wäre sehr schlecht), dann schalte das unbedingt aus, damit dir Autocrypt nicht deine Schlüsselsammlung kaputt macht! Es besteht sonst die Gefahr, dass du in dem guten Glauben, einen echten Schlüssel von einer Person zu haben, dieser Person eine geheime Nachricht schickst, aber in Wirklichkeit hat dir Autocrypt diesen Schlüssel mit einem anderen vertauscht und deine Nachricht bleibt nicht geheim. Oder eine korrekt aussehende Signatur von dieser Person ist nicht wirklich von dieser Person. Das schafft unnötigerweise zusätzliche Komplexität, das ist sehr schwer zu verstehen und somit das Gegenteil von einer Vereinfachung.

Wenn du die Schlüsselverteilung per Autocrypt gut findest und benutzen willst, dann lies mal kurz hier weiter.

Die Grundidee von Autocrypt wird in weniger kaputter Weise auch von OpenPGP und GnuPG unterstützt: Beim Signieren kann eine Nachricht mit dem zusätzlichen Argument --include-key-block um den zum Signieren verwendeten öffentlichen OpenPGP-Schlüssel (inklusive Haupt- und aller Unterschlüssel) ergänzt werden. Die Signatur wird damit etwas größer, weil der ganze öffentliche Schlüssel mit in der Signatur drin steht. Die Empfänger*in kann dann den eventuell fehlenden Schlüssel aus der Signatur importieren, indem sie zusätzlich das Argument --auto-key-import angibt. Wenn so der öffentliche Schlüssel aus der Signatur importiert wird, dann erscheint nicht die Meldung, dass die Signatur mangels öffentlichen Schlüssels nicht verifiziert werden konnte, sondern dann erscheint die Meldung, dass die Signatur stimmte und dem Signaturschlüssel nicht vertraut wird.

Der Unterschied zu Autocrypt ist, dass in keinem Fall der eventuell vorher schon vorhandene andere Schlüssel für dieselbe E-Mail-Adresse gelöscht wird. Wenn du einen Fingerabdruck abgeglichen und den Schlüssel lokal signiert hast, dann kannst du also immer sicher sein, dass die Signatur authentisch ist, wenn GnuPG sagt, dass die Signatur mit einem vertrauenswürdigen Schlüssel erzeugt wurde. Der eventuelle Fake-Schlüssel, der mit --auto-key-import importiert wurde, liegt zusätzlich in deinem Schlüsselbund und wird im Gegensatz zum weiterhin vorhandenen echten Schlüssel nicht als vertrauenswürdig bezeichnet werden.

Leute sind schlecht darin, Fingerabdrücke wirklich zu überprüfen, und sie neigen dazu, allen öffentlichen Schlüsseln in ihrem Schlüsselbund einfach zu vertrauen, selbst wenn GnuPG sagt, dass der Schlüssel nicht vertrauenswürdig ist. Deshalb ist die Option --auto-key-import standardmäßig abgeschaltet, damit dir kein Malheur passiert, wenn du das ebenfalls so handhabst.

Unverschlüsselt ist nicht der Standard

Die meisten E-Mail-Clients sind im Auslieferungszustand so eingestellt, dass OpenPGP nicht benutzt wird. Die Erzählung, dass OpenPGP so „kompliziert“ wäre, beruht wahrscheinlich zum Teil darauf, dass E-Mail-Clients normalerweise unsichere Standardeinstellungen haben und man sich erst durch irgendwelche unklar beschrifteten Konfigurationsmenüs wühlen muss, um Verschlüsselung erstmal zu aktivieren. Die Annahme, die durch diese unsicheren Standardeinstellungen implizit propagiert wird, ist also: Unverschlüsselt ist der Standard.

Das bedeutet für dich: Mach verschlüsselt zum Standard. Leider musst du dich am Anfang der Einrichtung deiner Software durch diese Konfigurationsmenüs wühlen und Anleitungen lesen, wie das geht. Dein E-Mail-Client (oder sonstige Software, mit der du OpenPGP benutzt) sollte so eingestellt sein, dass ausgehende Nachrichten immer verschlüsselt werden. Es gibt keinen Grund, weshalb du jedes Mal beim Verschicken einer Nachricht erstmal noch einen Knopf drücken müssen solltest, um sie vor dem Abschicken zu verschlüsseln. Das muss einfach immer automatisch passieren. Sonst wirst du eines Tages vergessen, diesen Knopf extra zu drücken, und es wird eine Nachricht unverschlüsselt rausgeschickt werden, die du wirklich nicht gern unverschlüsselt rausgeschickt hättest.

Es wird den Fall geben, dass du eine Nachricht an eine Person schickst, von der du gar keinen gültigen öffentlichen Schlüssel hast. In dem Fall wird dich das Programm darauf hinweisen, dass die Nachricht nicht automatisch verschlüsselt werden kann, und es wird dir anbieten, die Nachricht mit einem anderen öffentlichen Schlüssel zu verschlüsseln oder unverschlüsselt abzuschicken (oder auf die Suche nach dem passenden öffentlichen Schlüssel zu gehen, oder die Nachricht zurückzustellen, oder deinen Tippfehler in der E-Mail-Adresse zu korrigieren, oder oder oder). Wenn du also viel mit Leuten kommunizierst, die überhaupt nicht OpenPGP benutzen, dann ist das bei denen jeweils ein zusätzlicher Klick auf: „Ja, unverschlüsselt abschicken.“ Besser so als andersrum.

Wenn du von jemandem eine verschlüsselte Nachricht bekommst (was du zum Beispiel daran erkennst, dass du zum Lesen der Nachricht erstmal dein Mantra eingeben musst – es sei denn, du benutzt Thunderbird – auch deshalb bitte nicht Thunderbird benutzen), dann ist das ein sehr deutliches Signal, dass diese Person anscheinend OpenPGP benutzt. Wenn du nun dieser Person antworten willst und du hast den Schlüssel von dieser Person nicht, mit dem du die Antwort verschlüsseln könntest – was tust du dann? Ich hoffe, Folgendes: Du gehst auf die Suche nach dem Schlüssel (WKD, Schlüsselserver, vielleicht war der Schlüssel sogar der Nachricht angehängt). Wenn die Suche erfolglos ist, dann fragst du die Person, wie du an ihren Schlüssel kommen könntest. Sobald du den Schlüssel hast, antwortest du auf die ursprüngliche Nachricht, falls es ein nicht soo brisanter Inhalt war. Wenn es ein brisanter Inhalt war, dann verifizierst du erst den Fingerabdruck und antwortest dann auf die ursprüngliche Nachricht. Ich hoffe, dass du niemals Folgendes tust: Du klickst auf „Antworten“, die ursprüngliche geheime Nachricht erscheint als Vollzitat in deinem Textfenster, du ergänzt die Nachricht oben mit dem Satz: „Sorry, hab deinen Schlüssel nicht.“ und schickst das Ganze unverschlüsselt ab. Das Problem ist hier offensichtlich: Du hast das Vertrauen der anderen Person in dich, dass du OpenPGP benutzt, missbraucht, indem du ihren extra an dich verschlüsselten Text postwendend unverschlüsselt über den Äther geblasen hast. Auf gar keinen Fall! Wenn du der Person unverschlüsselt schreiben musst, dann natürlich ohne Bezugnahme auf den verschlüsselten Text!

Wie gut gesichert sind eigentlich die Daten, die bei dir lokal auf dem Datenträger liegen? Also zum Beispiel deine Entwürfe und gesendeten Nachrichten? Speicherst du die unverschlüsselt bei dir ab? Das wäre blöd, denn dein Datenträger wird eines Tages kaputt gehen oder aus anderen Gründen ausrangiert werden oder gar bei der Bullerei oder anderen bösartigen Leuten landen. Dann liegen da deine einst geschriebenen Texte drauf und machen dir vielleicht Sorgen. Also es ist super sinnvoll, auch Entwürfe und gesendete Nachrichten bei dir nur verschlüsselt abzuspeichern. Wenn du die Texte immer mit deinem eigenen Schlüssel verschlüsselst, dann kannst du sie selber noch nach Mantra-Eingabe lesen, aber es passiert nicht viel Schlimmes, wenn du sie beispielsweise aufgrund von Fehlkonfiguration aus Versehen per IMAP hochlädst.

Kannst du den Volltext deiner gesendeten und/oder empfangenen Nachrichten mit deinem E-Mail-Client durchsuchen, auch wenn sie verschlüsselt sind? Das wäre sonderbar, denn dann sind sie wohl doch nicht verschlüsselt. Wenn du Daten, die nur verschlüsselt über das Internet gehen sollten, lokal unverschlüsselt abspeicherst, dann ist das ein potenzielles Problem, solange du den Datenträger noch physisch bei dir hast. Sobald du den Datenträger aus der Hand gibst, wird es ein ganz reales Problem. Um dem Problem beizukommen, bietet sich eine Datenträgerverschlüsselung sehr an. Das tut nicht weh und hilft dir, Kummer zu vermeiden. Bitte informier dich über Datenträgerverschlüsselung (das ist je nach Betriebssystem unterschiedlich und geht über das Thema dieser Anleitung weit hinaus) und verschlüssel einfach immer alles mit deinem Mantra. Dann ist es auch weniger problematisch, wenn du den Klartext einer empfangenen verschlüsselten Nachricht in einer Datei abspeicherst, die du von deinem Datenträger nie wieder sicher gelöscht kriegst: Es ist ja zum Glück noch die Datenträgerverschlüsselung darunter, die dich rettet.

Unsigniert ist nicht der Standard

Eine andere Sache, die man bei E-Mail-Clients extra anschalten muss, weil sie standardmäßig abgeschaltet ist, ist, dass ausgehende Nachrichten immer signiert werden sollen. Natürlich gibt es einzelne Fälle, in denen du eine Nachricht mal unsigniert verschicken willst. Das sind aber seltene bis seltenste Ausnahmen. Also kannst du dir den Umweg sparen, jedes Mal beim Verfassen einer Nachricht noch extra einzustellen, dass diese Nachricht auch signiert werden soll.

Wenn du weißt, dass eine bestimmte Person, der du schreibst, ganz bestimmt nicht OpenPGP benutzt, dann ist das kein Grund, deine Nachricht an diese Person nicht zu signieren. Denn schaden kann es ja nicht – der Klartext ist auch mit angehängter Signatur natürlich trotzdem lesbar. Und nur wenn du alle deine ausgehenden Nachrichten signierst, dann können auch alle deine Kommunikationspartner*innen wissen, dass du OpenPGP benutzt. Nur so kommen Leute überhaupt auf die Idee, sich mal deinen Schlüssel zu besorgen, um deine Signaturen auch prüfen und dir verschlüsselt schreiben zu können. OpenPGP zu benutzen, ist ja keine Schande. Du musst diese Information also nicht extra geheim halten. Wenn du deine Nachrichten konsequent signierst und Leute somit wissen können, welcher dein richtiger Schlüssel ist, dann wirst du sehen, dass es doch gar nicht so wenige gibt, mit denen du verschlüsselt kommunizieren kannst.

Schlüsseltausch braucht neues Vertrauen

Eine Sache, die ich zum Thema „Vereinfachungen“ oben schon mal angeschnitten habe, möchte ich nochmal explizit ansagen: Glaube nicht, dass es so sei wie es scheint, wenn du keinen Beweis hast! Digitale Kommunikation über Internet ist natürlich deutlich besser fälschbar als direkte persönliche Kommunikation, bei der die Person vor dir steht und du das Gesicht und die Stimme erkennst. Nur weil du eine Textnachricht mit einer glaubwürdigen Absenderangabe bekommen hast, deren Duktus der üblichen Schreibweise derjenigen Person entspricht, und nur weil diese Textnachricht gerade ganz gut in den Kontext eurer sonstigen Kommunikation passt, heißt das noch überhaupt nicht, dass die Nachricht tatsächlich so von dieser Person an dich geschickt wurde. Deshalb signiert man ja Nachrichten, damit man eine dem persönlichen Gespräch ebenbürtige Vertrauenswürdigkeit in der Internet-Kommunikation herstellen kann. Das ganze Geschäftsmodell Phishing basiert auf dem verbreiteten Irrglauben, dass schon alles okay wäre, wenn es okay aussieht.

Wenn dir jemand eine Nachricht schickt, die nicht mit einem dir bereits bekannten Schlüssel signiert ist, dann kannst du dem Inhalt dieser Nachricht nur dann glauben, wenn nichts davon abhängt, dass dein Glaube vielleicht später erschüttert wird. Ebenso, wie du auf eine per E-Mail reinkommende Aufforderung, deine persönlichen Daten irgendwo einzugeben, nicht eingehst (insbesondere dann nicht, wenn du die Signatur nicht überprüfen kannst), ebenso gehst du nicht auf eine per E-Mail reinkommende Aufforderung ein, einem neuen öffentlichen Schlüssel zu glauben, dass er echt sei.

Wenn jemand ein neues Schlüsselpaar für sich erzeugt hat und dir den neuen öffentlichen Schlüssel schickt, dann muss der neue Schlüssel mit dem alten Schlüssel signiert sein. (Das kannst du mit dem Argument --list-sigs überprüfen.) Oder die Nachricht, in der dir der neue Schlüssel zugeschickt wird, muss mit dem alten Schlüssel signiert sein. Oder du musst den Fingerabdruck des neuen Schlüssels neu mit der Person abgleichen, also beim Vertrauensaufbau wieder von vorne anfangen. Wenn du das nicht gründlich und streng handhabst, dann hast du nur opportunistische Sicherheit und dann ergibt das ganze Konzept Vertrauen in Schlüssel keinen Sinn.

Beachte ungesicherte Begleitinfos

Dass du im Laufe dieser Anleitung gelernt hast, wie du GnuPG „zu Fuß“ bedienst, also über die Kommandozeile statt über die Automatisierungen der Oberfläche deines E-Mail-Clients, hat den Vorteil, dass du jetzt ziemlich genau weißt, wie der Informationsfluss ist: Du schreibst eine Nachricht, die du mit GnuPG signierst und/oder verschlüsselst. Die Nachricht ist dann also in irgendeiner Weise mit OpenPGP abgesichert. Diese mit OpenPGP abgesicherte Nachricht verschickst du dann per E-Mail, wobei du angibst, wem du die Nachricht schickst und wie der Betreff lautet. So gesehen ist es offensichtlich, dass die ganzen Metainformationen zu deiner E-Mail-Nachricht natürlich nicht mit OpenPGP abgesichert sind:

Deine E-Mail-Adresse,
dein Name, der eventuell neben deiner E-Mail-Adresse steht,
die E-Mail-Adresse der Empfänger*in,
der Name der Empfänger*in,
wann du die Nachricht verschickt hast,
der Betreff und noch unzählige weitere Metainformationen wie
der E-Mail-Server, mit dem du dich verbindest,
welche Nachricht worauf die Antwort ist,
dein Betriebssystem,
dein E-Mail-Client,
deine IP-Adresse,
dein Internetprovider,
deine Sprache,
deine Zeitzone wenn nicht gar dein genauer Standort,
der Name deines Computers,
alles Mögliche.

Alle diese Informationen liegen ungesichert offen und lassen sich teilweise nur schlecht bis gar nicht geheim halten, wenn du Nachrichten per E-Mail verschickst. Die Lösung kann nur sein: Nachrichten nicht per E-Mail verschicken, sondern zum Beispiel nur per Tor-Onion-Service austauschen. Wenn du Nachrichten per E-Mail bekommst, können diese Begleitinformationen gefälscht sein, weil sie nicht mit OpenPGP signiert sind. Das OpenPGP-Format selbst gibt auch ein paar Informationen preis (also unabhängig vom Transportweg E-Mail):

Dass du GnuPG benutzt und in welcher Programmversion genau,
wann die Nachricht erzeugt wurde,
die ungefähre Länge der verschlüsselten Nachricht,
an welche Schlüssel die Nachricht verschlüsselt ist, …

Das ist eine nicht-abschließende Liste, weil ich unmöglich wissen kann, was sich alles für hilfreiche Informationen aus einer OpenPGP-Nachricht extrahieren lassen. Nur zu einem kleinen Teil kann man solche Informationen verschleiern. Die Länge der Nachricht kannst du verschleiern, indem du immer gleich lange Nachrichten verschickst (ggf. aufgefüllt mit Zeilenumbrüchen und Leerzeichen oder reinkopierten Blindtexten). Die Angabe der Schlüssel-IDs, die die Nachricht entschlüsseln können, kann GnuPG mittels --throw-keyids bei der Verschlüsselung weglassen.

Natürlich musst du mit OpenPGP abgesicherte Nachrichten nicht per E-Mail verschicken. Aber es ist der übliche Kommunikationsweg, also sei dir dessen bewusst. Auf anderen Kommunikationskanälen gibt es möglicherweise andere Metainformationen, die du preisgibst alleine dadurch, dass du darüber kommunizierst, unabhängig davon was du genau verschickst.

Ebenso wie bei E-Mail der Betreff ungesichert ist, bezieht sich die Signatur einer Datei nicht auf den Dateinamen. Ich denke, das ist offensichtlich. Wenn du also eine Datei nextcloud-aktuellste-supersichere-version.tar.gz runtergeladen und deren Signatur erfolgreich überprüft hast, dann weißt du nur, dass der Inhalt der Datei mit dem passenden geheimen Schlüssel signiert wurde. Du weißt aber nicht, was genau der Inhalt ist. Es könnte zum Beispiel eine hoffnungslos veraltete Software mit vielen schwerwiegenden lange bekannten Sicherheitsproblemen sein. Die Datei umzubenennen, macht die Signatur nicht ungültig. (Guck zur Sicherheit auch immer, wann die Signatur erzeugt wurde. Das Datum gibt dir GnuPG bei der Verifikation der Signatur mit aus, und das sollte nicht zu lange zurückliegen.) Gleiches gilt für verschlüsselte Dateien: Die sollten nicht anschlagsplanung.pdf.crypt heißen, es sei denn, es handelt sich nicht um eine Anschlagsplanung und du hast einfach Bock auf den Nervenkitzel.

Lass uns beim Medium E-Mail bleiben: Wenn du also die Nachricht „Hi. Wir treffen uns morgen 17 Uhr am alten Sägewerk zur Besprechung. Hdgdl – Schnuffelchen“ verschlüsselt verschicken willst, weil die sehr geheim ist, und du wählst den Betreff „Besprechung morgen 17:00 Sägewerk“, dann kannst du dir die Verschlüsselung auch sparen, denn die wesentliche Information lieferst du unverschlüsselt mit. Also wähle keinen oder einen weniger aussagekräftigen Betreff wie zum Beispiel „Nachricht“ oder „…“.

Das Gleiche trifft zu, wenn du die Nachricht gar nicht verschlüsselst (weil du sie über eine Mailingliste verschickst oder du gar keinen öffentlichen Schlüssel von der Empfänger*in hast), sondern nur signierst. Wenn in dem Fall dein Betreff wieder „Besprechung morgen 17:00 Sägewerk“ lautet und du in den (signierten) Nachrichtenkörper nur reinschreibst: „Jo, freue mich. Ciao!“, dann bringt dir deine tolle Signatur exakt gar nichts. Die wesentliche Information darf natürlich nicht nur über den Betreff zu bekommen sein, sondern muss im signierten Teil der Nachricht stehen. Im Gegenteil: Der Betreff einer signierten Nachricht muss als möglicherweise gefälscht angenommen werden. Wenn du eine signierte Nachricht bekommst, die nur im Betreff eine Beleidigung enthält, dann solltest du dich nicht beleidigt fühlen.

Manche E-Mail-Clients unterstützen den Spezialtrick, dass der Betreff nicht tatsächlich in die dafür vorgesehene Betreffzeile geschrieben wird, sondern an den Anfang der verschlüsselten und/oder signierten Nachricht. Auf diese Weise ist der Betreff dann doch mit OpenPGP abgesichert. Aber weil einige E-Mail-Clients das Feature nicht so ganz unterstützen, ist das gefährlich. Der verschlüsselte Betreff könnte dann in der Antwortnachricht doch wieder unverschlüsselt zurückgeschickt werden: Wenn du auf deine geheime Nachricht hin eine Antwort zurück bekommst mit dem unverschlüsselten Betreff „Re: Besprechung morgen 17:00 Sägewerk“, dann hast du auch nichts gewonnen. Also am besten verzichtest du zumindest bei verschlüsselten Nachrichten komplett auf einen Betreff. (Lokal bei dir im E-Mail-Speicher kannst du den Betreff von E-Mail-Nachrichten, die du bekommen oder verschickt hast, beliebig nachträglich ändern. Die OpenPGP-Signatur oder -Verschlüsselung geht dadurch ja nicht kaputt. Also mach das ruhig, um später in deinen E-Mail-Nachrichten besser suchen zu können, denn die Suchfunktion deines E-Mail-Clients kann ja nicht in verschlüsselte Nachrichten reingucken, sondern nur nach Betreffzeilen suchen. Wenn du nachträglich einen aussagekräftigeren Betreff einträgst, musst du nur tierisch aufpassen, dass du die neue Betreffzeile nicht zum Beispiel per IMAP auf deinen E-Mail-Server hochlädst, bei einer Antwort auf die Nachricht mit Re: davor rausschickst oder sonstwie weitergibst.)

Neben diesen absichtlich eingebauten Metainformationen, die ich oben aufgezählt habe (Betreff, IP-Adressen, E-Mail-Clients usw.), gibt es auch noch sog. Seitenkanäle. Das sind unabsichtlich auftretende Informationsflüsse, über die geheime Informationen in unbefugte Hände gelangen können. Beispiel: Eine mit OpenPGP verschlüsselte Nachricht kann nicht ohne Kenntnis des geheimen Schlüssels gelesen werden. Aber um diese verschlüsselte Nachricht zu erzeugen, muss eine Person erstmal die Klartextnachricht in einen Computer eingeben. Und eine andere Person nimmt mit einem anderen Computer die Entschlüsselung vor und erhält wieder den Klartext. Auch bei Ende-zu-Ende-verschlüsselten Nachrichten gibt es also mehrere Stellen, an denen die unverschlüsselte Klartextnachricht vorliegt und eventuell unbefugt abgegriffen werden könnte. Computer sind komplexe Systeme, deren Komplexität sich auf vielfältige Weise ausnutzen lässt. Besonders einfach und offensichtlich sind sog. Keylogger: kleine Geräte oder im noch einfacheren Fall Software, die Tastatureingaben mitschneidet. Das kann die ganze Klartextnachricht sein (bei der Autor*in der Nachricht) oder das Mantra, das zur Entschlüsselung benötigt wird (bei der Empfänger*in). Etwas spezieller, aber auf jeden Fall ohne großen finanziellen Aufwand umsetzbar: Computer brauchen unterschiedlich viel elektrische Energie, je nach dem, was sie genau tun. An der Stromzufuhr oder dem Flackern der Power-LED eines Computers kann man also ablesen, was der Computer gerade tut, welche Zahlen er verarbeitet. Aus diesen Messungen kann ein geheimer Schlüssel rausfallen oder eine geheime Nachricht. Je nach dem, was der Computer gerade tut, gibt er verschiedene elektromagnetische Strahlung oder verschiedenen Schall in unhörbaren Frequenzen ab. Das kann gemessen werden. Daraus können unangenehme Rückschlüsse gezogen werden. Tastaturen klackern unterschiedlich, je nach dem, welche Tasten gedrückt werden. Mit einem einfachen Mikrophon können so sensible Informationen abgelauscht werden, zum Beispiel mit dem im Computer selber eingebauten Mikrophon oder mit dem Mikrophon im neben der Tastatur liegenden Smartphone. Sogar von außerhalb des Raumes, wo kein Geräusch hinkommt, können Geräuschquellen indirekt abgehört werden, denn Schallwellen bringen Fensterscheiben zum Schwingen. Diese Schwingungen können mit billigen Lasern gemessen werden. Auch der schnelle Blick über die Schulter (vielleicht indirekt mit einer Kamera) kann Informationen preisgeben.

Solche Seitenkanäle lassen sich sicherlich nicht absolut hundertprozentig abschalten. Ich schreibe das alles nur, damit du dir eine gesunde (nicht-übertriebene) Paranoia aneignest; d. h. du solltest deine Vorsichtsmaßnahmen deiner realistisch eingeschätzten Gefährdungslage anpassen (und der Gefährdungslage deiner Gesprächspartner*innen). Einfachste Sicherheitsmaßnahmen, die selbstverständlich sein sollten: das Backup deines geheimen Schlüssels gehört nicht in die Cloud oder andere fremde Hände, denn das Einzige, was dich dann noch vor der Katastrophe schützt, ist dein Mantra. Das Mantra bekommt man relativ leicht raus. Damit auch das nicht passiert: Sei nicht so leichtsinnig, dein Mantra in der Öffentlichkeit einzugeben, wenn dir unbekannte Personen hinter dir stehen könnten. So machst du es sonst viel zu leicht, dich zu hacken. Wer es auf deinen geheimen Schlüssel abgesehen hat, muss sich schon etwas mehr Mühe geben und mindestens eine Kamera in deiner Wohnung oder an einem von dir oft aufgesuchten öffentlichen Ort installieren oder dir unauffälliger folgen. Schau, dass du deinem eigenen Gerät vertraust, auf dem du vertrauliche Kommunikation abwickelst. Verwende kein Gerät, das eventuell einen Keylogger haben könnte (weil du keine Kontrolle über die darauf laufende Software hast, wie oft bei Smartphones etc., oder weil es zum Beispiel mal bei der Bullerei war oder gewesen sein könnte oder du nicht weißt, wo es war).

Soweit die einfachen Vorsichtsmaßnahmen. Wenn du konkret den Verdacht hast, dass jemand hinter deinen Nachrichten oder deinem geheimen Schlüssel her ist, und du wirklich wirklich wirklich sicher gehen willst, dass keine Seitenkanäle ausgenutzt werden, dann kann ich dir mit dieser Anleitung auch nicht helfen. Dann musst du mal recherchieren, was alles möglich ist und wie du dich schützen kannst. Ich will nicht dafür verantwortlich sein, wenn sie dich kriegen.

Erste Ansätze für deine Recherchen könnten sein:

visuelles Keyboard (findet sich oft unter der Kategorie Barrierefreiheit bzw. accessability) statt Tastatureingaben
das Betriebssystem Tails auf einem USB-Stick
geheimen Hauptschlüssel sehr sicher wegspeichern und im täglichen Gebrauch nie dabei haben, sondern nur die geheimen Unterschlüssel
Schlüsseloperationen nur auf einem Gerät ausführen, das gar keinen Netzwerkzugriff hat (air-gapped) und verschlüsselte Daten auf USB-Sticks hin und her tauschen (keine Klartextdaten auf USB-Sticks schreiben)
dieses Gerät in einem speziellen abhörsicheren Raum betreiben
Unterschlüssel mit Ablaufdatum versehen und routinemäßig widerrufen und neu erzeugen, um eventuellen Kompromittierungen des Schlüssels entgegenzuwirken
geheime Schlüssel nur auf Hardware-Modulen (Smartcards, z. B. ein USB-Token wie ein einfacher Nitrokey für 20 €) herumtragen, wo sie unmöglich herausgeholt werden können, selbst bei bekanntem Mantra

OpenPGP in Gruppen

Hinreichend oft habe ich in den vorangegangenen Abschnitten gepredigt, dass du deinen geheimen Schlüssel geheimhalten musst. Es ist nicht nötig, noch einmal zu wiederholen, dass du dein Mantra niemals weitergeben darfst. Bestimmt hast du dich gefragt, ob das dann heißt, dass OpenPGP so ein Personen-Ding ist, wo Personen mit Personen-Adressen persönliche Dinge hin und her schreiben, oder ob man auch als Gruppe an einer OpenPGP-Kommunikation teilnehmen kann.

Kann man. Eine konspirative Gruppe kann mit anderen konspirativen Gruppen ihre nächsten krummen Dinger besprechen, ohne dass das über die persönlichen Schlüssel einzelner Gruppenmitglieder laufen muss. Eine Zeitung kann OpenPGP-verschlüsselte heiße Infos entgegennehmen, auch wenn mehrere Redakteur*innen auf diese Infos Zugriff haben sollen.

Wenn dich das interessiert, dann lies hier weiter.

Die einfachste und schlechteste Lösung lautet: Ein Gruppenmitglied erzeugt ein Schlüsselpaar

gpg --expert --full-gen-key

und gibt den geheimen Schlüssel inklusive Mantra an die anderen Gruppenmitglieder weiter.

gpg -ao gruppenschluessel.sec --export-secret-keys blumenkinder@raf.org

Die anderen Gruppenmitglieder importieren den geheimen Schlüssel bei sich.

gpg --import gruppenschluessel.sec

Wenn du den geheimen Schlüssel mit --export-secret-keys exportierst, dann wirst du nach dem Mantra gefragt. Man könnte meinen, dass demnach der geheime Schlüssel in der exportierten Datei dann unverschlüsselt abgelegt wäre. Das ist aber nicht so. Der exportierte geheime Schlüssel ist mit genau demselben Mantra verschlüsselt, mit dem du ihn im Schlüsselbund hast. Das Mantra wird dann beim Import und der Verwendung des geheimen Schlüssels auch abgefragt. Das musst du also auch an die anderen Gruppenmitglieder weitergeben (auf einem anderen, noch viel abhörsichereren Kanal als die Schlüsseldatei selbst).

Wer den geheimen Schlüssel importiert hat, wird feststellen, dass für dessen Verwendung als öffentlicher Schlüssel (Nachrichten verschlüsseln und Signaturen verifizieren) immer abgenickt werden muss, dass dieser Schlüssel benutzt werden soll, obwohl er „keine vertrauenswürdige Signatur“ habe und es nicht sicher sei, dass er der in der User-ID genannten Person gehört. Das liegt daran, dass das Vertrauen in den importierten Schlüssel unbestimmt ist.

Bei der Erzeugung eines Schlüssels wird das Vertrauen in diesen Schlüssel auf „ultimativ“ gesetzt. Beim Import eines Schlüssels, den jemand anderes erzeugt hat, lässt GnuPG diesen Schritt weg. Mit Vertrauen ist dabei das Vertrauen gemeint, dass Beglaubigungen von diesem Schlüssel an anderen Schlüsseln wohlüberlegt sein werden; dass also die Schlüssel, die von diesem Schlüssel signiert wurden, die korrekte User-ID haben werden. Wenn du einen Schlüssel selbst erzeugst: Klar. Du selbst bist ja maximal vertrauenswürdig. So vertrauenswürdig, wie es eben geht. Du kannst dich natürlich immer selbst bescheißen und Schlüssel mit falscher oder ungeprüfter User-ID signieren. Aber bei dem Problem würde dir OpenPGP auch nicht helfen. Deshalb sind selbsterzeugte Schlüssel immer „ultimativ“ vertrauenswürdig. Du selbst bist quasi der Vertrauensanker.

Ein anderer Schlüssel, den du nicht selbst erzeugt hast, könnte dadurch valide (ohne Warnungen und Rückfragen benutzbar) werden, dass du ihn mit deinem Schlüssel (der ja vertrauenswürdig ist) signierst. Dein eigener selbsterzeugter Schlüssel wird dadurch valide, dass er ja selbstsigniert ist, also hat er eine Signatur von einem vertrauenswürdigen Schlüssel.

Woher soll GnuPG bei einem importierten geheimen Schlüssel wissen, wer den noch so alles hat und wie wohlüberlegt dessen Signaturen an anderen öffentlichen Schlüsseln sein werden! Deshalb ist das Vertrauen importierter Schlüssel nicht „ultimativ“, sondern unbestimmt. Und deshalb trägt der selbstsignierte Schlüssel eben nicht automatisch eine vertrauenswürdige Signatur und ist deshalb nicht valide. Um Signaturen dieses Schlüssels uneingeschränkt zu glauben und um nicht immer bestätigen zu müssen, dass dieser Schlüssel wirklich verwendet werden soll, könnten die anderen Gruppenmitglieder nach dem Import noch im --edit-key-Menü das Vertrauen auf „ultimativ“ setzen:

gpg --edit-key blumenkinder@raf.org
…

Secret key is available.

…

gpg> trust
…

Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)

…
  5 = I trust ultimately
  m = back to the main menu

Your decision? 5
Do you really want to set this key to ultimate trust? (y/N) y

…

gpg> save

Da die einzelnen Gruppenmitglieder aber nicht wissen können, wie freigiebig die jeweils anderen Gruppenmitglieder mit Schlüsselsignaturen sind, ist „Vertrauen ultimativ“ eigentlich eine falsche Aussage. Korrekter wäre es, die Gruppenmitglieder würden stattdessen jeweils den Gruppenschlüssel lokal mit ihrem eigenen Schlüssel signieren; mit demselben Effekt, dass der Gruppenschlüssel dann eine vertrauenswürdige Signatur hat:

gpg -u schnuffelchen --lsign-key blumenkinder@raf.org
…
     trust: unknown       validity: unknown
…
     Gruppe <blumenkinder@raf.org>
…
Are you sure that you want to sign this key with your
key "Schnuffelchen <schnuffelchen@pkx.be>" (8D631EC35A0B6427)

The signature will be marked as non-exportable.

Really sign? (y/N) y

Die Kommunikation läuft zum Beispiel über eine gemeinsam genutzte E-Mail-Adresse. Der bis hierhin beschriebene Ansatz (jemand erzeugt nen Schlüssel und verteilt den in der Gruppe) lässt sich mit dem Wort Aargh! gut beschreiben, denn Probleme tun sich hier auf: Jede Person, die im Besitz des geheimen Schlüssels ist, kann alles mit diesem Schlüssel tun, ihn verlängern, ihn widerrufen, User-IDs hinzufügen und widerrufen, ihn leaken, alles. Und zwar zeitlich unbegrenzt. Wenn eine Person aus der Gruppe austritt, oder rausgeschmissen wird gar, aus schwerwiegenden Gründen gar, dann gibt es leider keine Möglichkeit, dieser Person den geheimen Schlüssel zu entziehen. In dem Fall müsste die Gruppe ein neues Schlüsselpaar erzeugen, das alte widerrufen und das Vertrauensnetz neu aufbauen. Das ist also nur etwas für sehr vertrauensvolle und langfristig stabile Gruppen. (Oder für solche, mit denen eh niemand kommunizieren will. Dann stellt jährlich ein neuer Schlüssel auch kein signifikantes Problem dar.)

Aber es geht besser.

Eine Möglichkeit ist, dass ihr in eurer Gruppe einen Hausmeister wählt. Die Rolle nenne ich so, weil der Hausmeister die Schlüssel verwaltet. Der Hausmeister erzeugt einen Gruppenschlüssel, und zwar nach der oben unter Schlüssel erzeugen vorgeschlagenen Weise, dass der Hauptschlüssel nur zertifizieren kann (C) und dazu zwei Unterschlüssel zum Verschlüsseln und Signieren (E und S) gehören. Die anderen Gruppenmitglieder bekommen vom Hausmeister den geheimen Schlüssel – aber nicht den ganzen, sondern nur den geheimen E- und S-Unterschlüssel. Den geheimen C-Hauptschlüssel bekommen die anderen Gruppenmitglieder nicht; den behält nur der Hausmeister.

gpg -ao gruppenunterschluessel.sec --export-secret-subkeys blumenkinder@raf.org

Die Folge davon ist, dass alle Gruppenmitglieder an die Gruppe adressierte Nachrichten lesen können und ausgehende Nachrichten im Namen der Gruppe signieren können. Aber sie können den Gruppenschlüssel nicht verändern. Sie können ihn zum Beispiel nicht verlängern oder widerrufen. Denn um das zu tun, ist immer der zertifizierungsfähige Hauptschlüssel erforderlich, den nur der Hausmeister hat. Also wenn diese Dinge nötig sind, dann kann das immer nur der Hausmeister tun.

Wenn jetzt ein Gruppenmitglied austritt (nicht der Hausmeister, ein anderes Mitglied) und nicht mehr im Namen der Gruppe agieren können soll, dann widerruft der Hausmeister die beiden Unterschlüssel und erzeugt zwei neue Unterschlüssel. Die verbleibenden Gruppenmitglieder bekommen wieder die neuen geheimen Unterschlüssel ausgehändigt und die neuen öffentlichen Schlüssel werden in der ganzen Welt verteilt.

gpg --edit-key blumenkinder@raf.org
…

sec  rsa4096/…
     …                                         usage: C   
     trust: ultimate      validity: ultimate
ssb  rsa4096/…                
     …                    expires: never       usage: S   
ssb  rsa4096/…               
     …                    expires: never       usage: E
[ultimate] (1). Blumenkinder <blumenkinder@raf.org>

gpg> key *

sec  rsa4096/…
     …                                         usage: C   
     trust: ultimate      validity: ultimate
ssb* rsa4096/…                
     …                    expires: never       usage: S   
ssb* rsa4096/…               
     …                    expires: never       usage: E
[ultimate] (1). Blumenkinder <blumenkinder@raf.org>

gpg> revkey
Do you really want to revoke the selected subkeys? (y/N) y
Please select the reason for the revocation:
  0 = No reason specified
  1 = Key has been compromised
  2 = Key is superseded
  3 = Key is no longer used
  Q = Cancel
Your decision? 2
Enter an optional description; end it with an empty line:
> Austritt
> ↵
Reason for revocation: Key is superseded
Austritt
Is this okay? (y/N) y

sec  rsa4096/…
     …                                         usage: C   
     trust: ultimate      validity: ultimate
The following key was revoked …
ssb  rsa4096/…                
     …                    revoked: …           usage: S   
The following key was revoked …
ssb  rsa4096/…               
     …                    revoked: …           usage: E
[ultimate] (1). Blumenkinder <blumenkinder@raf.org>

gpg> addkey
…
Your selection? 4
…
What keysize do you want? (3072) 4096
…
Key is valid for? (0) ↵
Key does not expire at all
Is this correct? (y/N) y
Really create? (y/N) y
…
gpg> addkey
…
Your selection? 6
…
What keysize do you want? (3072) 4096
…
Key is valid for? (0) ↵
Key does not expire at all
Is this correct? (y/N) y
Really create? (y/N) y
…

sec  rsa4096/…
     …                                         usage: C   
     trust: ultimate      validity: ultimate
The following key was revoked …
ssb  rsa4096/…                
     …                    revoked: …           usage: S   
The following key was revoked …
ssb  rsa4096/…               
     …                    revoked: …           usage: E
ssb  rsa4096/…
                          expires: never       usage: S   
ssb  rsa4096/…
                          expires: never       usage: E
[ultimate] (1). Blumenkinder <blumenkinder@raf.org>

gpg> save

gpg -ao gruppenunterschluessel-neueversion.sec --export-secret-subkeys blumenkinder@raf.org
gpg -ao gruppenschluessel-neueversion.pub --export blumenkinder@raf.org

Der GnuPG-Befehl key * führt dazu, dass beide Unterschlüssel in der Ausgabe mit einem Stern markiert sind. Auf diese beiden markierten Unterschlüssel bezieht sich dann der darauffolgende Befehl revkey. Deshalb fragt GnuPG dann auch nach dem Widerruf der ausgewählten Unterschlüssel. Es ist wichtig, dass du hier ganz genau guckst, was du tust, damit du nicht aus Versehen den Hauptschlüssel widerrufst. Das könnte sehr ungünstig sein, je nach dem, wann es dir auffällt. Also key * wählt alle Unterschlüssel aus, key 1 usw. ändert die Markierung des ersten usw. Unterschlüssels. Wenn du nichts dergleichen eingibst oder einfach nur den Befehl key ohne ein Argument dahinter, dann wird kein einziger Unterschlüssel ausgewählt. In diesem Fall bezieht sich der Befehl revkey danach auf den Hauptschlüssel und nicht die Unterschlüssel. Gleiches gilt zum Beispiel für den Befehl expire.

Das ausgetretene Ex-Gruppenmitglied kann jetzt nur noch die alten verschlüsselten Nachrichten lesen, die es zur Zeit seiner Mitgliedschaft auch schon lesen konnte, aber nicht die neuen. Und es kann Signaturen mit dem alten Signaturschlüssel erzeugen, die spätestens ab dem bisherigen Ablaufdatum niemand mehr als gültig akzeptieren wird.

Der Vorteil von diesem Verfahren gegenüber dem einfacheren schlechteren von vorher ist erstens, dass die Gruppe nur eine einzige sehr vertrauenswürdige Person braucht, die mit dem Schlüssel nicht Amok laufen wird, und nicht alle Gruppenmitglieder so vertrauenswürdig sein müssen, und zweitens, dass bei einem Austritt eines Mitglieds nur die Unterschlüssel neu generiert werden müssen, nicht der Hauptschlüssel, was zur Folge hat, dass die Signaturen an den User-IDs erhalten bleiben, also das Vertrauensnetz nicht neu aufgebaut werden muss: Der allen Leuten seit Jahren bekannte Fingerabdruck bleibt derselbe, denn das ist der Fingerabdruck des Hauptschlüssels. Nur wenn der Hausmeister austritt, muss der Hauptschlüssel widerrufen und ein neuer generiert werden.

Damit das gut funktioniert, ist natürlich auch hier wieder ein nicht allzu großzügig gewählter Gültigkeitszeitraum essenziell. Wenn eure Gruppe einen Hauptschlüssel hat, der fünf Jahre gültig ist, und zwei Unterschlüssel, die niemals ablaufen, dann könnt ihr zwar bei einem Austritt wunderbar eure beiden Unterschlüssel widerrufen und zwei neue generieren, aber die Leute aus der befreundeten anderen Gruppe, die mit euch kommunizieren wollen, werden das ja erstmal nicht unbedingt mitkriegen oder einfach vergessen, euer neues Zertifikat mit dem Widerruf und den neuen Schlüsseln bei sich zu importieren. Dann werden sie aus Versehen noch den alten Schlüssel verwenden. Das heißt, sie werden euch verschlüsselte Nachrichten schicken, die euer ausgetretenes Ex-Mitglied ebenfalls lesen kann, und euer Ex-Mitglied kann denen signierte Nachrichten im Namen eurer Gruppe schicken, die sie für bare Münze nehmen werden, weil ihnen die Signatur gültig erscheint.

Wenn ihr als Gültigkeitszeitraum für den Hauptschlüssel nicht fünf, sondern nur ein Jahr gewählt habt, dann passiert zwar genau dasselbe, aber die alten Unterschlüssel werden spätestens mit Ablauf dieses einen Jahres definitiv für alle unbenutzbar. Also erst nach Ablauf des alten Gültigkeitszeitraums ist auf jeden Fall wieder ein sicherer Zustand erreicht.

Wenn das eine Jahr (oder welchen Gültigkeitszeitraum auch immer ihr gewählt habt) verstreicht, ohne dass jemand aus der Gruppe ausgetreten ist, dann müssen keine Unterschlüssel ersetzt werden. Dann verlängert der Hausmeister einfach den Gültigkeitszeitraum des Hauptschlüssels zum Beispiel um ein weiteres Jahr und veröffentlicht das neue Zertifikat, also den verlängerten öffentlichen Schlüssel.

gpg --edit-key blumenkinder@raf.org
…
gpg> expire
Changing expiration time for the primary key.
…
Key is valid for? (0) 1y
Key expires at …
Is this correct? (y/N) y
…
gpg> save

gpg -ao gruppenschluessel-neueversion.pub --export blumenkinder@raf.org

Sowohl die anderen Gruppenmitglieder (die im Besitz der geheimen Unterschlüssel sind) als auch alle anderen Leute auf der Welt (die nur die öffentlichen Schlüssel haben) importieren dieses Verlängerungszertifikat (zum Beispiel vom Schlüsselserver, oder es wird per E-Mail rumgeschickt) und sind damit auf dem aktuellen Stand: Der Hauptschlüssel und mit ihm die zwei Unterschlüssel sind ein weiteres Jahr gültig. Sämtliches Vertrauen bleibt erhalten, keine Fingerabdrücke müssen neu abgeglichen werden, keine geheimen Schlüssel müssen in der Gruppe verteilt werden, denn es hat sich nur das Ablaufdatum geändert.

Ach ja, ein Hinweis, der wahrscheinlich eh klar ist: Der Hausmeister muss natürlich für seinen geheimen Hauptschlüssel ein Mantra verwenden, das die anderen Gruppenmitglieder nicht kennen, also der Hausmeister ändert vor oder nach dem Export der geheimen Unterschlüssel das Mantra:

gpg --edit-key blumenkinder@raf.org
gpg> passwd
gpg> save

Die Datei mit den exportierten geheimen Unterschlüsseln gruppenunterschluessel.sec ist also mit einem anderen Mantra gesichert als der geheime Hauptschlüssel im Schlüsselbund des Hausmeisters.

Der Schwachpunkt ist sicherlich vor allem, dass jetzt viele Leute irgendwie die geheimen Unterschlüssel und das dazugehörige Mantra bekommen müssen. Kommunikation kann abgelauscht werden. Zettel können irgendwo liegen bleiben, abfotografiert oder aus dem Müll gefischt werden, andere Leute aus der Gruppe haben vielleicht nicht dasselbe Sicherheitsbewusstsein wie du. Du könntest den Prozess ein bisschen sicherer gestalten, indem du nicht nur ein einziges Gruppenmantra erzeugst, sondern für jede Person ein eigenes. Dann ist es für unbefugte Personen schwieriger, einen geheimen Schlüssel und das richtige dazu passende Mantra abzugreifen.

Vielleicht hast du dir schon gedacht: Wenn du einen Unterschlüssel widerrufst, dann wird die Repräsentation deines öffentlichen Schlüssels als exportierte Datei dadurch nicht kürzer, sondern länger: Alle bisherigen Informationen sind weiterhin drin, und es kommt noch die Information dazu, dass der eine Unterschlüssel nicht mehr verwendet werden soll. Wenn du einen neuen Unterschlüssel erzeugst, dann wird die exportierte Datei mit deinem öffentlichen Schlüssel wiederum länger, und zwar um die Größe des neuen Unterschlüssels. Egal, was du machst: Dein öffentlicher Schlüssel, den du in der Welt verteilen willst, wird nur immer länger und länger. In der Schlüsselübersicht mit gpg -k steht dann auch immer mehr Text, je mehr widerrufene Unterschlüssel du hast. Das wird irgendwann richtig unhandlich.

Deshalb habe ich vorhin, als es um das Ablaufdatum von Unterschlüsseln ging, nur zähneknirschend gesagt, dass du für Unterschlüssel kein Ablaufdatum setzen musst. Es ist zwar richtig, dass ein unendlich lange gültiger Unterschlüssel ohne aktuell noch gültigen Hauptschlüssel auch nicht verwendbar ist. Wenn du aber den Hauptschlüssel über viele Jahre hinweg immer weiter verlängern willst und in der Zwischenzeit haufenweise neue Unterschlüssel erzeugst, dann bindest du dich eben über die gesamte Lebensdauer des Hauptschlüssels an die Existenz jedes einzelnen Unterschlüssels. Wenn du einen dieser Unterschlüssel nicht mehr verwenden willst, dann musst du entweder ein Widerrufszertifikat für diesen Unterschlüssel immer mit veröffentlichen, oder der Unterschlüssel ist eh schon abgelaufen. Dafür ist es hilfreich, bei der Erzeugung des Unterschlüssels ein Ablaufdatum zu setzen. Wenn du den Unterschlüssel nicht mehr verwenden willst, dann widerrufst du ihn und musst ihn mit dem Widerrufszertifikat nur so lange veröffentlichen, wie der Unterschlüssel mal gültig war. Wenn der Gültigkeitszeitraum eh abgelaufen ist, dann kannst du den Unterschlüssel einfach löschen und so deinen öffentlichen Schlüssel kürzen. Das bietet sich vor allem für Unterschlüssel zum Verschlüsseln (E) an. Wenn du alte Unterschlüssel zum Signieren (S) löschst, dann können andere Leute deine alten Signaturen nicht mehr verifizieren. Das ist vielleicht ungünstig.

OpenPGP ist an sich ja ein hierarchiefreies System. Möglicherweise ist euch die Idee mit dem Hausmeister zu hierarchisch und ihr wollt gar nicht eine super-vertrauenswürdige Person bestimmen, die die zentrale Schlüsselgewalt hat. Dann könntet ihr mit ein bisschen mehr Aufwand auch die Hausmeisterrolle auf mehrere Personen aufteilen. Dazu legt ihr euch zum Beispiel einen Gruppenlaptop zu (irgendein gammliges Teil, das kostenlos irgendwo abfällt), auf dem ihr euren geheimen Hauptschlüssel gemeinsam erzeugt und verwaltet. Als Mantra wählt ihr dabei eine zusammengesetzte Zeichenkette, wobei jede beteiligte Person (in der richtigen Reihenfolge) ihr eigenes Mantra beisteuert. Immer wenn das Mantra abgefragt wird, müssen alle Hausmeister anwesend sein und ihr jeweiliges Mantra eingeben, damit der Schlüssel gemeinsam entsperrt wird.

Auf dem Gruppenrechner verwaltet ihr also euren geheimen Hauptschlüssel und von dort aus exportiert ihr euch eure geheimen Unterschlüssel ohne Hauptschlüssel, die ihr jeweils alleine mit euren eigenen Mantren entsperren könnt.

Ich höre jetzt langsam auf mit den Ideen. Ich denke, dir fallen leicht noch viele weitere Verfeinerungen des Ablaufs ein, die sämtliche Paranoialevel abdecken. Bei deinen Experimenten wirst du wahrscheinlich oft das GnuPG-Kommandozeilenargument --homedir sehr praktisch finden. Wenn du nur vorübergehend an deinem Schlüsselbund etwas verändern willst (zum Beispiel dein Mantra für den darauffolgenden Export der geheimen Unterschlüssel) und schon weißt, dass du später den vorherigen Zustand wiederherstellen willst, dann kannst du dein komplettes Verzeichnis .gnupg, in dem dein Schlüsselbund gespeichert ist, kopieren; zum Beispiel unter dem neuen Namen gnupg-test. Mit der Kommandozeile

gpg --homedir gnupg-test …

kannst du dann in dem Test-Schlüsselbund Veränderungen vornehmen, die sich auf deinen eigentlichen Schlüsselbund gar nicht auswirken.

Hier steht mehr dazu.

Wenn du einen Rechner einer anderen Person simulieren willst, auf dem deine geheimen Schlüssel nicht vorhanden sind (zum Beispiel um den Import der geheimen Unterschlüssel ohne Hauptschlüssel zu testen), dann kannst du ein neues leeres Verzeichnis anlegen und GnuPG mittels --homedir sagen, dass es das benutzen soll.

Als Ablageort für diese temporären GnuPG-Verzeichnisse eignet sich am besten eine sog. RAM-Disk, also ein Ort in deinem Verzeichnisbaum, dessen Inhalt nicht auf einen Permanentspeicher geschrieben wird, sondern im Arbeitsspeicher bleibt. Spätestens wenn du den Computer ausschaltest, ist der Inhalt der RAM-Disk definitiv nicht wiederherstellbar. Das ist zum Beispiel dann wichtig, wenn du erst das Mantra deines geheimen Schlüssels änderst und dann die geheimen Unterschlüssel ohne Hauptschlüssel exportierst (um die dann zusammen mit dem neuen Mantra in der Gruppe weiterzugeben). In dem Fall hast du nämlich in dem Zwischenschritt auch den geheimen Hauptschlüssel mit dem schwächeren Mantra abgespeichert, das du den anderen Gruppenmitgliedern nennen wirst. Da die anderen Gruppenmitglieder aber den geheimen Hauptschlüssel nicht bekommen dürfen, ist es besser, wenn du die Datei nur in der RAM-Disk und nicht permanent gespeichert hast. Oft ist das Verzeichnis /tmp/ eine RAM-Disk. Du kannst auch mal auf der Kommandozeile mount eingeben (wenn du nicht Windows benutzt) und in der Ausgabe nach dem Wort tmpfs oder /dev/md… suchen.

Ohne RAM-Disk geht es aber auch:

mit deinem eigenen, sichereren Mantra die geheimen Unterschlüssel in eine Datei exportieren: gpg -o unterschluessel-meinmantra.sec --export-secret-subkeys blumenkinder@raf.org
ein neues leeres Verzeichnis anlegen, in dem du GnuPG arbeiten lassen willst: mkdir gnupg-gruppenschluessel-test auf der Kommandozeile, oder wie auch immer du ein Verzeichnis anzulegen gewohnt bist
in dem neuen bisher leeren Verzeichnis die eben exportierten geheimen Unterschlüssel importieren: gpg --homedir gnupg-gruppenschluessel-test --import unterschluessel-meinmantra.sec
das Mantra von der importierten Version (ohne Hauptschlüssel) verändern: gpg --homedir gnupg-gruppenschluessel-test --edit-key blumenkinder ↵ … passwd ↵ … save ↵
mit dem weiterzugebenden Mantra die geheimen Unterschlüssel in eine Datei exportieren: gpg --homedir gnupg-gruppenschluessel-test -o unterschluessel-gruppenmantra.sec --export-secret-subkeys blumenkinder
die Datei unterschluessel-gruppenmantra.sec weitergeben
auf einem anderen Kommunikationskanal (Zettel verteilen oder so) das Gruppenmantra weitergeben
die Datei unterschluessel-meinmantra.sec und das Verzeichnis gnupg-gruppenschluessel-test kann gelöscht werden

Wenn ihr eine konspirative Gruppe seid, die intern möglichst unüberwachbar kommunizieren möchte, dann könnt ihr mal darüber nachdenken, ob ihr nicht OpenPGP-Nachrichten per E-Mail austauscht, sondern an nur einem Ort die Nachrichten für alle Mitglieder gespeichert sind. Auf die Weise fallen nämlich einige Metadaten weg, die die Anzahl der Gruppenmitglieder angeben, wer wann eine Nachricht verschickt und wer wann Nachrichten abruft. Wenn E-Mail euer Medium ist, dann sollte ein einziges Gruppenpostfach ausreichen, auf das alle Mitglieder Zugriff haben und in dem alle Mitglieder ihre Nachrichten mit ihrem jeweils eigenen Schlüssel signiert und mit dem gemeinsamen Gruppenschlüssel verschlüsselt ablegen. Ein Wiki, ein Dateispeicher oder ähnliches tut es statt E-Mail aber auch. Wenn alle Gruppenmitglieder die Nachrichten per Tor-Onion-Service abrufen und abschicken, dann seid ihr schon ziemlich sicher vor jeglicher Ausspähung.

In größeren, geographisch verteilt agierenden Organisationen stellt sich vielleicht die Frage, wie die vielen Mitglieder und Organisationseinheiten den Überblick über die korrekten aktuell gültigen Schlüssel behalten, ohne sich persönlich zum Fingerabdruck-Abgleich zu treffen. Auch dafür gibt es schöne Lösungen.

Wenn dich das interessiert, dann lies hier weiter.

Wenn es dir zu unterkomplex ist, dass auf einer über TLS abgesicherten Website die Organisation eine signierte Datei mit allen Schlüsseln veröffentlicht, die du dann nur noch gegen den Haupt-Organisationsschlüssel verifizieren und mit gpg --import importieren musst, dann kannst du das Thema auch etwas erschöpfender angehen.

OpenPGP erlaubt es, ein richtiges Vertrauensnetz aufzubauen – das web of trust. In den allermeisten Fällen brauchst du das nicht, aber manchmal ist es doch ganz hilfreich.

Schlüssel haben ein Vertrauen und eine Gültigkeit. Das Vertrauen gibt an, wie sehr du glaubst, dass die Signaturen von diesem Schlüssel an den User-IDs anderer Schlüssel für die Korrektheit der signierten User-IDs sprechen. Also ist das eigentlich kein Vertrauen in den Schlüssel, sondern Vertrauen in die Person, die im Besitz des dazu passenden geheimen Schlüssels ist, dass sie User-IDs gut prüft, bevor sie sie signiert.

Gültig ist ein Schlüssel, wenn er mindestens eine vertrauenswürdige Signatur hat. Gültige Schlüssel werden von GnuPG ohne Rückfrage akzeptiert. Bei ungültigen Schlüsseln musst du erstmal eine Warnung übergehen, dass der Schlüssel nicht von einem vertrauenswürdigen Schlüssel signiert wurde.

Du kannst definieren, welche Schlüssel der Vertrauensanker sind, und du kannst die Gültigkeit von Schlüsseln sich von dort aus ausbreiten lassen, entlang der Schlüsselsignaturen. Damit ein Schlüssel, der dir nicht selbst gehört, gültig wird, kannst du ihn einfach signieren. Wenn du willst, dass ein Schlüssel, der dir nicht selbst gehört, die Fähigkeit bekommt, andere Schlüssel durch Signieren gültig zu machen, dann kannst du diesem Schlüssel Vertrauen zuweisen (mit gpg --edit-key und trust).

Daraus ergibt sich noch eine andere Möglichkeit, wie ein Schlüssel gültig werden kann: Durch indirekte Vertrauenszuweisung: Wenn A B vertraut, dass B anderen das Vertrauen aussprechen kann, und B C vertraut, dann kann C die User-ID von D signieren und damit dafür sorgen, dass der Schlüssel von D für A als gültig erkannt wird – obwohl sich A und D noch nie persönlich getroffen haben.

Wenn du eine Hierarchie in der Organisationsstruktur hast, dann lässt sich die wunderbar in dieser indirekten Vertrauenszuweisung abbilden: Die geheime Weltregierung vertraut der Bundesorganisation auf Tiefe 2. Die Bundesorganisation vertraut der Ortsgruppe auf Tiefe 1. Die Ortsgruppe signiert die Schlüssel ihrer Mitglieder. Die einzelnen Mitglieder müssen jetzt nur noch den Schlüssel der geheimen Weltregierung als vertrauenswürdig markieren. Alle Schlüssel der Organisationsmitglieder aus irgendeiner Ortsgruppe in irgendeinem Land werden damit dann automatisch als gültig erkannt.

Beispiel: Wir erzeugen ein paar Schlüsselpaare für eine geheime Weltregierung, eine Bundesorganisation, zwei Ortsgruppen und zwei Mitglieder:

mkdir weltregierung bundesorga schnarchenreuth kleinkuhkackerode franz gerda
gpg --homedir weltregierung --expert --full-gen-key
gpg --homedir bundesorga --expert --full-gen-key
gpg --homedir schnarchenreuth --expert --full-gen-key
gpg --homedir kleinkuhkackerode --expert --full-gen-key
gpg --homedir franz --expert --full-gen-key
gpg --homedir gerda --expert --full-gen-key

Alle schicken ihren eigenen öffentlichen Schlüssel im Textformat (mit -a) an die geheime Weltregierung. Die geheime Weltregierung fügt alle öffentlichen Schlüssel zusammen in eine einzelne Datei, die dann alle bei sich importieren können. So haben erstmal alle alle Schlüssel:

gpg --homedir weltregierung -ao weltregierung.txt --export
gpg --homedir bundesorga -ao bundesorga.txt --export
gpg --homedir schnarchenreuth -ao schnarchenreuth.txt --export
gpg --homedir kleinkuhkackerode -ao kleinkuhkackerode.txt --export
gpg --homedir franz -ao franz.txt --export
gpg --homedir gerda -ao gerda.txt --export
cat *.txt > alle.txt
gpg --homedir weltregierung --import alle.txt
gpg --homedir bundesorga --import alle.txt
gpg --homedir schnarchenreuth --import alle.txt
gpg --homedir kleinkuhkackerode --import alle.txt
gpg --homedir franz --import alle.txt
gpg --homedir gerda --import alle.txt

Der einzige gültige Schlüssel ist jeweils der eigene mit ultimativem Vertrauen:

gpg --homedir gerda -k
/home/schnuffelchen/beispiel/gerda/pubring.kbx
-------------------------------------------
pub   rsa3072 2342-08-29 [C] [expires: 2342-09-12]
      7D28C6F3576A2B2B266E9C9FDF8EFF40C7FF747A
uid           [ultimate] Gerda <gerda@aufstand.net>

pub   rsa3072 2342-08-29 [C] [expires: 2342-09-12]
      090FE842136E6E27EF401696628EC85C849EEDD6
uid           [ unknown] Bundesorga <bundesorga@de.raf.org>

pub   rsa3072 2342-08-29 [C] [expires: 2342-09-12]
      83DE14C87C6934337EB9632A0B0A582D53A8ED40
uid           [ unknown] Franz <franz@aufstand.net>

pub   rsa3072 2342-08-29 [C] [expires: 2342-09-12]
      E9CC7DBF7EE3CE0E7E06C8A59B06BB3E45C0ED87
uid           [ unknown] OG Kleinkuhkackerode <og-kleinkuhkackerode@de.raf.org>

pub   rsa3072 2342-08-29 [C] [expires: 2342-09-12]
      3AC1DF3D1933A4ECA57EE3A83D572635FE154D6F
uid           [ unknown] OG Schnarchenreuth <og-schnarchenreuth@de.raf.org>

pub   rsa3072 2342-08-29 [C] [expires: 2342-09-12]
      946327744C12AC7915C6C4D10A9B8934EA26FD48
uid           [ unknown] Weltregierung <weltregierung@raf.org>

Die Ortsgruppe Schnarchenreuth signiert die User-ID am Schlüssel ihres Mitglieds Franz und die Ortsgruppe Kleinkuhkackerode signiert die User-ID am Schlüssel ihres Mitglieds Gerda:

gpg --homedir schnarchenreuth --sign-key franz
…

     Franz <franz@aufstand.net>

This key is due to expire on 2342-09-12.
Are you sure that you want to sign this key with your
key "OG Schnarchenreuth <og-schnarchenreuth@de.raf.org>" (3D572635FE154D6F)

Really sign? (y/N) y

gpg --homedir kleinkuhkackerode --sign-key gerda
…

     Gerda <gerda@aufstand.net>

This key is due to expire on 2342-09-12.
Are you sure that you want to sign this key with your
key "OG Kleinkuhkackerode <og-kleinkuhkackerode@de.raf.org>" (9B06BB3E45C0ED87)

Really sign? (y/N) y

Weiterhin signiert die Bundesorganisation die User-IDs der beiden Ortsgruppen. Dabei spricht die Bundesorganisation den Ortsgruppen durch eine Trust-Signatur das Vertrauen aus, weitere Signaturen an anderen Schlüsseln zu erzeugen, die den von den Ortsgruppen signierten Schlüsseln Gültigkeit verleihen:

gpg --homedir bundesorga --edit-key schnarchenreuth
…
pub  rsa3072/3D572635FE154D6F
     created: 2342-08-29  expires: 2342-09-12  usage: C   
     trust: unknown       validity: unknown
[ unknown] (1). OG Schnarchenreuth <og-schnarchenreuth@de.raf.org>

gpg> tsign
…

     OG Schnarchenreuth <og-schnarchenreuth@de.raf.org>

This key is due to expire on 2342-09-12.
Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)

  1 = I trust marginally
  2 = I trust fully

Your selection? 2

Please enter the depth of this trust signature.
A depth greater than 1 allows the key you are signing to make
trust signatures on your behalf.

Your selection? 1

Please enter a domain to restrict this signature, or enter for none.

Your selection? ↵

Are you sure that you want to sign this key with your
key "Bundesorga <bundesorga@de.raf.org>" (628EC85C849EEDD6)

Really sign? (y/N) y

gpg> save

gpg --homedir bundesorga --edit-key kleinkuhkackerode
…
[ unknown] (1). OG Kleinkuhkackerode <og-kleinkuhkackerode@de.raf.org>

gpg> tsign

…
  2 = I trust fully

Your selection? 2

Please enter the depth of this trust signature.
…

Your selection? 1

Please enter a domain to restrict this signature, or enter for none.

Your selection? ↵

…

Really sign? (y/N) y

gpg> save

Die Schlüssel der Mitglieder Franz und Gerda sind mit Signaturen ihrer jeweiligen Ortsgruppe versehen. Die beiden Ortsgruppen sind mit Trust-Signaturen auf Tiefe 1 von der Bundesorganisation versehen. Die Bundesorganisation bekommt jetzt noch eine Trust-Signatur auf Tiefe 2 von der geheimen Weltregierung:

gpg --homedir weltregierung --edit-key bundesorga
…
[ unknown] (1). Bundesorga <bundesorga@de.raf.org>

gpg> tsign

…
  2 = I trust fully

Your selection? 2

Please enter the depth of this trust signature.
…

Your selection? 2

Please enter a domain to restrict this signature, or enter for none.

Your selection? ↵

…

Really sign? (y/N) y

gpg> save

Nachdem die Ortsgruppen, die Bundesorganisation und die Weltregierung Schlüssel signiert haben, lassen sie die neuen Signaturen auch anderen zukommen, indem sie die eben signierten Schlüssel exportieren. Die exportierten Schlüssel können wieder bei der geheimen Weltregierung gesammelt, in eine einzelne Datei zusammengefügt und von allen Organisationsmitgliedern importiert werden:

rm *.txt
gpg --homedir weltregierung -ao bundesorga.txt --export bundesorga
gpg --homedir bundesorga -ao schnarchenreuth.txt --export schnarchenreuth
gpg --homedir bundesorga -ao kleinkuhkackerode.txt --export kleinkuhkackerode
gpg --homedir schnarchenreuth -ao franz.txt --export franz
gpg --homedir kleinkuhkackerode -ao gerda.txt --export gerda
cat *.txt > alle.txt
gpg --homedir weltregierung --import alle.txt
gpg --homedir bundesorga --import alle.txt
gpg --homedir schnarchenreuth --import alle.txt
gpg --homedir kleinkuhkackerode --import alle.txt
gpg --homedir franz --import alle.txt
gpg --homedir gerda --import alle.txt

Gerda und Franz haben sich noch nie persönlich kennen gelernt. Aber wenn Gerda der geheimen Weltregierung auf Tiefe 3 vertraut, dann besteht eine vollständige Vertrauenskette von Gerda zu Franz und allen anderen Mitgliedern und Organen der Organisation:

gpg --homedir gerda --edit-key weltregierung
…

gpg> ltsign

…

     Weltregierung <weltregierung@raf.org>

…
  2 = I trust fully

Your selection? 2

Please enter the depth of this trust signature.
…

Your selection? 3

Please enter a domain to restrict this signature, or enter for none.

Your selection? ↵

Are you sure that you want to sign this key with your
key "Gerda <gerda@aufstand.net>" (DF8EFF40C7FF747A)

The signature will be marked as non-exportable.

Really sign? (y/N) y

gpg> save

gpg --homedir gerda -k
…
pub   rsa3072 2342-08-29 [C] [expires: 2342-09-12]
      7D28C6F3576A2B2B266E9C9FDF8EFF40C7FF747A
uid           [ultimate] Gerda <gerda@aufstand.net>

pub   rsa3072 2342-08-29 [C] [expires: 2342-09-12]
      090FE842136E6E27EF401696628EC85C849EEDD6
uid           [  full  ] Bundesorga <bundesorga@de.raf.org>

pub   rsa3072 2342-08-29 [C] [expires: 2342-09-12]
      83DE14C87C6934337EB9632A0B0A582D53A8ED40
uid           [  full  ] Franz <franz@aufstand.net>

pub   rsa3072 2342-08-29 [C] [expires: 2342-09-12]
      E9CC7DBF7EE3CE0E7E06C8A59B06BB3E45C0ED87
uid           [  full  ] OG Kleinkuhkackerode <og-kleinkuhkackerode@de.raf.org>

pub   rsa3072 2342-08-29 [C] [expires: 2342-09-12]
      3AC1DF3D1933A4ECA57EE3A83D572635FE154D6F
uid           [  full  ] OG Schnarchenreuth <og-schnarchenreuth@de.raf.org>

pub   rsa3072 2342-08-29 [C] [expires: 2342-09-12]
      946327744C12AC7915C6C4D10A9B8934EA26FD48
uid           [  full  ] Weltregierung <weltregierung@raf.org>

Statt der Trust-Signatur auf Tiefe 3 hätte Gerda auch der geheimen Weltregierung „ultimativ“ vertrauen können (in --edit-key mit dem Befehl trust und der Auswahl 5 für ultimatives Vertrauen), weil damit auch die Gültigkeit des Schlüssels der Weltregierung auf „ultimativ“ gesetzt wird. Das ist aber sowas wie ein Blankoscheck, denn ultimatives Vertrauen bedeutet eigentlich, dass das dein eigener Schlüssel ist, also dass du im Prinzip auch den geheimen Schlüssel dazu hast (nur vielleicht nicht hier auf diesem Gerät, sondern sicher verwahrt), und niemand sonst.

Du hast bemerkt, dass die Trust-Signatur auch auf eine „Domain“ eingeschränkt werden kann. Damit ist der Teil rechts vom @ gemeint, oder eine Oberdomain davon (also bei hansi.mueller@amt4711.verwaltung.neustadt.ch wäre das amt4711.verwaltung.neustadt.ch oder verwaltung.neustadt.ch oder neustadt.ch oder ch). Damit wird dem signierten Schlüssel dann nur erlaubt, User-IDs unter dieser Domain das Vertrauen auszusprechen. Wenn ihr eine organisationseigene Domain habt, unter der alle E-Mail-Adressen der Organisation laufen, dann empfiehlt sich die Domain-Beschränkung.

Wenn jetzt die Bundesorganisation bei der geheimen Weltregierung in Ungnade fällt, dann bricht die Vertrauenskette von Gerda zu Franz (sofern Gerda nicht ihrer eigenen Bundesorganisation auch eine Trust-Signatur der nötigen Tiefe verpasst hat):

gpg --homedir weltregierung --edit-key bundesorga
…
[  full  ] (1). Bundesorga <bundesorga@de.raf.org>

gpg> revsig
You have signed these user IDs on key 628EC85C849EEDD6:
     Bundesorga <bundesorga@de.raf.org>
   signed by your key 0A9B8934EA26FD48 on 2342-08-30

user ID: "Bundesorga <bundesorga@de.raf.org>"
signed by your key 0A9B8934EA26FD48 on 2342-08-30
Create a revocation certificate for this signature? (y/N) y
You are about to revoke these signatures:
     Bundesorga <bundesorga@de.raf.org>
   signed by your key 0A9B8934EA26FD48 on 2342-08-30
Really create the revocation certificates? (y/N) y
Please select the reason for the revocation:
  0 = No reason specified
  4 = User ID is no longer valid
  Q = Cancel
Your decision? 0
Enter an optional description; end it with an empty line:
> Spalter!!
> ↵
Reason for revocation: No reason specified
Spalter!!
Is this okay? (y/N) y

pub  rsa3072/628EC85C849EEDD6
     created: 2342-08-29  expires: 2342-09-12  usage: C
     trust: full          validity: full
[  full  ] (1). Bundesorga <bundesorga@de.raf.org>

gpg> save

gpg --homedir weltregierung -ao bundesorga.txt --export bundesorga
gpg --homedir gerda --import bundesorga.txt
gpg --homedir gerda -k
…
pub   rsa3072 2342-08-29 [C] [expires: 2342-09-12]
      7D28C6F3576A2B2B266E9C9FDF8EFF40C7FF747A
uid           [ultimate] Gerda <gerda@aufstand.net>

pub   rsa3072 2342-08-29 [C] [expires: 2342-09-12]
      090FE842136E6E27EF401696628EC85C849EEDD6
uid           [ unknown] Bundesorga <bundesorga@de.raf.org>

pub   rsa3072 2342-08-29 [C] [expires: 2342-09-12]
      83DE14C87C6934337EB9632A0B0A582D53A8ED40
uid           [ unknown] Franz <franz@aufstand.net>

pub   rsa3072 2342-08-29 [C] [expires: 2342-09-12]
      E9CC7DBF7EE3CE0E7E06C8A59B06BB3E45C0ED87
uid           [ unknown] OG Kleinkuhkackerode <og-kleinkuhkackerode@de.raf.org>

pub   rsa3072 2342-08-29 [C] [expires: 2342-09-12]
      3AC1DF3D1933A4ECA57EE3A83D572635FE154D6F
uid           [ unknown] OG Schnarchenreuth <og-schnarchenreuth@de.raf.org>

pub   rsa3072 2342-08-29 [C] [expires: 2342-09-12]
      946327744C12AC7915C6C4D10A9B8934EA26FD48
uid           [  full  ] Weltregierung <weltregierung@raf.org>

Ein paar Ideen, was ihr in eurer Organisation noch machen könnt:

Schlüsselsignaturen mit Ablaufdatum (--ask-cert-expire),
ein richtiges Vertrauens-Netz statt einer Hierarchie und natürlich
ein organisationseigener WKD-Server.

Quantencomputer

Ein Blick in die Zukunft: Quantencomputer sind ein Gegenstand aktueller Forschung und derzeit nicht so im praktischen Einsatz, dass das für die Kryptographie irgendeine Bedeutung hätte. Aber Quantencomputer sind theoretisch gut verstanden und es gibt sie im Labormaßstab. Wenn deren technische Umsetzung in praktisch relevanten Größenordnungen möglich wäre (was derzeit nicht gesichert, aber auch noch nicht ausgeschlossen ist), dann wären Quantencomputer eine Bedrohung für die asymmetrische Kryptographie, wie sie bei OpenPGP verwendet wird. Auch rückwirkend natürlich: Heute sicher verschlüsselte Nachrichten könnten in Zukunft von Unbefugten gelesen werden, wenn es leistungsfähige Quantencomputer gibt.

Hier kannst du dazu mehr erfahren.

Sowohl RSA als auch ECC kann mit Quantencomputern gebrochen werden. Wenn es einen hinreichend leistungsfähigen Quantencomputer gibt (Bislang existiert im bekannten Universum keiner. Was Geheimdienste so haben, weiß man natürlich nicht genau.), dann kannst du also davon ausgehen, dass zu einem bekannten öffentlichen Schlüssel der dazugehörige geheime Schlüssel berechnet werden kann. Damit ist OpenPGP, wie es bisher verwendet wird, kaputt.

OpenPGP an sich als Standard für ein Datenformat ist eigentlich nicht kaputt, sondern die darin verwendeten konkreten Algorithmen. Es sind asymmetrische Kryptographie-Algorithmen in der Entwicklung, die auch von Quantencomputern nicht geknackt werden können. Die sind bislang nicht in OpenPGP standardisiert und GnuPG unterstützt auch bislang keinen einzigen solchen Algorithmus. Das könnte sich in Zukunft aber ändern. Dann wäre OpenPGP sicher vor Quantencomputern.

Eine mögliche Zukunft ist also: Ein quantencomputer-sicheres Kryptographieverfahren wird in OpenPGP spezifiziert und in GnuPG implementiert. Du erzeugst dir später dann ein neues Schlüsselpaar mit dem neuen Algorithmus. Dann gibt es irgendwann benutzbare Quantencomputer, die deine sämtliche alte Kommunikation offenlegen. Aber deine Kommunikation mit dem quantencomputer-sicheren Algorithmus wird dann sicher sein. Eine andere mögliche Zukunft ist: Es gibt nie Quantencomputer, die deine Schlüssel knacken können. Das bleibt das theoretische Konzept, das es derzeit ist. Das dystopischste Zukunftsszenario ist: Es passiert demnächst ein Durchbruch und es gibt Quantencomputer, bevor OpenPGP quantencomputer-sicher ist. Dann hättest du ein Problem.

Vielleicht hast du die Befürchtung, dass das letztgenannte Szenario eintritt. Oder auch das erstgenannte, und du möchtest nicht, dass deine heutige verschlüsselte Kommunikation in 10, 20 Jahren mittels Quantencomputer geknackt werden kann. Für beide Fälle könntest du dich nur wappnen, indem du nicht OpenPGP benutzt. GnuPG hilft dir aber trotzdem.

Unter dem Namen post-quantum cryptography (PQC) werden derzeit Algorithmen für asymmetrische Kryptographie entwickelt, die auch von Quantencomputern nicht gebrochen werden können. Die sind noch nicht etabliert und demnach noch nicht so gut beforscht. Also es ist nicht sicher, wie sicher sie sind.

Sicherer ist es, wenn du dich stattdessen an symmetrische Kryptographie hältst, denn die ist auch post-quantum und dabei sehr etabliert und gut erforscht. Um eine Datei nicht asymmetrisch, sondern symmetrisch zu verschlüsseln, ersetzt du bei GnuPG einfach das Kommandozeilenargument -e durch -c. -e steht für asymmetrische Verschlüsselung (mit einem oder mehreren öffentlichen Schlüsseln) und -c steht für symmetrische Verschlüsselung (mit einem Passwort). Die Entschlüsselung funktioniert in allen Fällen wie gewohnt mit dem Kommandozeilenargument -d und entweder dem passenden geheimen Schlüssel (bei asymmetrischer Verschlüsselung) oder dem richtigen Passwort (bei symmetrischer Verschlüsselung).

Probier einmal aus: Verschlüssele eine Datei.

gpg -aco ausgabedatei.txt eingabedatei.txt

Du wirst nach einem Passwort gefragt und die Klartextdatei eingabedatei.txt ist dann verschlüsselt in der neu angelegten Datei ausgabedatei.txt gespeichert. Damit du das Entschlüsseln sinnvoll testen kannst, musst du GnuPG neustarten, weil GnuPG sich das eingegebene Passwort für eine Weile merkt.

gpgconf --kill all

Dann kannst du den Text entschlüsseln:

gpg -d ausgabedatei.txt

Du wirst nach dem Passwort gefragt und wenn du das richtig eingegeben hast und nicht per Kommandozeilenargument -o die Ausgabe in eine Datei umgelenkt hast, dann erscheint der entschlüsselte Text in deinem Terminalfenster.

Innerhalb der symmetrischen Verschlüsselung kannst du auch eine asymmetrische Signatur an deiner Nachricht haben: -sc lässt sich genauso kombinieren wie -se. Aber wenn du davon ausgehst, dass es Quantencomputer gibt, dann kann die asymmetrische Signatur ja gefälscht sein. Andererseits brauchst du die auch nicht unbedingt, denn wenn du eine Nachricht mit einem bestimmten Passwort entschlüsseln kannst, dann ist das eine sichere Aussage darüber, dass die Nachricht nur von einer Person verschlüsselt worden sein kann, die das Passwort kennt (zumindest dann, wenn GnuPG keine Fehlermeldung zusätzlich zum entschlüsselten Text ausgibt).

So viel komplizierter als asymmetrische Kryptographie ist symmetrische Kryptographie eigentlich gar nicht. Wenn du bei asymmetrischer Kryptographie mit deinen Kommunikationspartner*innen öffentliche Schlüssel austauschst, dann musst du ja eh über einen manipulationssicheren Kanal die Fingerabdrücke abgleichen. Wenn dieser Kanal zufällig auch abhörsicher ist, dann kannst du über den Kanal auch Passwörter für die symmetrische Kryptographie austauschen. Also mit dem Passwortgenerator in deinem Passwortmanager oder einem anderen guten Offline-Passwortgenerator erzeugst du für jede deiner Kommunikationspartner*innen ein eigenes Passwort (das sehr komplex sein soll, denn du gibst es natürlich nicht selber ein, sondern hast es in deinem Passwortmanager). Es ist wichtig, dass du immer selber das Passwort generierst und das nicht deiner Kommunikationspartner*in überlässt, weil du nie weißt, ob andere Leute das genauso gut wie du verstanden haben, dass sie gleiche Passwörter nicht für verschiedene Zwecke benutzen dürfen. Weil deine Kommunikationspartner*in ebenso denkt und die Passwortgenerierung nicht dir überlassen will, generiert ihr am besten beide je ein halbes Passwort und verwendet das komplette aus zwei Hälften bestehende Passwort. Das symmetrische Passwort darf natürlich gerne auch häufig geändert werden.

E-Mail-Clients haben eher keine Unterstützung für symmetrische Kryptographie. In Mutt kriegt man es hin. In allen anderen wird es schwierig. Also das machst du dann auf der Kommandozeile.

Da es für Kommunikation mit symmetrischer Kryptographie sowieso keinen etablierten Standard gibt, musst du auch gar nicht GnuPG benutzen, dessen Herangehensweise an symmetrische Kryptographie weniger von Sinnhaftigkeit als vom OpenPGP-Standard geprägt ist. Mit einem frisch entwickelten Werkzeug wie Age bekommst du eine sichere Passwortverschlüsselung auf dem aktuellen Stand der Technik. Der Nachteil ist, dass deine Kommunikationspartner*innen sich ebenfalls Age installieren müssen.

Lobotomierte Computer

Bislang bin ich in dieser Anleitung immer davon ausgegangen, dass du einen (oder mehrere) Computer benutzt, der physisch in deinem Besitz ist und auf dem du beliebigen Programmcode ausführen kannst (das heißt: auf dem du Administratorrechte hast und ein Betriebssystem deiner Wahl installieren kannst). Das stimmt für Notebooks und Desktoprechner aktuellerer Generationen immer nur so halb, weil heutige Prozessoren geheimen Code ausführen, den niemand nachvollziehen kann, und du auf die Firmware des Mainboards keinen Einfluss hast. Aber zumindest kannst du auf normalen Universalrechnern tatsächlich beliebigen Programmcode ausführen (ggf. zusätzlich zu dem vorgenannten geheimen Programmcode) und es ist bislang nicht öffentlich bekannt geworden, dass der geheime Programmcode tatsächlich massenhaft Leute ausspioniert oder anderweitig in großem Stil Kryptographie torpediert. (Wenn du im Fadenkreuz stehen könntest, musst du aber gucken, wo du deine Computer kaufst.) Beides trifft auf Spielcomputer wie Touch-Tablets und sog. „Smart“-Phones nicht zu.

Eingesperrte Computer, die man erst mit einem Jailbreak befreien muss, bevor man sie tatsächlich vollumfänglich benutzen kann, sind nicht sicher betreibbar. Zum Zocken, Telefonieren und Selfies-Retweeten taugen sie wohl gerade noch, aber nicht für Kryptographie. Wenn du auf einem Gerät Kryptographie betreiben willst, dann musst du wissen und kontrollieren, welcher Programmcode auf diesem Gerät läuft. Sonst wirst du gehackt und abgehört. Staatstrojaner laufen auf „Smart“-Phone-Betriebssystemen.

Die Hacktivist*innen-Gruppe Capulcu beschreibt die Situation in ihrer 2015er Textsammlung „Disconnect!“ so:

„Vor zehn Jahren brauchte es eine koordinierte Operation mit mehreren Schnüffelbehördenmitarbeiter*innen um gerade mal die Wohnung einer Person zu verwanzen. Sollten gleich mehrere für diese Person relevante Orte abgehört werden, erhöhte sich der Aufwand entsprechend. Heute zahlt die abzuhörende Person mehrere hundert Euro für ihr stylisches Abhörgerät und zusätzlich monatlich anfallende Abhörgebühren. Die Zielperson trägt es in der Regel rund um die Uhr bei sich – freiwillig. Manche der besonders beflissenen Abzuhörenden stehen sogar stundenlang an, wenn die neueste Wanze vom Abhöranbieter ihres Vertrauens ausgeliefert wird.“

Hier stehen ein paar Hinweise für den Fall, dass du dringend einen lobotomierten Computer einsetzen musst.

In der Kryptographie gilt es als guter Stil, Schlüssel möglichst oft zu wechseln, denn wenn ein einzelner Schlüssel nur wenige Daten verschlüsselt, dann kann beim Abhandenkommen des Schlüssels auch nur wenig schiefgehen. Auf die Situation übertragen, in der du mehrere Geräte hast, von denen einzelne als unsicher angesehen werden können (im Sinne von: geheime Schlüssel könnten ausgeleitet werden), bedeutet das: Besser benutzt du auf den verschiedenen Geräten verschiedene OpenPGP-Schlüssel.

Noch genauer durchdacht: Ein unsicheres Gerät sollte niemals überhaupt nur in die Nähe eines geheimen Hauptschlüssels geraten. Nur ein geheimer Unterschlüssel zum Verschlüsseln, falls du mit diesem Gerät Nachrichten an dich entschlüsseln willst, und ein geheimer Unterschlüssel zum Signieren, falls du mit diesem Gerät signierte Nachrichten abschicken willst, sollten vorhanden sein. Den Hauptschlüssel brauchst du niemals auf einem unsicheren Gerät, also hat der da auch nichts verloren – selbst wenn du ein komplett neues OpenPGP-Schlüsselpaar (also einen eigenen neuen Hauptschlüssel) nur für dieses Gerät erzeugt hast. Den Hauptschlüssel solltest du sicher verwahren, damit der nicht abhanden kommt. Einen geheimen OpenPGP-Schlüssel mit nur den Unterschlüsseln ohne Hauptschlüssel erzeugst du mit gpg --export-secret-subkeys.

Wie wissen jetzt die Leute, die dir schreiben wollen, mit welchem Schlüssel sie ihre Nachricht verschlüsseln sollen? Du kannst zwar mehrere Verschlüsselungs-Unterschlüssel anlegen, aber es wird davon trotzdem nur einer benutzt. Das bringt also nichts. Du musst verschiedene Hauptschlüssel anlegen, einen „sicheren“ und einen „unsicheren“ zum Beispiel. Die kannst du gegenseitig signieren, damit die Leute nur den „sicheren“ Fingerabdruck abgleichen müssen und nicht beide. Auf deinem „sicheren“ Gerät hast du beide geheimen Schlüssel, den „sicheren“ und den „unsicheren“. Auf deinem „unsicheren“ Gerät hast du nur den „unsicheren“ geheimen Schlüssel (ohne Hauptschlüssel). Wer dir was schicken will, muss sich überlegen: Ist das nur mittelgeheim und ist es verhältnismäßig wichtig, dass du das auch auf dem „unsicheren“ Gerät lesen kannst? Dann wird es mit dem „unsicheren“ Schlüssel verschlüsselt. Solltest du das nur auf dem „sicheren“ Gerät lesen können, für extra Sicherheit? Dann wird es mit dem „sicheren“ Schlüssel verschlüsselt. Am besten benutzt du verschiedene E-Mail-Adressen für die beiden Zwecke, damit es nicht zu Verwechslungen kommt.

Ganz schön komplex. Wenn du die Komplexität lieber selber ausbaden willst, statt sie deinen Kommunikationspartner*innen aufzulasten, dann könntest du auch eine schlaue Hardwarelösung probieren. Ich habe weiter oben schon mal empfohlen: geheime Schlüssel nur auf Hardware-Modulen (Smartcards, z. B. ein USB-Token wie ein einfacher Nitrokey für 20 €) herumtragen, wo sie unmöglich herausgeholt werden können, selbst bei bekanntem Mantra. Für besonders eingeschränkte Computer, die nicht mal eine USB-Buchse haben, gibt es die auch mit NFC-Schnittstelle. Auf diese kleinen Dinger packst du mit einem sicheren Computer deine sicher verwahrten Unterschlüssel zum Signieren und Verschlüsseln drauf (ohne Hauptschlüssel). Und das ist der Witz: Die Schlüssel können da nur raufgeschrieben werden. Der umgekehrte Weg, einen aktuell drauf abgelegten Schlüssel auszulesen, ist unmöglich. Die Schlüsseloperationen Entschlüsseln und Signieren führt diese Hardware selbst aus, ohne den dazu benötigten Schlüssel rauszugeben. Damit hast du den Schlüssel also tatsächlich physisch in der Hand und er kann nicht kopiert werden. Wenn du das soweit im Griff hast, dass das Verfahren sicher ist (also du zum Entsperren der Smartcard auch noch ein Passwort eingeben musst und du bei Schlüsseloperationen noch ein Knöpfchen drücken musst, damit dein gehacktes Cyberphone nicht bei angestecktem Hardwaretoken beliebige Schlüsseloperationen ohne dein Zutun ausführen kann), dann sollte auch ein gemeinsames Schlüsselpaar für alle deine Geräte ausreichen.

Als OpenPGP-Umsetzung für Android wird OpenKeychain empfohlen. Ich habe es nicht getestet und gebe das hier einfach mal ungeprüft wieder.

Welcher E-Mail-Client für Android und IOS infrage kommt, kann ich schwer sagen. K-9 Mail wird oft genannt. Wie gut das benutzbar ist, weiß ich nicht. Es scheint Autocrypt zu unterstützen, ist also suspekt.

Kleingedrucktes

Die Quellen der einzeln stehenden Bilder sind verlinkt. Die Quellen der kleinen Bilder vor Linktexten sind:

Das Design ist inspiriert von Erus Input und die Navigation in Teilen angelehnt an secushare.org.

Meine eigenen Beiträge sind lizenziert unter der Creative Commons Attribution 4.0 International License.