Signierte E-Mails und OpenPGP-Basics

außerdem: Grafische Tools, Unterschlüssel und das Ablaufdatum

Nachdem ich nun schon das zweite Jahr in Folge gewisse "Schwierigkeiten" beim Verlängern meines OpenPGP-Schlüssels hatte, den ich zum Signieren meiner ausgehenden Geschäfts-E-Mails nutze, möchte ich hier ein paar Basics zu OpenPGP und meine Erfahrungen rund um dieses Thema teilen.

Außerdem erkläre ich dir, wieso das Anlegen und Verwenden von Unterschlüsseln, das Entfernen des privaten Schlüssels aus dem Hauptschlüssel-Paar und ein Ablaufdatum für die Sicherheit deiner Schlüsselpaare essenziell sind.

Danke an dieser Stelle an die Debian-Entwickler:innen für diesen exzellenten Artikel [Englisch] zur Verwendung von Unterschlüsseln.

Vorab noch ein Hinweis
Dieser Blogartikel liefert dir alle Informationen, die du brauchst, um OpenPGP zu verstehen und das Hintergrundwissen, um gute Entscheidungen im Bezug auf deine Schlüsselpaare zu treffen. Er beinhaltet allerdings – außer für das Entfernen des Privaten Schlüssel des Hauptschlüssel-Paares – keine Schritt-für-Schritt-Anleitungen.

Technische Affinität oder zumindest der Wille, mit den grafischen Tools und einem Test-Schlüsselpaar (nimm erstmal keinen produktiven Schlüssel) zu experimentieren, sind also erforderlich.

* * *

Inhaltsverzeichnis

Der Sinn hinter signierten E-Mails
GUI-Tools zur Schlüsselverwaltung
OpenPGP-Basics
    Hauptschlüssel-Paar
    Unterschlüssel
    Inhalt eines Schlüssels
    Öffentlicher Schlüssel
    Privater Schlüssel des Hauptschlüssel-Paares
    Privater Schlüssel des Unterschlüssel-Paares
    Privaten Schlüssel des Hauptschlüssel-Paares entfernen
        Los gehts!
        GPG-Version kleiner als 2.1
        GPG-Version größer als 2.1
        Prüfen, ob alles geklappt hat und Passphrase ändern
    Schlüsselserver / Keyserver
        Löschen von Schlüsseln auf Schlüsselservern
Warum ein Ablaufdatum für den Hauptschlüssel essenziell ist
    Ablaufdatum bei privaten Schlüsseln
Kommandozeilen-Befehle

Ich möchte mit OpenPGP arbeiten, habe dabei aber Schwierigkeiten
Quellen und weiterführende Links

* * *

Der Sinn hinter signierten E-Mails

Das Signieren von geschäftlichen E-Mails ist sinnvoll, damit dein:e Empfänger:in nachprüfen kann, dass die Mail auch wirklich von dir persönlich verschickt wurde und nicht von jemandem, der sich als du ausgibt, wie das häufig bei Phishing der Fall ist. Denn das Fälschen von E-Mailabsendern ist sehr einfach möglich und der Absender einer E-Mail ungefähr soviel wert, wie der handschriftliche Absender auf einem Briefumschlag. Den kann schlichtweg jede:r draufschreiben – auch nachträglich noch während des Versandes.

Daher empfehle ich dir, gerade im geschäftlichen Bereich, für alle deine Mitarbeiter:innen gültige E-Mailsignaturen anzulegen und die Signaturfunktion auch stets zu verwenden. Das erhöht das Sicherheitsniveau beträchtlich und reduziert gleichzeitig das Risiko, dass Phishing-Angriffe erfolgreich sind. Denn Phishing-Mails können niemals signiert sein, solange dein privater Schlüssel in sicheren Händen liegt.

Wenn die (v.a. interne) geschäftliche Kommunikation mittels signierter E-Mails stattfindet, macht eine unsignierte E-Mail vom Chef an die Buchhaltung, Geld auf ein Konto zu überweisen, direkt stutzig.

* * *

GUI-Tools zur Schlüsselverwaltung

