Table of Contents

GnuPG-Schlüsselhierarchie: passender Algorithmus für jede Aufgabe, Schlüsselaustausch ohne Verlust des Web of Trust

Vor ein paar Wochen habe ich mir einen neuen Key für GnuPG/PGP (im Folgenden einfach “GPG” genannt) zugelegt, weil mein bisheriger abgelaufen ist. Das habe ich zum Anlass genommen meine Vorgehensweise beim Erstellen eines GPG-Schlüssels zu überarbeiten. Die Erkenntnisse will ich hier festhalten, vielleicht bringt es ja jemandem etwas ;-). Ziel war:

  • Fein granulare Schlüsselhierarchie: Eine GPG-Aufgabe → Ein Schlüssel.
  • Die verschiedenen Schlüssel sollen den jeweils passendsten Algorithmus für die Aufgabe verwenden und bei Bedarf nach relativ kurzer Zeitspanne verfallen dürfen.
  • :!: Der Austausch eines Schlüssels soll NICHT zur Folge haben, dass das eigene Web-of-Trust verloren geht.

Dabei ist der letzte Punkt IMHO der Wichtigste. Er erspart einem, dass man wieder mühsam Signaturen für die neue Schlüssel einsammeln muss (den neuen Key vor Ablauf des alten Key mit selbigen zu signieren ist IMHO nur eine Notlösung, aber besser als nichts). Die Vorteile liegen auf der Hand:

  • Geeignetere Algorithmen und Schlüsselstärken für die jeweilige Aufgabe
    Beispiel: RSA erzeugt irrsinnig lange Signaturen, ist aber gut für Verschlüsselung geeignet. Wenn man dennoch zur Verschlüsselung auf RSA setzen will, kann man seinen Signierschlüssel über DSA realisieren. Zudem kann man die nötige Schlüssellänge (Bit) besser zwischen Aufgabe und Performance abwägen.
  • Mehr Sicherheit
    Selbst wenn mal ein Schlüssel mit brachialer Großrechnerpower über Jahre geknackt werden könnte, so hat der Angreifer bei regelmäßig wechselnden Schlüsseln dann immer nur einen Teil der Daten und muss für weiteren Zugang zu älteren/neueren Daten erneut genausoviel Aufwand in Kauf nehmen. Dies gilt natürlich auch, wenn ein Schlüssel anderweitig kompromittiert wird (was wahrscheinlicher ist als Brute-Force). Es ist ein deutlicher Unterschied, ob jemand ein einziges Jahr oder z.B. fünfzehn Jahre Kommunikation nachvollziehen kann ;-). Oder ob nur ein Webserver-Login ermöglicht wird oder gleich alle jemals verschickten Daten entschlüsselt werden können.

Grundlage

Damit man mit häufiger wechselnden Schlüsseln nicht andauernd sein Web-of-Trust ruiniert, fußt dass im Folgenden beschriebenen Szenario auf einem Hautpsignierschlüssel, welcher ausschließlich dazu verwendet wird, die eigenen und fremden Schlüssel zu zertifizieren (Certify), und nicht1) abläuft. D.h. dieser Schlüssel hat nur den Zweck, Dritten bei Verwendung der nach kürzerer Zeit2) wechselnden Unterschlüssel zu beweisen, dass der neue Schlüssel wirklich unter meiner Kontrolle steht und die damit verschlüsselten Inhalte auch nur mir zugänglich sein werden. Das muss man aber nicht extra “aufdröseln” oder “zusammenfrickeln”, da alle Identitäten immer am Hauptschlüssel hängen.

Die lange Laufzeit dieses Hautpsignierschlüssels ist dabei wenig sicherheitskritisch, da ein Angreifer damit “nur” die Identität fälschen könnte und so Kommunikationspartner ggf. weismachen, er sei ich. Er kommt aber nicht an bereits verschlüsselte Inhalte. Dies steht in keinem Verhältnis einen Großrechner Jahrzehnte zu beschäftigen, um den Hautpsignierschlüssel zu knacken. Man wird die Rechenzeit lieber in das “knacken” der Inhalte investieren als “lediglich” in das fälschen der Identität - es gibt zum Einen sicher billigere Wege, einem Dritten vorzugaukeln, man sei ich und zum Anderen könnte ich sofort einen neuen Key erstellen, nutzen und verbreiten (und damit all die Arbeit des Angreifers zu Nichte machen), sobald mir klar wird, dass jemand Drittes meine Identität zu fälschen versucht.

