GnuPG Anleitung - Seite 7

Das grundsätzliche Kommando, mit dem man den Schlüsseleditor in der Konsole öffnet:

gpg --edit-key Schlüssel-ID oder Benutzer-ID
gpg> Kommando
gpg> save oder quit

Für den Überblick können im Schlüsseleditor das list, check und fpr Kommando hilfreich sein. Das list Kommando gibt alle Informationen zu Schlüsseln aus. Das check Kommando überprüft und listet alle Zertifikate. Das fpr Kommando zeigt den Fingerabdruck des Hauptschlüssels an.

Einzelne Kommandos können auch direkt erfolgen:

gpg --Kommando Schlüssel-ID oder Benutzer-ID

Zur Gewährleistung der Eindeutigkeit sollte die Schlüssel-ID des Hauptschlüssels statt der Benutzer-ID als Parameter benutzt werden. Zur Ermittlung der Schlüssel-ID lässt man sich passende Schlüssel anzeigen. Die Schlüssel-ID sollte in Langform (mit den sechszehn letzten Zeichen des Fingerprints) und mit dem gesamten Fingerprint angegeben werden.

gpg --Kommando 4623BA84 (Kurzform, 32-Bit)
gpg --Kommando 5A1796454623BA84 (Langform, 64-Bit)
gpg --Kommando "2883 3DFE AF81 8885 51C0  5241 5A17 9645 4623 BA84"

In der gpg.conf sollte man für Anzeigen generell die Langform und die Ausgabe des Fingerprints festlegen:

keyid-format long
with-fingerprint

Siehe auch die Heise-Meldung Haufenweise Fake-PGP-Schlüssel im Umlauf und den Artikel OpenPGP: Duplicate keyids - short vs long im Sumptuous Capital Blog.

Während der Bearbeitung eines Schlüssels erfolgen nach Eingabe eines Kommandos u. U. weitere selbsterklärende Nachfragen, Bestätigungsanfragen, Auswahldialoge und die Abfrage der Passphrase. Mit dem help Kommando erhält man eine Übersicht aller möglichen Kommandos. Jede Bearbeitung wird mit save oder quit abgeschlossen. Mit dem save Kommando werden vorgenommene Änderungen gespeichert oder mit dem quit Kommando der Schlüsseleditor verlassen und alle Änderungen verworfen.

Anzeige-Kommandos kann zusätzlich ein Muster als Parameter mitgegeben werden, um nur die Schlüssel auswerfen zu lassen, bei denen Teile oder der gesamte Inhalt einer Benutzer-ID (Namen und E-Mail Adressen) oder die Schlüssel-ID auf das Muster zutreffen. Zusätzlich kann der Umfang und der Inhalt der Ausgaben vorab mit Parametern für die list-options Option in der gpg.conf bestimmt werden.

• Kurze Anzeige

gpg --list-keys [Muster]

• Anzeige plus Zertifikate

gpg --list-sigs [Muster]

• Anzeige plus Zertifikate und ihrem Überprüfungsstatus

gpg --check-sigs [Muster]

• Anzeige plus Fingerabdruck des Hauptschlüssels

gpg --Kommando --fingerprint [Muster]

Bei der Ausgabe werden in der ersten Spalte je nach gewähltem Kommando verschiedene Kürzel angezeigt:

Parameter für die list-options Option in der gpg.conf:

In die gpg.conf werden ausgewählte Parameter mit Komma oder Leerzeichen getrennt hinter die list-options Option gesetzt. Mit no-parameter wird die Bedeutung negiert.

list-options [no-]parameter1 parameterN

gpg --edit-key test@test.de
gpg> adduid

Anwendung:

• neue oder zusätzliche E-Mail bzw. Kontaktadresse
• Wechsel des E-Mail Providers
• alte Kontaktadresse nicht mehr genutzt und wird zurückgezogen
• Aufnahme eines zusätzlichen Spitznamens oder Pseudonyms

gpg --edit-key test@test.de
gpg> uid N
gpg> primary

Damit wird bei mehreren Benutzer-IDs eine als die primäre Benutzer-ID gekennzeichnet und sollte bei der Auflistung oder Auswahl von Schlüsseln primär angezeigt werden.

Anwendung:

• bei mehr als einer Benutzer-ID

gpg --edit-key test@test.de
gpg> uid N
gpg> deluid