Für alle Aktionen rund um OpenPGP-Schlüssel empfehle ich dir, entsprechende Tools mit grafischer Oberfläche zu verwenden. Zwar lässt sich alles auch über die zugrundeliegenden Kommandozeilentools gpg und gpg2 erledigen. Diese sind jedoch so komplex, dass man schnell Fehler machen kann und übersichtlich bzw. eingängig sind die Befehle auch nicht.

Für Linux empfehle ich dir Seahorse bzw. Kleopatra.

Für Windows / macOS findest du entsprechende Software hier.

Plattformübergreifend empfehle ich dir Mailvelope.

Auf die Bedienung der Software gehe ich in diesem Beitrag jedoch nicht ein.

* * *

OpenPGP-Basics

Hauptschlüssel-Paar

Mit OpenPGP erstellst du dir ein sog. GPG-Schlüsselpaar, welches anschließend zum Signieren (Sign), Verifizieren (Verify/Check) und Ver-/Entschlüsseln (Decrypt/Encrypt) von Text, Dateien und E-Mails verwendet werden kann.

Jeder OpenPGP-Schlüssel enthält dabei mindestens ein Schlüsselpaar bestehend aus öffentlichem (blau) und privatem Schlüssel (rot) – nachfolgend Hauptschlüssel-Paar genannt.

Unterschlüssel

Dabei kann das Hauptschlüssel-Paar (schwarzer Totenkopf auf privatem Schlüssel) beliebig viele Unterschlüssel-Paare (weißer Totenkopf auf privatem Schlüssel) beinhalten.

Das ist in etwa vergleichbar mit einer Schließanlage, bei der du dir beliebig viele "weniger privilegierte" Schlüssel erzeugen kannst, es aber immer einen Zentralschlüssel gibt, der alles darf. Kommt dieser abhanden, muss die gesamte Schließanlage getauscht werden.

Inhalt eines Schlüssels

Bei einem Schlüssel – egal ob öffentlich oder privat – begegnen dir außerdem immer auch zwei eher "technisch" anmutende Dinge:

  • der Fingerabdruck (auch Fingerprint genannt)
  • die Schlüssel-ID (auch Key-ID oder ID genannt)

Der Fingerabdruck besteht aus 10 Blöcken mit je 4 Großbuchstaben & Zahlen, z.B. 1AAD CF02 A7C6 3294 3B2B 667B CC7D 6C68 A309 55B9. Der Fingerabdruck identifiziert einen Schlüssel immer eindeutig.

Die Schlüssel-ID besteht aus 4 oder 8 Blöcken mit je 4 Großbuchstaben & Zahlen, z.B. A549 90CD 22BE 7444. Meist ist hier noch ein 0x vorangestellt, so dass die gesamte Schlüssel-ID so aussieht: 0xA54990CD22BE7444. Leider kann es hier zu sog. Hash-Kollisionen kommen, so dass die Schlüssel-ID nicht zwangsläufig eindeutig ist.

Prüfe also immer zusätzlich nochmal den eindeutigen Fingerabdruck, bevor du einen Schlüssel verwendest bzw. diesem vertraust.

Öffentlicher Schlüssel

Der öffentliche Schlüssel eines jeden Schlüsselpaares ist – wie der Name schon sagt – öffentlich und darf bekannt gemacht werden. Diesen verwendet dein Gegenüber, um Inhalte an dich zu VERschlüsseln oder deine Signatur zu überprüfen. Er kann jedoch nicht zum ENTschlüsseln oder Signieren verwendet werden.

Privater Schlüssel des Hauptschlüssel-Paares

Der private Schlüssel des Hauptschlüssel-Paares hingegen ist ABSOLUT heilig.

Er darf unter keinen Umständen in fremde Hände gelangen.