Nötiges GPG-Wissen

Dieser Text ist kein Anfänger-Tutorial, sondern ein Anwendungsbeispiel für fortgeschrittene GPG-Nutzer: Wer komplett neu ist, sollte sich zunächst 3-4 Tage Zeit nehmen und GPG kennen lernen3). Anschließend sollte die hier beschriebene Hierarchie aber gut umsetzbar sein, denn die Systematik dürfte auch für “neue” GPG-Nutzer Sinn ergeben.

Auch wenn man sich schon ein wenig mit GPG beschäftigt hat, ist es für den folgenden Text unabdingbar, zu 100% zu verstehen, was der Unterschied zwischen den verschiedenen Schlüsselfähigkeiten/Flags “Certify”, “Sign” und “Encrypt” ist. Außerdem sollte man wissen, dass verschiedene Algorithmen nicht mit jedem Flag kombiniert werden können. Daher will ich kurz darauf eingehen.

Die folgenden Flags können auf GPG-Schlüssel angewendet werden:

  • C: “Certify”
    Zertifizierung/Certification. Dient dazu Schlüssel (eigene/von Dritten) zu unterschreiben.
  • S: “Sign”
    Unterschreiben/Signing. Dient dazu Daten (eigene/von Dritten), z.B. eine Datei oder Text, zu unterschreiben.
  • E: “Encrypt”
    Verschlüsselung/Encryption. Dient dazu Daten (eigene/von Dritten), z.B. eine Datei oder Text, zu verschlüsseln.
  • A: “Authenticate”4)
    Authentifizieren. Dient dazu einen Aufrufe/challenge zu signieren. Kann z.B, genutzt werden, wenn der GPG-Schlüssel für einen (wie auch immer gearteten) Login genutzt werden soll, um der Kommunikationsgegenstelle beim challenge zu beweisen, dass man derjenige ist, für den man sich ausgiebt (also Identitätsnachweis), um so Zugriff auf einen Dienst zu erhalten. “Authenticate” ist also vergleichbar mit “Certify”/“Sign”, nur eben nicht für Schlüssel oder Daten, sondern für challenges. Kann je nach Software z.B. den Login via Passwort ersetzen oder ergänzen.

Die verschiedenen Algorithmen sind damit wie folgt kombinierbar:

  • RSA
    Alles. Ein RSA-Key kann mit Certify, Sign, Encrypt und Authenticate geflaggt werden.
  • DSA
    Ein nur zum signieren geeigneter Algorithmus, kann mit Certify, Sign und Authenticate geflaggt werden.
  • ElGamal
    Ein nur zum verschlüsseln geeigneter Algorithmus, kann nur mit Encrypt geflaggt werden.

Will man also verschlüsseln und signieren – was jeder GPG-Nutzer will ;-) – hat man daher die Wahl zwischen einem RSA-Hauptschlüssel mit RSA-Unterschlüssel(n) (⇒ RSA/RSA) oder einem DSA-Hauptschlüssel mit ElGamal-Unterschlüssel(n) (⇒ DSA/ElGamal bzw. DSA/ELG genannt). Auf die verschiedenen Algorithmen will ich hier nicht weiter eingehen, es sei nur gesagt, dass bisher geglaubt wurde (!=bewiesen), dass das dem DSA zu Grunde liegende mathematische Problem (Discrete logarithm problem :lang_en:) schwerer zu lösen sei, als das von RSA (Integer factorization problem), und daher ein RSA-Schlüssel mehr Bits aufweisen muss, um gleiche Sicherheit zu bieten. Allerdings kommen daran mehr und mehr Zweifel auf, und GPG wird u.a. daher in Zukunft auch den Default von DSA/ElGamal 1024/4096bit auf RSA 2048/2048bit ändern5). Es folgt dennoch eine kleine Entscheidungshilfe.

RSA:

  • Pro:
    • Sehr gut untersucht, weit verbreitet.
    • Offen entwickelt.
  • Contra:
    • Sehr lange Signaturen im vgl. mit DSA (fällt vor allem bei kurzen E-Mails ins Gewicht; selbst 4-5 Zeilen Text bringen immer 1-2 Zeilen à 80 Zeichen “Signaturlast” mit).
    • Weniger kompatibel zu sehr alten GPG-Versionen.