Für N wird die Nummer der betreffenden Benutzer-ID ausgewählt, die gelöscht werden soll. Wurde der Schlüssel bereits veröffentlicht, muss die Benutzer-ID zurückgezogen und der Schlüssel danach neu veröffentlicht werden.

gpg --edit-key test@test.de
gpg> uid N
gpg> revuid

Damit wurde für die ausgewählte Benutzer-ID ein Rückzugsvermerk ausgestellt und in der Schlüsselanzeige wird der Benutzer-ID der [widerrufen] Hinweis vorangestellt. Um den Rückzug global wirksam werden zu lassen, muss der Schlüssel exportiert bzw. auf einem Schlüsselserver veröffentlicht werden.

Anwendung:

• Kontaktadresse wird nicht mehr genutzt

gpg --edit-key test@test.de
gpg> passwd

Danach wird die alte Passphrase abgefragt und 2x die neue Passphrase eingegeben.

gpg --edit-key test@test.de
gpg> expire
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) 2014-12-31

Statt allgemeiner Zeitraumangaben mit n Zeitraum kann auch ein bestimmtes Datum nach dem Muster YYYY-MM-DD angegeben werden.

Anwendung:

• alternativ zum kompletten Schlüssel-Widerruf und Erstellung eines neuen Schlüssels

gpg --edit-key Schlüssel-ID
gpg> key N
gpg> expire
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) 2014-12-31

Für N wird die Nummer des Unterschlüssels ausgewählt, dessen Ablaufdatum geändert werden soll. Statt allgemeiner Zeitraumangaben mit n Zeitraum kann auch ein bestimmtes Datum nach dem Muster YYYY-MM-DD angegeben werden.

Anwendung:

• alternativ zum Unterschlüssel-Widerruf oder Hinzufügen eines neuen Unterschlüssels

gpg --edit-key Schlüssel-ID
gpg> keyserver
Geben Sie die URL Ihres bevorzugten Schlüsselservers ein:
hkps://keys.openpgp.org

Zusätzlich bzw. alternativ kann die URL des Schlüsselservers in der gpg.conf hinterlegt werden, so dass die URL automatisch bei neu erzeugten Schlüsseln oder bei Änderung der Krypto-Präferenzen im Eigenzertifikat gespeichert wird:

default-keyserver-url URL

gpg.conf

sig-keyserver-url hkps://keys.openpgp.org

Mit den Angaben wird zukünftig der öffentliche Schlüssel vom angegebenen Schlüsselserver bezogen, wenn der Kommunikationspartner den Schlüssel aktualisiert oder zwecks Signaturüberprüfung erstmalig herunterlädt.

gpg --output schlüsseldatei --armor --export test@test.de 

Wer einen Schlüssel im Binärformat benötigt, ersetzt --armor durch --no-armor.

gpg --output schlüsseldatei --armor --export-secret-keys test@test.de 

Wer einen Schlüssel im Binärformat benötigt, ersetzt --armor durch --no-armor.

gpg [--keyserver URL] --send-keys 92CFDAD95A2EEAA6

Wurde in der gpg.conf keine Schlüsselserver URL mit der keyserver Option hinterlegt, muss der Schlüsselserver im Kommando angegeben werden. Zu Schlüsselservern wird von GnuPG nur der öffentliche Schlüssel gesendet.

Über Parameter für die export-options Option in der gpg.conf kann vorab das Exportverhalten beeinflusst werden.

In die gpg.conf werden ausgewählte Parameter mit Komma oder Leerzeichen getrennt hinter die export-options Option gesetzt. Mit no-parameter wird die Bedeutung negiert.

export-options [no-]parameter1 parameterN

Die gleichen Parameter können im Schlüsselserver Kommando mit --keyserver-options [no-]parameter1 parmaterN verwendet werden. Weitere Parameter für Schlüsselserver sind unter Schlüsselring aktualisieren aufgeführt.

gpg --import datei

Ist die Schlüssel-ID bekannt:

gpg [--keyserver URI] --recv-keys Schlüssel-ID

Ist nicht bekannt, ob ein Schlüssel existiert:

gpg [--keyserver URI] --search-keys Muster

Wurde in der gpg.conf keine Schlüsselserver URI mit der keyserver Option hinterlegt, muss der Schlüsselserver im Kommando angegeben werden.

GnuPG wirft danach eine nummerierte Liste aller Schlüssel aus, auf die das Muster zutrifft. Nach Eingabe einer Nummer wird der betreffende Schlüssel in die öffentliche Schlüsselringdatei importiert.