Da dieser über deine E-Mailadresse(n) direkt an deine Identität(en) geknüpft ist, kann sich der Besitzer dieses Schlüssels als all diese Identitäten ausgeben, VERschlüsselte Inhalte ENTschlüsseln (auch rückwirkend), Inhalte im Namen dieser Identitäten signieren, weitere Unterschlüssel anlegen, das Ablaufdatum aller Schlüssel ändern und dem Schlüssel weitere Identitäten hinzufügen. Alles in allem hat er damit Kontrolle über wirklich alles, was mit diesem Schlüssel jemals verschlüsselt wurde und ggf. noch wird.

Daher muss dieser private Schlüssel deines Hauptschlüssel-Paares so sicher wie irgendwie möglich verwahrt werden. Am Besten auf einem sog. Air-Gapped-PC, also einem PC ohne jeglichen Internetzugang.

Privater Schlüssel des Unterschlüssel-Paares

Um den privaten Schlüssel des Hauptschlüssel-Paares sicher verwahren zu können, legst du dir mittels OpenPGP jeweils eigene Unterschlüssel für die Aktionen (Verschlüsseln / Signieren) an und teilst die öffentlichen Schlüssel mit deinem Gegenüber bzw. der Welt (siehe Schlüsselserver / Keyserver).

Aus dem GPG-Schlüssel kannst du nun – ein sauberes und sicheres Backup des gesamten "Schlüsselbundes" vorausgesetzt – den privaten Schlüssel des Hauptschlüssel-Paares entfernen. Wie das geht, beschreibe ich dir im nächsten Abschnitt.

Kommt der private Schlüssel eines deiner Unterschlüssel-Paare abhanden, so kannst du diesen mit dem privaten Schlüssel deines Hauptschlüssel-Paares (das ist der ganz ganz sicher verwahrte Schlüssel, den man nur für sehr wenige Fälle aus dem Tresor holt) jederzeit für ungültig erklären und einen Neuen erstellen, ohne deine digitale Identität komplett neu erzeugen zu müssen.

Privaten Schlüssel des Hauptschlüssel-Paares entfernen

Erstelle als Erstes bitte ein vollständiges Backup deines gesamten Schlüssels. So kannst du jederzeit wieder zu dem Stand zurückkehren, an dem du gestartet bist, auch wenn du versehentlich etwas zu viel gelöscht hast. 😅

Es reicht, wenn du dazu unter Linux / macOS den Ordner ~/.gnupg an einen temporären und sicheren Ort sicherst. Unter Windows liegt dieser Ordner vmtl. in deinem Profil unter C:\Users\USERNAME\.gnupg – bitte prüfe das jedoch selbst nochmal nach.

Dann kannst du dir über die grafischen Tools einen neuen Unterschlüssel anlegen. Als Zertifikatstyp wählst du RSA und als Schlüssellänge empfehle ich dir 4096 Bit – wer weiß, wann die Quantenkryptografie so weit ist, dass Schlüssel mit 2048 Bit geknackt werden können.

Das Ablaufdatum sollte nicht mehr als ein oder zwei Jahre betragen, siehe Warum ein Ablaufdatum für den Hauptschlüssel essenziell ist. Für Unterschlüssel kannst du theoretisch auch ein unbegrenztes Ablaufdatum setzen, da dieser spätestens mit dem Ablaufdatum des Hauptschlüssels ungültig wird.

Reminder
📆 Denk bitte daran, dir im Kalender einen Reminder zu setzen, das Zertifikat rechtzeitig vor dem Ablauf zu verlängern.

Ist das erledigt, bietet es sich an, nochmal ein Backup des oben genannten Ordners zu machen, denn im Anschluss entfernen wir den privaten Schlüssel des Hauptschlüssel-Paares vollständig aus dem GPG-Schlüssel.

Du erinnerst dich – den "weniger privilegierten" Schlüssel am gleichen Schlüsselbund mit dem Generalschlüssel zu tragen, gefährdet bei einem Verlust die Sicherheit der gesamten "Schließanlage".

Die folgenden Schritte finden ich ausschließlich auf der Kommandozeile statt, funktionieren teilweise aber auch mit grafischen Tools.

Los gehts!

Lass dir zuerst alle Schlüssel inkl. Schlüssel-ID und Fingerabdruck der Unterschlüssel anzeigen:

gpg2 --list-secret-keys --verbose --with-subkey-fingerprints

Die Ausgabe des Befehls sieht z.B. so aus (je nach Anzahl der Schlüssel):

sec   rsa4096 2024-01-05 [SC] [verfällt: 2025-01-06]
      1BCE0D11319D8201D30B57A9A54990CD22BE7444 <--- ℹ️ Fingerabdruck des Hauptschlüssels
uid        [ ultimativ ] Hans Wurst <hans@wurst.de>
ssb   rsa4096 2024-01-05 [E] [verfällt: 2025-01-06]
      A75E7A5A3827CA374CED4FF7E3CF74E622FFA08E <--- ℹ️ Fingerabdruck des ersten Unterschlüssels
ssb   rsa4096 2024-01-06 [S]
      D13AE50925C0B66E0527D6513FB990EA656C610E <--- ℹ️ Fingerabdruck des zweiten Unterschlüssels

Der Fingerabdruck deines Hauptschlüssels ist in diesem Beispiel 1BCE0D11319D8201D30B57A9A54990CD22BE7444, der des ersten (meist automatisch erstellten) Unterschlüssels ist A75E7A5A3827CA374CED4FF7E3CF74E622FFA08E und der des zweiten (gerade neu erstellten) Unterschlüssels, den wir künftig verwenden wollen, ist D13AE50925C0B66E0527D6513FB990EA656C610E.

Da sich das Vorgehen zum Entfernen des privaten Schlüssels des Hauptschlüssel-Paares je nach GPG-Version unterscheidet, führe einmal gpg2 --version aus, um deine Version herauszufinden. Bei mir ist es z.B. gpg (GnuPG) 2.4.3, also geht es direkt bei GPG-Version größer als 2.1 weiter.

GPG-Version kleiner als 2.1

Leider gibt es in dieser GPG-Version noch keinen einfachen Weg, um den privaten Schlüssel zu entfernen. Wir müssen also einen Umweg wählen und den Unterschlüssel exportieren, den privaten Schlüssel entfernen und den Unterschlüssel wieder importieren.

Alle Unterschlüssel exportieren (für den Befehl den Fingerabdruck des Hauptschlüssels verwenden):

gpg2 --output secret-subkeys.asc --export-secret-subkeys 1BCE0D11319D8201D30B57A9A54990CD22BE7444

Alternativ kannst du auch die Fingerabdrücke der zu exportierenden Unterschlüssel gefolgt von einem Ausrufezeichen angeben:

gpg2 --output secret-subkeys.asc --export-secret-subkeys A75E7A5A3827CA374CED4FF7E3CF74E622FFA08E!

Falls du mehr als einen Unterschlüssel exportieren willst, sieht der Befehl so aus:

gpg2 --output secret-subkeys.asc --export-secret-subkeys A75E7A5A3827CA374CED4FF7E3CF74E622FFA08E! D13AE50925C0B66E0527D6513FB990EA656C610E!

Entferne nun den privaten Schlüssel des Hauptschlüssels (für den Befehl den Fingerabdruck des Hauptschlüssels verwenden):

gpg2 --delete-secret-keys 1BCE0D11319D8201D30B57A9A54990CD22BE7444

Importiere nun wieder die zuvor exportierten Unterschlüssel:

gpg2 --import secret-subkeys.asc

Lösche anschließend noch die temporäre Export-Datei secret-subkeys.asc

GPG-Version größer als 2.1

Ab Version 2.1 ist es relativ einfach, den privaten Schlüssel zu entfernen.

Dazu benötigen wir nur den sog. Keygrip des Hauptschlüssels (für den Befehl den Fingerabdruck des Hauptschlüssels verwenden):

gpg2 --with-keygrip --list-key 1BCE0D11319D8201D30B57A9A54990CD22BE7444

Die Ausgabe des Befehls sieht z.B. so aus (je nach Anzahl der Schlüssel):