DSA:

  • Pro:
    • Kurze Signaturen
    • Hohe Kompatibilität zu sehr alten GPG-Versionen.
  • Contra:
    • Weniger untersucht als z.B. RSA
    • Kleine Keygröße macht DSA ggf. anfällig in Zukunft gebrochen zu werden. Der zu Grunde liegende Hash (SHA-1) ist zwar noch als vertrauenswürdig anzusehen, aber nicht mehr für neue kryptographische Anwendungen empfohlen.

Umsetzung

Genug Prosa, es wird konkreter. Ich will zeigen, wie man das Beschriebene umsetzen könnte. Ich erstelle daher beispielhaft eine Hierarchie, die 1:1 nachvollzogen werden kann (d.h. sie ist 100% praxistauglich):

  • Hautpsignierschlüssel (RSA-4096bit, Flag(s): Certify, Verfällt nie (=0))
    Nur zum zertifizieren eigener und fremder Schlüssel, also dem Aufbau/Erhalt eines Web-of-Trust. Alle Identitäten/User-IDs werden von GPG immer automatisch über den Hauptschlüssel integriert.
    • Unterschlüssel (DSA-1024bit, Flag(s); Sign, verfällt nach zwei Jahren (=2y))
      Dient nur dem Signieren von Daten (z.B. E-Mail). DSA statt RSA da sie Signaturen erheblich kürzer ausfallen.
    • Unterschlüssel (RSA-4096bit, Flag(s); Encrypt, verfällt nach zwei Jahren (=2y))
      Dient nur zum Verschlüsseln von Daten (z.B. E-Mail).
    • Unterschlüssel (RSA-4096bit, Flag(s); Authenticate, verfällt nach einem Jahr (=1y))
      Dient nur Authentifikationsprozessen (z.B. Login via SSH etc.).

Nun haben wir also für jede Aufgabe einen eigenen Schlüssel. Das Ganze funktioniert hervorragend, da GPG automatisch den passenden Schlüssel für die jeweilige Aufgabe auswählt. Das heißt, wenn eine Anwendung beispielsweise an GPG meldet “verschlüsseln eines Textes für den Empfänger john.doe@example.com” wird automatisch der passende Hauptschlüssel über die E-Mail-Identität john.doe@example.com sowie ein Unterschlüssel mit dem Flag Encrypt ausgewählt. Dabei stellt es überhaupt kein Problem dar, wenn der Unterschlüssel ein Verfallsdatum hat, der Hauptschlüssel jedoch nicht.

Dass der/die Unterschlüssel ein Verfallsdatum hat und der Hauptschlüssel nicht, ist im Grunde der Entscheidende Unterschied zu einem Default-Schlüsselpaar, das mit einem Verfallsdatum z.B. wie folgt aussähe:

  • Hautpsignierschlüssel (RSA oder DSA, Flag(s): Certify, Sign, Authenticate, verfällt in x Jahren)
    • Unterschlüssel (RSA oder ElGamal, Flags(s): Encrypt, verfällt in x Jahren)

Da der Hautpsignierschlüssel in der Default-Konfiguration ebenfalls abläuft, wenn man den zur Verschlüsselung genutzten Unterschlüssel aus Sicherheitsgründen ablaufen lässt, sind damit auch die ganzen Unterschriften/das Web of Trust im Eimer, da wie schon erwähnt alle Identitäten immer am Hautpsignierschlüssel hängen.

Der Text ist zwar auf *ix zugeschnitten, die Informationen sollten aber auch Nutzern anderer Betriebssysteme dienlich sein. Die Kommandozeilenausgaben können – je nach verwendeter GPG-Version – leicht variieren.

Per Default legt GPG Signierschlüssel mit den Flags Sign, Certify und Authenticate6) an. Um einen in unserem Aufbau benötigten Certify-only Schlüssel zu erhalten, wird die --expert-Option verwendet. Falls man einen DSA-Schlüssel mit mehr als 1024bit anlegen will, muss --enable-dsa2 verwendet werden (darauf verzichte ich in meinen Beispiel, das hauptsächlich auf RSA fußt und DSA aus Kompatibilitätsgründen “nur” mit 1024bit nutzt).

Erstellen des Hautpsignierschlüssels

Nochmal die Eckdaten: RSA-4096bit, Flag(s): C, Verfällt nie (=0).