Über Parameter für die import-options Option in der gpg.conf kann vorab das Importverhalten beeinflusst werden.

In die gpg.conf werden ausgewählte Parameter mit Komma oder Leerzeichen getrennt hinter die import-options Option gesetzt. Mit no-parameter wird die Bedeutung negiert.

import-options [no-]parameter1 parameterN

Die gleichen Parameter können im Schlüsselserver Kommando mit --keyserver-options [no-]parameter1 parmaterN verwendet werden. Weitere Parameter für Schlüsselserver sind unter Schlüsselring aktualisieren aufgeführt.

gpg --delete-keys 89E6F36838F20095
 
pub  1024D/0x89E6F36838F20095 2012-02-25 test2 test2 <test2@test.de>
 
Diesen Schlüssel aus dem Schlüsselbund löschen? (j/N) j

Das Löschen eigener Schlüssel bietet sich für Schlüssel an, die nur lokal im Gebrauch waren und nicht bereits zur Kommunikationsverschlüsselung veröffentlicht wurden. Bereits veröffentlichte Schlüssel müssen zuerst zurückgezogen und können ggf. danach auch gelöscht werden.

Wenn man eigene Schlüsselpaare entfernen will, möchte man i. d. R., dass der private und der öffentliche Schlüssel aus beiden Schlüsselringdateien gelöscht wird.

gpg --delete-secret-and-public-keys 92CFDAD95A2EEAA6
 
sec  3072D/0x92CFDAD95A2EEAA6 2012-02-09 test test <test@test.de>
 
Diesen Schlüssel aus dem Schlüsselbund löschen? (j/N) j
Dies ist ein privater Schlüssel! - Wirklich löschen? (j/N) j
 
pub  3072D/0x92CFDAD95A2EEAA6 2012-02-09 test test <test@test.de>
 
Diesen Schlüssel aus dem Schlüsselbund löschen? (j/N) j

Ein abgeschalteter Schlüssel kann nicht mehr zur Verschlüsselung verwendet werden, solange er abgeschaltet ist. Dafür können weiterhin Signaturen überprüft werden und Zertifikate sind weiterhin Schlüsseln bzw. Benutzer-IDs zuzuordnen.

gpg --edit-key Schlüssel-ID
gpg> disable

gpg --edit-key Schlüssel-ID
gpg> enable

Anwendung:

• alternativ zur Löschung eines Schlüssels

Das Eigenzertifikat und die eigenen Zertifikate der Benutzer-IDs des gesamten Schlüssels oder Unterschlüssel werden zurückgezogen, indem für die Zertifikate ein Widerrufszertifikat ausgestellt und anschließend der Schlüssel mit dem Widerrufszertifikat veröffentlicht wird.

Anwendung:

• Passphrase vergessen
• Schlüsselringdateien beschädigt
• Schlüssel wird nicht mehr verwendet
• der geheime Schlüssel wurde komprimitiert
• verwendeter Algorithmus gebrochen oder geschwächt

Die beiden ersten Punkte legen nahe, für jeden neu erstellten Schlüssel, der auch veröffentlicht wird, ein externes Widerrufszertifikat direkt nach der Erstellung anzufertigen und zur späteren Verwendung sicher zu verwahren. Zur sicheren Verwahrung kann man z. B. neben der Speicherung auf einem externen, ggf. zugangsgeschützten Medium alle Widerrufszertifikate in ein Archiv packen und das Archiv mit GnuPG symmetrisch verschlüsseln. Da während der Anfertigung von Widerrufszertifikaten die Passphrase abgefragt wird, ist deshalb ein späteres Widerrufszertifikat bei vergessener Passphrase nicht mehr möglich.

gpg --edit-key Schlüssel-ID
gpg> key N
gpg> revkey

gpg --output zertdatei --gen-revoke Schlüssel-ID

Mit dem obigen Kommando wird das Widerrufszertifikat erzeugt und zur späteren Verwendung in der externen zertdatei Datei gespeichert. Zum Zeitpunkt des tatsächlichen Widerrufs des Schlüssels wird die Datei wie beim Schlüssel-Import importiert und anschließend der öffentliche Schlüssel mit dem Widerrufszertifikat exportiert und verbreitet bzw. an einen Schlüsselserver gesendet. Widerrufene Schlüssel werden von GnuPG nicht mehr zur Verschlüsselung berücksichtigt.