pub   rsa4096 2024-01-05 [SC] [verfällt: 2025-01-06]
      1BCE0D11319D8201D30B57A9A54990CD22BE7444
      Keygrip = 56598FAF98BBD33E7C9C8354CBEDC83F39C8D6EB <--- ℹ️ Keygrip des Hauptschlüssels
uid        [ ultimativ ] Hans Wurst <hans@wurst.de>
sub   rsa4096 2024-01-05 [E] [verfällt: 2025-01-06]
      Keygrip = CAD543EB47E805A6F7FB1D6E8D700F8BB282FD4B <--- ℹ️ Keygrip des ersten Unterschlüssels
sub   rsa4096 2024-01-06 [S]
      Keygrip = 112DCC31824C19DE2EA15A8DDAD7F973A5D83D43 <--- ℹ️ Keygrip des zweiten Unterschlüssels

Lösche nun im Ordner ~/.gnupg (unter Windows vmtl. in deinem Profil unter C:\Users\USERNAME\.gnupg) die Datei ~/.gnupg/private-keys-v1.d/56598FAF98BBD33E7C9C8354CBEDC83F39C8D6EB.key, wobei du hier natürlich den Keygrip verwendest, der dir nach der Eingabe des obigen Befehls ausgegeben wurde.

Wichtiger Hinweis
Sollte dein OpenPGP-Schlüssel kürzlich in das neue Format migriert worden sein, liegt dein privater Schlüssel auch noch im "alten Schlüsselbund" unter ~/.gnupg/secring.gpg. Sollte diese Datei nicht sowieso schon leer sein oder gar nicht existieren, lösche sie ebenfalls, da sie nicht mehr benötigt wird.

Prüfen, ob alles geklappt hat und Passphrase ändern

Ob der private Schlüssel des Hauptschlüssel-Paares erfolgreich gelöscht wurde, erkennst du nach Eingabe des folgenden Befehls an einer Raute # hinter dem sec:

gpg2 -K

Die Ausgabe des Befehls sieht z.B. so aus (je nach Anzahl der Schlüssel):

sec#  rsa4096 2024-01-05 [SC] [verfällt: 2025-01-06]
      1BCE0D11319D8201D30B57A9A54990CD22BE7444
uid        [ ultimativ ] Hans Wurst <hans@wurst.de>
ssb   rsa4096 2024-01-05 [E] [verfällt: 2025-01-06]
ssb   rsa4096 2024-01-06 [S]

Setze anschließend mit folgendem Befehl eine neue Passphrase für den / die Schlüssel – alternativ kannst du auch die grafischen Tools dafür nutzen (für den Befehl den Fingerabdruck des Hauptschlüssels verwenden):

gpg --edit-key 1BCE0D11319D8201D30B57A9A54990CD22BE7444

Fertig! 🥳 Du hast jetzt einen oder mehrere Unterschlüssel, die bei einem Verlust jederzeit mit dem privaten Schlüssel des Hauptschlüssels aus deinem Backup für ungültig erklärt werden können. Für den Schlüssel im Backup gilt selbstverständlich noch die alte Passphrase.

Alle Schritte findest du auch hier noch gut beschrieben – allerdings ausschließlich auf Englisch.

* * *

Schlüsselserver / Keyserver

Auf einem Schlüsselserver bzw. Keyserver können die öffentlichen Schlüssel zentral gespeichert und über die E-Mailadresse, die Schlüssel-ID oder den Fingerabdruck von überall abgerufen werden. Das geht entweder manuell über die Weboberfläche des Schlüsselservers oder automatisch über die Schnittstelle HKPS, welche in vielen (E-Mail)-Anwendungen oder Browser-Addons intergriert ist.

Damit der Schlüssel auf diesen Servern für andere abrufbar ist, muss er zuvor von dir hochgeladen worden sein. Das ist ebenfalls erneut notwendig, sobald du an deinem Schlüssel Änderungen vorgenommen hast, z.B. wenn du das Ablaufdatum angepasst oder weitere Unterschlüssel hinzugefügt hast.

Bei den Schlüsselservern gibt es außerdem einen zentralen Unterschied: Die Verifizierung der E-Mailadresse(n)