Man rufe den passenden GPG-Schlüsseldialog auf: 

gpg --gen-key --expert

Man wählt dort (7) RSA (eigene Fähigkeit setzen). GnuPG konfrontiert einen dann mit folgender Ausgabe: 

Mögliche Aktionen für einen RSA Schlüssel: Unterschreiben Zertif. Verschlüsseln Authentifizieren 
Derzeitige erlaubte Aktionen: Unterschreiben Zertif. Verschlüsseln
[...]

Wie man sieht sind per Default für RSA die Flags Sign Certify Encrypt gesetzt. Wir wollen einen Certify-only 4096bit-Schlüssel, daher schalte ich die entsprechenden Fähigkeiten im Dialog um (→ S, E), so dass man folgende Ausgabe sehen sollte: 

Mögliche Aktionen für einen RSA Schlüssel: Unterschreiben Zertif. Verschlüsseln Authentifizieren 
Derzeitige erlaubte Aktionen: Zertif. 
[...]

Jetz passen die Flags. Weiter geht's: 

Ihre Auswahl? Q
RSA Schlüssel können zwischen 1024 und 4096 Bits lang sein.
Welche Schlüssellänge wünschen Sie? (2048) 4096
Die verlangte Schlüssellänge beträgt 4096 Bit
Bitte wählen Sie, wie lange der Schlüssel gültig bleiben soll.
         0 = Schlüssel verfällt nie
      <n>  = Schlüssel verfällt nach n Tagen
      <n>w = Schlüssel verfällt nach n Wochen
      <n>m = Schlüssel verfällt nach n Monaten
      <n>y = Schlüssel verfällt nach n Jahren
Wie lange bleibt der Schlüssel gültig? (0) 0
Schlüssel verfällt nie

Es folgen die persönlichen Angaben der Hauptidentität, d.h. man sollten den Namen und ggf. die “Haupt”-E-Mail-Adresse angeben.7) Alle Identitätsangaben können nachträglich editiert werden, weitere E-Mail-Adressen/Identitäten kann man ebenfalls später hinzufügen. Wenn man also in zwei Jahren die Firma und damit auch die berufliche E-Mail-Adresse wechselt ist das kein Problem.

Die Schlüsselgenerierung kann wirklich sehr lange dauern, u. U. sollte man schon mal 5-10 Minuten mitbringen.8)

Nach der Generierung sollte eine ähnlich lautende Meldung ausgegeben werden: 

gpg: Schlüssel <KEYID> ist als uneingeschränkt vertrauenswürdig gekennzeichnet
Öffentlichen und geheimen Schlüssel erzeugt und signiert.

Diese <KEYID> sollte man sich für die folgenden Schritte notieren. Falls man es verpasst hat oder ein paar Tage später etwas ändern will, schlägt man sie einfach kurz via gpg --list-keys nach.9)

Erstellen der Unterschlüssel

Erzeugen der Unterschlüssel, wie direkt unter “Umsetzung” beschrieben.

Sign-only DSA-Unterschlüssel

Erstellen des Sign-only DSA-Unterschlüssels (DSA-1024bit, Flag(s); Sign, verfällt nach zwei Jahren (=2y)). 

gpg --edit-key --expert Key-ID-des-Hauptschlüssels
Befehl> addkey

Nun muss man seinen Passphrase eingeben, um den Private-Key zu entsperren und den Unterschlüssel hinzufügen zu können.

Los geht's: 

Bitte wählen Sie, welche Art von Schlüssel Sie möchten:
   (2) DSA (nur unterschreiben/beglaubigen)
   (3) DSA (eigene Fähigkeit setzen)
   (4) Elgamal (nur verschlüsseln)
   (5) RSA (nur signieren/beglaubigen)
   (6) RSA (nur verschlüsseln)
   (7) RSA (eigene Fähigkeit setzen)
Ihre Auswahl? 3

Mögliche Aktionen für einen DSA Schlüssel: Unterschreiben Authentifizieren 
Derzeitige erlaubte Aktionen: Unterschreiben 

   (S) Umschalten der Fähigkeit zum Unterzeichnen
   (A) die Fähigkeit zur Authentifizierung umschalten
   (Q) Beendet

Nun setzt/entfernt man also die Flags, die man nicht haben will. Für einen Sign-only-Schlüssel muss man, wie man an der Zeile Derzeitige erlaubte Aktionen: Unterschreiben sieht, nichts mehr ändern. Es kann also direkt weitergehen: 