Widerrufene Schlüssel sind in Auflistungen an einem enstprechenden Vermerk erkennbar:

In der Konsole:

pub 3072D/0x92CFDAD95A2EEAA6 2012-02-09 [widerrufen: 2012-02-27]
    Schl.-Fingerabdruck = 0469 14AB 60F2 D0D8 C1F9  C89D 92CF DAD9 5A2E EAA6
uid [widerrufen] test test <test@test.de>
 
sub 4096g/0xB728BB7FFBC19289 2012-02-09 [widerrufen: 2012-02-27]

Ein Schlüsseleigentümer kann einen anderen Schlüsselinhaber zum Widerruf-Agenten ernennen („designated revoker“), der stellvertretend den Schlüssel des Schlüsseleigentümers zurückziehen bzw. ein Rückzugs-Zertifikat ausstellen kann.

gpg --edit-key Schlüssel-ID
gpg> addrevoker sensitive
 
Geben sie die User-ID des designierten Widerrufers ein: Schlüssel-ID

Durch den sensitive Parameter werden Informationen zum Widerruf-Agenten bei einem Schlüssel-Export nicht mitexportiert, solange die --export-options export-sensitive-revkeys Exportoption nicht verwendet wird.

Um für den fremden Schlüssel ein Rückzugs-Zertifikat auszustellen, gibt der Widerruf-Agent das folgende Kommando ein und verfährt mit dem Rückzugs-Zertifikat wie beim Widerruf eines Gesamtschlüssels, um den Schlüssel tatsächlich zu widerrufen.

gpg --output zertdatei --desig-revoke Schlüssel-ID

siehe Schlüsselerstellung → Unterschlüssel (Signieren) u. Unterschlüssel (Verschlüsseln)

Anwendung:

• alter Unterschlüssel abgelaufen oder komprimitiert
• alternativ zur Erstellung eines komplett neuen Schlüssels

gpg --edit-key Schlüssel-ID
gpg> trust
 
Bitte entscheiden Sie, in wieweit Sie diesem User zutrauen,
Schlüssel anderer User korrekt zu prüfen (durch Vergleich
mit Lichtbildausweisen, Vergleich der Fingerabdrücke aus
unterschiedlichen Quellen ...)?
 
  1 = Weiß nicht so recht
  2 = Nein, ihm traue ich NICHT
  3 = Ich vertraue ihm marginal
  4 = Ich vertraue ihm vollständig
  5 = Ich vertraue ihm absolut
  m = Zurück zum Menü
 
Ihre Auswahl? 

Anwendung:

• für das Web of Trust sollte jedem neu aufgenommenen Schlüssel neben der zumindest lokalen Zertifizierung auch ein Vertrauensgrad vergeben werden

Ein lokales Zertifikat wird bei einem Schlüssel-Export nicht mitexportiert, sondern gilt nur im lokalen Schlüsselring und der Vertrauens-Datenbank für das lokale Web of Trust.

gpg --lsign-key Schlüssel-ID

Anwendung:

• für das lokale Web of Trust sollte jeder neu aufgenommene Schlüssel neben der Vergabe eines Vertrauensgrads zumindest lokal zertifiziert werden

Ein normales Zertifikat wird bei einem Schlüssel-Export mitexportiert und trägt so zum globalen Web of Trust bei. Deshalb sollte der Schlüssel nach der Zertififizierung an einen Schlüsselserver gesendet werden.

gpg --sign-key Schlüssel-ID

Werden Schlüssel nach festen Regularien einer Beglaubigungsrichtlinie zertifiziert, kann die URL zur Beglaubigungsrichtlinie im Zertifikat gespeichert werden. Dazu übergibt man dem Kommando zusätzlich --cert-policy-url URL oder setzt die URL dauerhaft in die gpg.conf:

cert-policy-url https://domain.tld/richtlinie

Ein weiterer Typ des normalen Zertifikats ist ein Zertifikat, das der Aussteller zu einem späteren Zeitpunkt nicht widerrufen kann.

gpg --edit-key Schlüssel-ID
gpg> nrsign