Die auf der Software Hockeypuck basierenden Keyserver folgen (noch) dem Prinzip des Web-Of-Trust und laden alle Beglaubigungen / Signaturen der öffentlichen Schlüssel auf den Server hoch. Diese Art von Schlüsselservern kann (und wird leider) von Spammern missbraucht, welche in fremdem Namen / mit fremder E-Mailadresse Schlüssel generieren und den Schlüsselserver damit "zumüllen".

Die auf der Software Hagrid bzw. Mailvelope Keyserver basierenden Schlüsselserver hingegen verzichten zugunsten einer Behebung dieses Spam-Problems auf das Prinzip des Web-Of-Trust. Außerdem sind diese Schlüsselserver DSGVO-konform, da sie eine Löschung der öffentlichen Schlüssel (nach vorheriger E-Mailbestätigung) vorsehen. Das ist bei den zuvor genannten Servern (bewusst) nicht möglich, da es das Prinzip des Web-Of-Trust zunichte machen würde. Bei heise.de wird das etwas genauer erklärt.

Nicht verifizierende Server:

Verifizierende Server:

Löschen von Schlüsseln auf Schlüsselservern

Es ist auf den nicht verifizierenden Schlüsselservern bewusst nicht möglich, öffentliche Schlüssel und deren Beglaubigungen / Signaturen jemals wieder zu löschen. Das hat angesichts der Einführung der DSGVO auch dazu geführt, dass die früher weit verbreiteten SKS-Keyserver abgeschaltet wurden / werden mussten. Wie lange es die nicht verifizierenden Server noch geben wird, ist ungewiss. Mit einem Widerrufs-Zertifikat lassen sich die Schlüssel zwar für ungültig erklären, doch auch dieser Vorgang bleibt weiterhin öffentlich sichtbar – inkl. aller bisherigen Beglaubigungen / Signaturen.

* * *

Warum ein Ablaufdatum für den Hauptschlüssel essenziell ist

Es wäre natürlich denkbar, den öffentlichen Schlüssel deines Hauptschlüssels ohne Ablaufdatum zu versehen. Das bedeutet aber auch, dass dieser – sofern er nicht eines Tages mit einem Widerrufs-Zertifikat für ungültig erklärt wird – unendlich Gültigkeit besitzt. Da dieses Widerrufs-Zertifikat im Vorfeld generiert und ebenfalls sicher verwahrt werden müsste, ist es immer besser, eine Notlösung in der Hinterhand zu haben, falls das nicht geschehen ist oder man dieses verloren hat.

Reduzierst du die Gültigkeitsdauer eines öffentlichen Zertifikats beispielsweise auf ein oder zwei Jahre, hast du eine Art Totmannschalter eingebaut, der bei einem Verlust des privaten Schlüssels oder dessen Passworts sicherstellt, dass spätestens nach dem Erreichen des Ablaufdatums kein Schindluder mehr damit getrieben werden kann.

Außerdem zeigst du nach außen durch ein regelmäßig aktualisiertes Ablaufdatum, dass der Schlüssel noch "lebendig" ist und aktiv verwendet wird. Und ein kleiner Refresh der Bedienung der oben genannten grafischen Tools für die Schlüsselverwaltung schadet sicherlich auch nicht. Einen Erste-Hilfe-Kurs wiederholt man schließlich auch regelmäßig, stimmts? 😉

Ablaufdatum bei privaten Schlüsseln

Private Schlüssel haben kein Ablaufdatum. Ein Ablaufdatum gibt es ausschließlich bei öffentlichen Schlüsseln, denn selbst wenn ein privater Schlüssel ablaufen würde, würde niemand etwas davon mitbekommen, da er ja privat ist und niemals in fremde Hände geraten darf.

* * *

Kommandozeilen-Befehle

Hier findest du ein paar gängige Kommandozeilen-Befehle für die Schlüsselverwaltung. Diese erheben keinen Anspruch auf Vollständigkeit und ich betone nochmal, für die Schlüsselverwaltung vorrangig grafische Tools zu verwenden.