Ihre Auswahl? Q
Das DSA-Schlüsselpaar wird 1024 Bit haben.
Bitte wählen Sie, wie lange der Schlüssel gültig bleiben soll.
         0 = Schlüssel verfällt nie
      <n>  = Schlüssel verfällt nach n Tagen
      <n>w = Schlüssel verfällt nach n Wochen
      <n>m = Schlüssel verfällt nach n Monaten
      <n>y = Schlüssel verfällt nach n Jahren
Wie lange bleibt der Schlüssel gültig? (0) 2y
Key verfällt am <DATUM> <UHRZEIT>
Ist dies richtig? (j/N) j
Wirklich erzeugen? (y/N) y
Wir müssen eine ganze Menge Zufallswerte erzeugen.  Sie können dies
unterstützen, indem Sie z.B. in einem anderen Fenster/Konsole irgendetwas
tippen, die Maus verwenden oder irgendwelche anderen Programme benutzen.

Nun heißt es warten.

Ist alles erledigt, jetzt muss man die Änderungen speichern und kann anschließend wieder zur Konsole wechseln: 

Befehl> save

Encrypt-only RSA-Unterschlüssel

Erstellen des Encrypt-only RSA-Unterschlüssels (RSA-4096bit, Flag(s); Encrypt, verfällt nach zwei Jahren (=2y)). 

gpg --edit-key --expert Key-ID-des-Hauptschlüssels
Befehl> addkey

Nun muss man seinen Passphrase eingeben, um den Private-Key zu entsperren und den Unterschlüssel hinzufügen zu können.

Los geht's: 

Bitte wählen Sie, welche Art von Schlüssel Sie möchten:
   (2) DSA (nur unterschreiben/beglaubigen)
   (3) DSA (eigene Fähigkeit setzen)
   (4) Elgamal (nur verschlüsseln)
   (5) RSA (nur signieren/beglaubigen)
   (6) RSA (nur verschlüsseln)
   (7) RSA (eigene Fähigkeit setzen)
Ihre Auswahl? 7

Mögliche Aktionen für einen RSA Schlüssel: Unterschreiben Verschlüsseln Authentifizieren 
Derzeitige erlaubte Aktionen: Unterschreiben Verschlüsseln 

   (S) Umschalten der Fähigkeit zum Unterzeichnen
   (E) Umschalten der Verschlüsselungsfähigkeit
   (A) die Fähigkeit zur Authentifizierung umschalten
   (Q) Beendet

Nun setzt/entfernt man also die Flags, die man nicht haben will. Für einen Encrypt-only-Schlüssel muss man, wie man an der Zeile Derzeitige erlaubte Aktionen: Unterschreiben Verschlüsseln sieht, noch den “Unterschreiben”/Sign-Flag entfernen und dazu wie folgt vorgehen: 

Ihre Auswahl? S

Mögliche Aktionen für einen RSA Schlüssel: Unterschreiben Verschlüsseln Authentifizieren 
Derzeitige erlaubte Aktionen: Verschlüsseln 

   (S) Umschalten der Fähigkeit zum Unterzeichnen
   (E) Umschalten der Verschlüsselungsfähigkeit
   (A) die Fähigkeit zur Authentifizierung umschalten
   (Q) Beendet

Nun passt es. Weiter geht's: 

Ihre Auswahl? Q
RSA Schlüssel können zwischen 1024 und 4096 Bits lang sein.
Welche Schlüssellänge wünschen Sie? (2048) 4096
Die verlangte Schlüssellänge beträgt 4096 Bit
Bitte wählen Sie, wie lange der Schlüssel gültig bleiben soll.
         0 = Schlüssel verfällt nie
      <n>  = Schlüssel verfällt nach n Tagen
      <n>w = Schlüssel verfällt nach n Wochen
      <n>m = Schlüssel verfällt nach n Monaten
      <n>y = Schlüssel verfällt nach n Jahren
Wie lange bleibt der Schlüssel gültig? (0) 2y
Key verfällt am <DATUM> <UHRZEIT>
Ist dies richtig? (j/N) j
Wirklich erzeugen? (y/N) y
Wir müssen eine ganze Menge Zufallswerte erzeugen.  Sie können dies
unterstützen, indem Sie z.B. in einem anderen Fenster/Konsole irgendetwas
tippen, die Maus verwenden oder irgendwelche anderen Programme benutzen.
[...]