Bei einem Trust-Zertifikat handelt es sich um ein lokales oder exportierbares Zertifikat, in dem gleichzeitig Informationen über die Vertrauenswürdigkeit des Schlüsseleigentümers gespeichert sind. Zusätzlich ist im Zertifikat angegeben, bis zu welcher Vertrauenspfad-Tiefe der Schlüsseleigentümer seinerseits „in unserem Namen“ Trust-Zertifikate an andere Schlüsseleigentümer vergeben kann und ob die Zertifikate auf einen bestimmte Domainnamen der Benutzer-IDs bzw. Benutzerkreis beschränkt sind oder an jeden beliebigen Schlüsseleigentümer vergeben werden können.

gpg --edit-key Schlüssel-ID
gpg> tsign (exportierbar) oder ltsign (lokal)
 
Bitte wählen Sie, wie lange die Beglaubigung 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 die Beglaubigung gültig? (0) 0
 
Wie genau haben Sie überprüft, ob der Schlüssel, den Sie jetzt beglaubigen
wollen, wirklich der o.g. Person gehört?
Wenn Sie darauf keine Antwort wissen, geben Sie "0" ein.
 
   (0) Ich antworte nicht. (default)
   (1) Ich habe es überhaupt nicht überprüft.
   (2) Ich habe es flüchtig überprüft.
   (3) Ich habe es sehr sorgfältig überprüft.
 
Ihre Auswahl? ('?' für weitere Informationen): 3
 
Bitte entscheiden Sie, in wieweit Sie diesem User zutrauen,
Schlüssel anderer User korrekt zu prüfen (durch Vergleich
mit Lichtbildausweisen, Vergleich der Fingerabdrücke aus
unterschiedlichen Quellen ...)?
 
  1 = Ich vertraue ihm marginal
  2 = Ich vertraue ihm vollständig
 
Ihre Auswahl? 2
 
Geben Sie bitte die Tiefe dieser "Trust"-Signatur ein.
Eine Tiefe größer 1 erlaubt dem zu signierenden Schlüssel
Trust-Signatures für Sie zu machen.
 
Ihre Auswahl? 2
 
Geben Sie bitte eine Domain ein, um die Signatur einzuschränken
oder nur die Eingabetaste für keine Domain
 
Ihre Auswahl? test.de

Anwendung:

• Aufbau bzw. Nutzung einer OpenPGP PKI

Wurde der Schlüssel bereits veröffentlicht, müssen Zertifikate zurückgezogen und der Schlüssel danach neu veröffentlicht werden.

gpg --edit-key Schlüssel-ID
gpg> uid N
gpg> delsig

gpg --edit-key Schlüssel-ID
gpg> uid N
gpg> revsig

Anwendung:

• der Schlüssel bzw. Schlüsseleigentümer ist nicht mehr vertrauenswürdig

Das refresh-keys Kommando sollte in Abständen ausgeführt werden, um die Schlüssel im öffentlichen Schlüsselring zu aktualisieren. Dabei werden Änderungen an Schlüsseln wie neue oder zurückgezogene Zertifikate, Unterschlüssel, Benutzer-IDs usw. vom Schlüsselserver abgerufen und geänderte Schlüssel in den öffentlichen Schlüsselring importiert.

gpg [--keyserver URI] --refresh-keys

Wurde in der gpg.conf keine Schlüsselserver URI mit der keyserver Option hinterlegt, muss der Schlüsselserver im Kommando angegeben werden.

Die Ansteuerung und Verwendung von Schlüsselserver-Funktionen kann man durch Parameter für die keyserver-options Option in der gpg.conf beeinflussen:

In die gpg.conf werden ausgewählte Parameter mit Komma oder Leerzeichen getrennt hinter die keyserver-options Option gesetzt. Mit no-parameter wird die Bedeutung negiert.

keyserver-options [no-]parameter1 parameterN

Einige Schlüsselserver sind nicht nur über das unverschlüsselte HTTP Keyserver Protokoll (HKP – Horowitz Schlüsselserver Protocol), sondern auch über das verschlüsselnde HTTPS Keyserver Protokoll (HKPS) erreichbar, so dass Schlüssel-Aktualisierungen, -Importe und -Exporte veschlüsselt übertragen werden. Für die Ansteuerung und Verwendung von HKPS Schlüsselserver relevante Optionen können in der dirmngr.conf Konfigurationsdatei hinterlegt werden.

Nach Abschaltung des SKS Keyserverpools bieten sich drei Schlüsselserver an:

• der Schlüsselserver, den eventuell der eigene Mailanbieter betreibt (z. B. bei mailbox.org)
• der mit Hockeypuck betriebene Ubuntu Schlüsselserver, der Standard-Schlüsselserver ist, wenn kein anderer Schlüsselserver in der GnuPG Konfiguration angegeben wird und sich mit anderen Schlüsselservern synchronisiert
• der mit Hagrid betriebene keys.openpgp.org Schlüsselserver, der mit E-Mail Verifizierung arbeitet und sich nicht mit anderen Schlüsselservern synchronisiert

Nach Export des öffentlichen Schlüssels wird die Schlüsseldatei zuerst zu keys.open.org hochgeladen. Nach dem Upload stößt man über Buttons die Verifizierung der im Schlüssel erkannten E-Mail Adressen an, die über den Aufruf der URLs in den E-Mail Nachrichten von keys.openpgp.org abgeschlossen ist. Erst dann kann der Schlüssel über die Benutzer-ID bzw. E-Mail Adresse gefunden und der Schlüssel vollständig vom Schlüsselserver bezogen werden:

Will man später eine Benutzer-ID entfernen, die für einen veröffentlichten Schlüssel verifiziert wurde, ruft man die Management-Seite auf und klickt den Delete Button an:

Da es z. Zt. nur einen keys.openpgp.org Schlüsselserver gibt, der sich nicht synchronisiert, sollte man den Schlüssel parallel zum Ubuntu Schlüsselserver hochladen. Weitere Besonderheiten von keys.openpgp.org werden auf der FAQ und Usage Seite erläutert.

Wer Privoxy und Tor installiert hat, kann den gesamten unverschlüsselten oder verschlüsselten Datenverkehr anonymisieren. Dafür verwendet man den folgenden Parameter für die keyserver-options Option mit http://127.0.0.1:8118/ als Proxyadresse. Da Anonymisierung und verschlüsselter Transport zeitaufwendiger sind, bietet sich ein entsprechender Timeout-Wert von >= 60 Sekunden für die timeout keyserver-options Option an.

In der torrc Tor Konfigurationsdatei wird der Hostname des Schlüsselservers in die TrackHostExits Liste aufgenommen, um für die Dauer der Verbindungen zum Schlüsselserver den gleichen Tor Ausgang-Router zu verwenden.

Das Skript kann man z. B. täglich oder wöchentlich per cron nutzen, um die Schlüssel automatisch zu aktualisieren. Das Skript löscht nach der Aktualisierung alle Schlüssel, die nach der Aktualisierung immer noch abgelaufen sind, d. h. deren Ablaufdatum nicht geändert wurde. Wer das nicht möchte, entfernt nach # Abgelaufene Schlüssel entfernen den gpgdel ; sleep 5 && Aufruf.

Um unabhängig von anderweitigen Schlüsselringdateien (z. B. die APT Schlüsselringdatei) zu sein, die u. U. neben der pubring.gpg Schlüsselringdatei in der gpg.conf des Benutzers eingetragen sind, auf die der Benutzer aber keinen Schreibzugriff hat, wird in der gpgdefault Variable die gpg.conf ignoriert und die zu verwendende Schlüsselringdatei explizit benannt.

Im gpgrefresh Cron Skript muss der Pfad zum gpg_refresh Skript und der Loginname des BENUTZERS eingetragen werden, dessen Schlüssel aktualisiert werden sollen. Im gpg_refresh Skript ist ebenfalls der Loginname einzusetzen und mit GnuPG 2.0 zu entscheiden, ob man einen Schlüsselserver ohne (HKP) oder mit (HKPS) Verschlüsselung verwenden will. Außerdem ist zu entscheiden, ob die Namensauflösung des Schlüsselserver-Hostnamen und die Aktualisierung über Privoxy und Tor anonymisiert werden oder nicht. Entsprechende Hinweise stehen im Skript.

Vor der Aktualisierung wird ein Backup der Schlüsselringe und Vertrauens-Datenbank angelegt, das bei erfolgreicher Aktualisierung gelöscht und ansonsten wieder zurückgespielt wird. Beide Skripte sind so gehalten, dass es keinerlei Ausgaben gibt und nur per Mail über die Resultate informiert wird.

/etc/cron.weekly/gpgrefresh

#!/bin/sh
sudo -H -u BENUTZER /pfad/gpg_refresh >/dev/null
exit 0

#!/bin/sh
 