Auch wenn die meisten Befehle ebenfalls mit gpg und ggf. leicht veränderter Syntax verwendet werden könnten, verwende ich hier ausschließlich gpg2.

Alle Schlüssel inkl. Schlüssel-ID und Fingerabdruck des Hauptschlüssels anzeigen

gpg2 --list-secret-keys --keyid-format=long
sec   rsa4096/A54990CD22BE7444 2024-01-05 [SC] [verfällt: 2025-01-06]
      1BCE0D11319D8201D30B57A9A54990CD22BE7444
uid              [ ultimativ ] Hans Wurst <hans@wurst.de>
ssb   rsa4096/E3CF74E622FFA08E 2024-01-05 [E] [verfällt: 2025-01-06]

Alle Schlüssel inkl. Schlüssel-ID und Fingerabdruck der Unterschlüssel anzeigen

gpg2 --list-secret-keys --verbose --with-subkey-fingerprints
sec   rsa4096 2024-01-05 [SC] [verfällt: 2025-01-06]
      1BCE0D11319D8201D30B57A9A54990CD22BE7444
uid        [ ultimativ ] Hans Wurst <hans@wurst.de>
ssb   rsa4096 2024-01-05 [E] [verfällt: 2025-01-06]
      A75E7A5A3827CA374CED4FF7E3CF74E622FFA08E

Fingerabdruck des Hauptschlüssels anzeigen

gpg2 --fingerprint hans@wurst.de

oder

gpg2 --fingerprint A54990CD22BE7444

oder

gpg2 --fingerprint 1BCE0D11319D8201D30B57A9A54990CD22BE7444
pub   rsa4096 2024-01-05 [SC] [verfällt: 2025-01-06]
      1BCE 0D11 319D 8201 D30B  57A9 A549 90CD 22BE 7444
uid        [ ultimativ ] Hans Wurst <hans@wurst.de>
sub   rsa4096 2024-01-05 [E] [verfällt: 2025-01-06]

Hochladen des Schlüssels auf einen / mehrere Keyserver

gpg2 --keyserver hkps://keyserver.ubuntu.com --send-key A54990CD22BE7444
gpg2 --keyserver hkps://pgp.surfnet.nl --send-key A54990CD22BE7444
gpg2 --keyserver hkps://keys.openpgp.org --send-key A54990CD22BE7444
gpg2 --keyserver https://keys.mailvelope.com --send-key A54990CD22BE7444

Inhalt eines Schlüssels anzeigen

gpg2 --export-secret-keys --armor A54990CD22BE7444 | gpg2 --list-packets
# off=0 ctb=95 tag=5 hlen=3 plen=1816
:secret key packet:
    version 4, algo 1, created 1704476847, expires 0
    pkey[0]: [4096 bits]
    pkey[1]: [17 bits]
    skey[2]: [4094 bits]
    skey[3]: [2048 bits]
    skey[4]: [2048 bits]
    skey[5]: [2047 bits]
    checksum: 7930
    keyid: A54990CD22BE7444
# off=1819 ctb=b4 tag=13 hlen=2 plen=26
:user ID packet: "Hans Wurst <hans@wurst.de>"
# off=1847 ctb=89 tag=2 hlen=3 plen=599
:signature packet: algo 1, keyid A54990CD22BE7444
    version 4, created 1704476847, md5len 0, sigclass 0x13
    digest algo 8, begin of digest 8f 4a
    hashed subpkt 33 len 21 (issuer fpr v4 1BCE0D11319D8201D30B57A9A54990CD22BE7444)
    hashed subpkt 2 len 4 (sig created 2024-01-05)
    hashed subpkt 27 len 1 (key flags: 03)
    hashed subpkt 9 len 4 (key expires after 1y1d17h12m)
    hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 2)
    hashed subpkt 34 len 1 (pref-aead-algos: 2)
    hashed subpkt 21 len 5 (pref-hash-algos: 10 9 8 11 2)
    hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
    hashed subpkt 30 len 1 (features: 07)
    hashed subpkt 23 len 1 (keyserver preferences: 80)
    subpkt 16 len 8 (issuer key ID A54990CD22BE7444)
    data: [4096 bits]