Nun heißt es warten.

Ist alles erledigt, jetzt muss man die Änderungen speichern und kann anschließend wieder zur Konsole wechseln: 

Befehl> save

Authenticate-only RSA-Unterschlüssel

Erstellen des Authenticate-only RSA-Unterschlüssels (RSA-4096bit, Flag(s); Authenticate, verfällt nach einem Jahr (=1y)). 

gpg --edit-key --expert Key-ID-des-Hauptschlüssels
Befehl> addkey

Nun muss man seinen Passphrase eingeben, um den Private-Key zu entsperren und den Unterschlüssel hinzufügen zu können.

Los geht's: 

Bitte wählen Sie, welche Art von Schlüssel Sie möchten:
   (2) DSA (nur unterschreiben/beglaubigen)
   (3) DSA (eigene Fähigkeit setzen)
   (4) Elgamal (nur verschlüsseln)
   (5) RSA (nur signieren/beglaubigen)
   (6) RSA (nur verschlüsseln)
   (7) RSA (eigene Fähigkeit setzen)
Ihre Auswahl? 7

Mögliche Aktionen für einen RSA Schlüssel: Unterschreiben Verschlüsseln Authentifizieren 
Derzeitige erlaubte Aktionen: Unterschreiben Verschlüsseln 

   (S) Umschalten der Fähigkeit zum Unterzeichnen
   (E) Umschalten der Verschlüsselungsfähigkeit
   (A) die Fähigkeit zur Authentifizierung umschalten
   (Q) Beendet

Nun setzt/entfernt man also die Flags, die man nicht haben will. Für einen Authenticate-only-Schlüssel muss man, wie man an der Zeile Derzeitige erlaubte Aktionen: Unterschreiben Verschlüsseln sieht, noch den “Unterschreiben”/Sign-sowie den “Verschlüsseln”/Encrypt-Flag entfernen und den “Authentifizierung”/Authenticate-Flag hinzufügen. Dazu geht man wie folgt vor: 

Ihre Auswahl? S

Mögliche Aktionen für einen RSA Schlüssel: Unterschreiben Verschlüsseln Authentifizieren 
Derzeitige erlaubte Aktionen: Verschlüsseln 

   (S) Umschalten der Fähigkeit zum Unterzeichnen
   (E) Umschalten der Verschlüsselungsfähigkeit
   (A) die Fähigkeit zur Authentifizierung umschalten
   (Q) Beendet

Ihre Auswahl? E

Mögliche Aktionen für einen RSA Schlüssel: Unterschreiben Verschlüsseln Authentifizieren 
Derzeitige erlaubte Aktionen: 

   (S) Umschalten der Fähigkeit zum Unterzeichnen
   (E) Umschalten der Verschlüsselungsfähigkeit
   (A) die Fähigkeit zur Authentifizierung umschalten
   (Q) Beendet

Ihre Auswahl? A

Mögliche Aktionen für einen RSA Schlüssel: Unterschreiben Verschlüsseln Authentifizieren 
Derzeitige erlaubte Aktionen: Authentifizieren 

   (S) Umschalten der Fähigkeit zum Unterzeichnen
   (E) Umschalten der Verschlüsselungsfähigkeit
   (A) die Fähigkeit zur Authentifizierung umschalten
   (Q) Beendet

Nun passt es. Weiter geht's: 

Ihre Auswahl? Q
RSA Schlüssel können zwischen 1024 und 4096 Bits lang sein.
Welche Schlüssellänge wünschen Sie? (2048) 4096
Die verlangte Schlüssellänge beträgt 4096 Bit
Bitte wählen Sie, wie lange der Schlüssel gültig bleiben soll.
         0 = Schlüssel verfällt nie
      <n>  = Schlüssel verfällt nach n Tagen
      <n>w = Schlüssel verfällt nach n Wochen
      <n>m = Schlüssel verfällt nach n Monaten
      <n>y = Schlüssel verfällt nach n Jahren
Wie lange bleibt der Schlüssel gültig? (0) 1y
Key verfällt am <DATUM> <UHRZEIT>
Ist dies richtig? (j/N) j
Wirklich erzeugen? (y/N) y
Wir müssen eine ganze Menge Zufallswerte erzeugen.  Sie können dies
unterstützen, indem Sie z.B. in einem anderen Fenster/Konsole irgendetwas
tippen, die Maus verwenden oder irgendwelche anderen Programme benutzen.
[...]