gpguser="BENUTZER"
gpghome="/home/$gpguser/.gnupg"
export gpghome
gpgbackup="/home/$gpguser/tmp"
gpg="/pfad/bin/gpg2"
gpgdefault="--no-options --no-default-keyring --keyring $gpghome/pubring.gpg --quiet --no-verbose --no-tty"
# GnuPG 2.1:
# gpgdefault="--no-options --no-default-keyring --keyring $gpghome/pubring.kbx --quiet --no-verbose --no-tty"
# GnuPG 2.0:
# HKP-Schlüsselserveradresse
# keyserver="hkp://eu.pool.sks-keyservers.net"
# HKPS-Schlüsselserveradresse
keyserver="hkps://hkps.pool.sks-keyservers.net"
cacertfile="/pfad/sks-keyservers.netCA.pem"
 
gpglist () {
  $gpg $gpgdefault --list-public-keys --with-colons 2>/dev/null | grep "^pub:" | wc -l
}
 
gpgdel () {
  for keyid in $($gpg $gpgdefault --list-public-keys --with-colons 2>/dev/null | grep "^pub:e" | cut -d: -f5); do
    $gpg $gpgdefault --batch --yes --no-auto-check-trustdb --delete-key $keyid
  done
}
 
gpgtdbupd () {
  $gpg $gpgdefault --batch --check-trustdb >/dev/null 2>&1
}
 
# Namensauflösung für Schlüsselserver
# nicht anonymisiert:
dig -t A -4 $(echo $keyserver | cut -d/ -f3) | grep NOERROR > /dev/null
# anonymisiert:
# tor-resolve $(echo $keyserver | cut -d/ -f3) >/dev/null 2>&1
 
if [ $? -gt 0 ]; then
 echo "Namensauflösung für GPG-Keyrefresh fehlgeschlagen - Status Code: $?\nWiederholen Sie die Aktualisierung mit $0." | mail -s "GPG-Keyrefresh: Namensausflösung" root
 exit 1
fi
 