# off=2449 ctb=9d tag=7 hlen=3 plen=1816
:secret sub key packet:
    version 4, algo 1, created 1704476847, expires 0
    pkey[0]: [4096 bits]
    pkey[1]: [17 bits]
    skey[2]: [4095 bits]
    skey[3]: [2048 bits]
    skey[4]: [2048 bits]
    skey[5]: [2045 bits]
    checksum: 7a38
    keyid: E3CF74E622FFA08E
# off=4268 ctb=89 tag=2 hlen=3 plen=572
:signature packet: algo 1, keyid A54990CD22BE7444
    version 4, created 1704476847, md5len 0, sigclass 0x18
    digest algo 8, begin of digest b4 b0
    hashed subpkt 33 len 21 (issuer fpr v4 1BCE0D11319D8201D30B57A9A54990CD22BE7444)
    hashed subpkt 2 len 4 (sig created 2024-01-05)
    hashed subpkt 27 len 1 (key flags: 0C)
    hashed subpkt 9 len 4 (key expires after 1y1d17h12m)
    subpkt 16 len 8 (issuer key ID A54990CD22BE7444)
    data: [4092 bits]

Öffentlichen Schlüssel in Textform exportieren

gpg2 --armor --export hans@wurst.de > ~/gpg-pubkey.asc

oder

gpg2 --armor --export A54990CD22BE7444 > ~/gpg-pubkey.asc

oder

gpg2 --armor --export 1BCE0D11319D8201D30B57A9A54990CD22BE7444 > ~/gpg-pubkey.asc

Privaten Schlüssel in Textform exportieren

VORSICHT
Mit dieser Funktion exportierst du den privaten Schlüssel als Datei auf deinen PC. Jede:r, der:die in den Besitz dieser Datei bzw. deren Inhalt kommt, braucht nur noch das Passwort, mit dem der Schlüssel gesichert ist, zu knacken um anschließend deine Identität zu übernehmen. Sei bei diesem Schritt und mit der exportierten Datei sehr sehr achtsam und lösche Sie umgehend, wenn du sie nicht mehr benötigst!

gpg2 --export-secret-keys --armor hans@wurst.de > ~/gpg-privkey.asc

oder

gpg2 --export-secret-keys --armor A54990CD22BE7444 > ~/gpg-privkey.asc

oder

gpg2 --export-secret-keys --armor 1BCE0D11319D8201D30B57A9A54990CD22BE7444 > ~/gpg-privkey.asc

Einen Schlüssel auf der Kommandozeile bearbeiten

gpg2 --edit-key 1BCE0D11319D8201D30B57A9A54990CD22BE7444
* * *

Ich möchte mit OpenPGP arbeiten, habe dabei aber Schwierigkeiten

Ich unterstütze dich gerne beim Anlegen / Bearbeiten von Schlüsselpaaren, Unterschlüsseln, dem Ändern des Ablaufdatums und allen weiteren Konfigurationen.
Schreib mir hierzu einfach über Kontakt, per Telegram oder unten in die Kommentare eine Nachricht.

* * *
* * *

Änderungshistorie

11.01.2024, 00:30 – Artikel erweitert und veröffentlicht
06.01.2024, 03:00 – Artikel erstellt

* * *
Christian Süßenguth Christian Süßenguth @sweetgood

Hi, ich bin Christian und Inhaber der Firma SWEETGOOD. Mit dem andersGOOD Blog möchte ich auch dich für datensichere IT-Lösungen begeistern. So bringst du dein Unternehmen voran, ohne großen Konzernen deine wertvollen Daten zu liefern. Probiers mal anders!


Kommentarbereich

Die Kommentare sind für dich noch deaktiviert, da du dem Setzen von Cookies bisher nicht zugestimmt hast.
Klicke oben rechts auf "Ja, klar!" und lade die Seite neu, um die Kommentare anzuzeigen.

Seite neu laden

👾 Magst du Kekse?

Ich würde gerne Cookies setzen

Ist das OK für dich?