Jetzt heißt es warten.

Ist alles erledigt, jetzt muss man die Änderungen speichern und kann anschließend wieder zur Konsole wechseln: 

Befehl> save

Weitere Identitäten hinzufügen

gpg --edit-key Key-ID-des-Hauptschlüssels
Befehl> adduid

Der folgende Dialog sollte selbsterklärend sein. Falls einem die Identitätsverwaltung via Konsole zu frickelick ist, dem kann ich Seahorse als grafische Oberfläche empfehlen.

Falls man sich mal vertippt hat: Editieren ist nicht möglich. Stattdessen muss man die fehlerhafte Identität löschen und anschließend neu anlegen.

Die Hauptidentität kann mittels 

gpg --list-key Key-ID-des-Hauptschlüssels
Befehl> primary
Bitte genau eine User-ID auswählen.

Befehl> <NUMMER>

ausgewählt werden.

<NUMMER> entnimmt man der direkt darüber angezeigten Auflistung. Beispiel 

[uneingeschränkt] (1).  John Doe (privat) <foobar@example.com>
[uneingeschränkt] (2)   John Doe (business) <business@example.com>

(1). ist die derzeitige Hauptidentität. Um (2) zur Hauptidentität zu machen, müsste man also 

gpg --edit-key Key-ID-des-Hauptschlüssels
Befehl> primary
Bitte genau eine User-ID auswählen.

Befehl> 2

verwenden. Im der folgenden Auflistung ist die neue Hauptidentität mit einem Sternchen gekennzeichnet. Die Nummerierung ändert sich erst nach dem Speichern.

Ist alles erledigt, jetzt muss man die Änderungen speichern und kann anschließend wieder zur Konsole wechseln: 

Befehl> save
Befehl> quit

Überprüfen

Alles was man gerade erstellt hat, kann man sich einfach auflisten lassen: 

gpg --list-key Key-ID-des-Hauptschlüssels

Es sollte eine Ausgabe, erscheinen, die so ähnlich aussieht wie die Folgende: 

pub   4096R/B55A743F <DATUM>
uid                  John Doe (privat) <foobar@example.com>
uid                  John Doe (business) <business@example.com>
sub   1024D/56F9EF32 <DATUM> [verfällt: <DATUM>]
sub   1024R/A99B3881 <DATUM> [verfällt: <DATUM>]
sub   2048R/6D0696AE <DATUM> [verfällt: <DATUM>]

Hinweise zum Verständnis:

  • Hinter pub findet sich der Hauptschlüssel.
  • Hinter sub findet sich jeweils ein Unterschlüssel
  • Hinter uid finden sich and den Hauptschlüssel angehängte Identitäten (User-IDs).
  • Die Bitstärke, Algorhithmus, Key-ID und Erstellungsdatum verstecken sich in hinter <BITS><ALGORHITMUS>/<KEYID> <DATUM>. R steht dabei für RSA, D für DSA und g für ElGamal.10)

Fertig. Die neue Schlüsselhierarchie ist einsatzbereit. Jetzt einfach den Publickey exportieren und wie gewohnt nutzen, unterschreiben lassen etc..

Einstieg

Vokabular

Ergänzendes

1)
oder erst nach vielen Jahren
2)
z.B. jährlich
3)
am besten die Einstiegs-Weblinks am Ende dieses Textes durcharbeiten und alles einmal ausprobieren
4)
seit GPG 1.4 verfügbar
5)
s. http://lists.gnupg.org/pipermail/gnupg-users/2009-June/036794.html
6)
seit GPG 1.4
7)
es geht aber auch gänzlich ohne
8)
also nicht an der Meldung “Es sind nicht genügend Zufallswerte vorhanden. Bitte führen Sie andere Arbeiten durch, damit das Betriebssystem weitere Entropie sammeln kann!” verzweifeln, sondern einfach dem Rat folgen und ein wenig surfen, bis sich wieder etwas tut.
9)
Aufbau: pub <BITS><ALGORHITMUS>/<KEYID> <YYYY-MM-DD>. Die gesucht ID steht also hinter dem Schrägstrich.
10)
in der hier vorhanden Konfiguration nicht genutzt