# Backup der Schlüsseldaten
cp -f $gpghome/*.gpg $gpgbackup/ >/dev/null 2>&1 && \
# GnuPG 2.1:
# cp -f $gpghome/pubring.kbx $gpghome/*.gpg $gpgbackup/ >/dev/null 2>&1 && \
 
# Schlüssel-Aktualisierung
# mit GnuPG 2.0 muss ohne Anonymisierung über Privoxy und Tor die Zeile
# --keyserver-options http-proxy=http://127.0.0.1:8118/ \
# entfernt werden.
 
$gpg $gpgdefault --no-auto-check-trustdb --keyserver "$keyserver" \
  --keyserver-options ca-cert-file\=$cacertfile,no-honor-keyserver-url,no-include-isabled,timeout\=60 \
  --keyserver-options http-proxy=http://127.0.0.1:8118/ \
  --import-options merge-only,import-clean \
  --refresh-keys >/dev/null 2>&1
 
# GnuPG 2.1:
# $gpg $gpgdefault --no-auto-check-trustdb \
#  --keyserver-options no-honor-keyserver-url,no-include-isabled,timeout\=60 \
#  --import-options merge-only,import-clean \
#  --refresh-keys >/dev/null 2>&1
 
refreshstatus=$?
 
keyzahlold="$(gpglist)"
 
# Abgelaufene Schlüssel entfernen
# TrustDB aktualisieren
# Backups löschen oder wiederherstellen.
# Benachrichtigung
 
if [ $refreshstatus = 0 ]; then
  gpgdel ; sleep 5 && gpgtdbupd && sleep 5 && rm $gpgbackup/*.gpg
  keyzahl="$(gpglist)"
  echo "GPG-Keyrefresh wurde mit Status Code $refreshstatus beendet.\nIm Schlüsselring befinden sich jetzt $keyzahl Schlüssel. Vor der Aktualisierung $keyzahlold Schlüssel." | mail -s "GPG-Keyrefresh: erfolgreich" root
  exit 0
else
  mv $gpgbackup/*.gpg $gpghome/
  echo "GPG-Keyrefresh wurde mit Status Code $refreshstatus abgebrochen. Das Backup der Schlüsselringdateien wurde wiederhergestellt.\nSie können die Aktualisierung manuell mit $0 wiederholen" | mail -s "GPG-Keyrefresh: Fehlschlag" root
  exit 1
fi
 
exit 0

Die Bevorzugung von Algorithmen durch die Reihenfolge in verschiedenen Listen wirkt sich auf die lokale Verschlüsselung von Daten und die Verschlüsselung von Kommunikationsinhalten aus. Bei der lokalen (nicht-symmetrischen) Verschlüsselung mit eigenen Schlüsseln wird GnuPG immer die Algorithmen einsetzen, die in den Reihenfolgen an erster Stelle stehen.

Bei der Verschlüsselung von Daten oder Kommunikationsinhalten mit einem fremden Schlüssel will sowohl der Schlüsselanwender, als auch der Schlüsseleigentümer seine Präferenzen berücksichtigt wissen. GnuPG besitzt dafür einen intelligenten Mechanismus, der die Liste der Präferenzen im Eigenzertifikat des öffentlichen Schlüssels des Schlüsseleigentümers auf Übereinstimmung mit den Präferenzen abgleicht, die der Schlüsselanwender hat. Aus beiden Listen bildet GnuPG eine neue Liste der Algorithmen, die Schlüsseleigentümer und Schlüsselanwender gemeinsam haben und verwendet diese bei der Verschlüsselung, Signierung und Erzeugung von Prüfsummen.

Mit dem Befehl erhält man die Ausgabe aller von GnuPG unterstützen und in der OpenPG Spezifikation zugelassenen Algorithmen zur Public-Key („Öff. Schlüssel“) und symmetrischen („Verschlü.“) Verschlüsselung, für die Prüfsummen („Hash“) und zur Komprimierung.

Zum Setzen der bevorzugten Algorithmen im Eigenzertifikat mit dem setpref Kommando und in der gpg.conf mit den *-preferences Optionen kann man die Klarnamen oder die ebenfalls angegebenen Sn, Hn und Zn IDs der OpenPGP Spezifikation verwenden.

gpg --version
 
Unterstützte Verfahren:
Öff. Schlüssel: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Verschlü.: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
           CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Komprimierung: nicht komprimiert, ZIP, ZLIB, BZIP2

Der Befehl listet die im Eigenzertifikat gespeicherte Reihenfolge der bevorzugten Algorithmen auf:

gpg --edit-key Schlüssel-ID
gpg> showpref
 
[ uneing.] (1). test test <test@test.de>
     Verschlü.: TWOFISH, AES256, AES192, AES, 3DES, BLOWFISH, CAST5
     Digest: SHA256, RIPEMD160, SHA1
     Komprimierung: BZIP2, ZLIB, ZIP, nicht komprimiert
     Eigenschaften: MDC, Keyserver no-modify

Als Beispiel werden die obigen Präferenzen auf AES256 und TWOFISH für die symmetrische Verschlüsselung, SHA256 für die Prüfsummen und BZIP2 für die Komprimierung gesetzt:

gpg --edit-key Schlüssel-ID
gpg> setpref AES256 TWOFISH SHA256 BZIP2
 
Setze die Liste der Voreinstellungen auf:
     Verschlü.: AES256, TWOFISH, 3DES
     Digest: SHA256, SHA1
     Komprimierung: BZIP2, nicht komprimiert
     Eigenschaften: MDC, Keyserver no-modify
Die Voreinstellungen wirklich ändern? (j/N) j

Die Anzeige der Präferenzen nach der Änderung:

gpg --edit-key Schlüssel-ID
gpg> showpref
 
[ uneing.] (1). test test <test@test.de>
     Verschlü.: AES256, TWOFISH, 3DES
     Digest: SHA256, SHA1
     Komprimierung: BZIP2, nicht komprimiert
     Eigenschaften: MDC, Keyserver no-modify

Hat man mit den *-preferences Optionen in der gpg.conf ein „Profil“ der bevorzugten Algorithmen gespeichert (siehe Schlüsselerstellung), kann man mit einem weiteren Kommando das Profil als neue Präferenzen in das Eigenzertifikat übertragen bzw. speichern:

gpg --edit-key Schlüssel-ID
gpg> updpref
 
Setze die Liste der Voreinstellungen auf:
     Verschlü.: TWOFISH, AES256, AES192, AES, 3DES, BLOWFISH, CAST5
     Digest: SHA256, RIPEMD160, SHA1
     Komprimierung: BZIP2, ZLIB, ZIP, nicht komprimiert
     Eigenschaften: MDC, Keyserver no-modify
Die Voreinstellungen wirklich ändern? (j/N) j

Inhalt | Seite 6 | Seite 8