OpenPGP Keys mit Sequoia

Dieser Artikel behandelt, was der OpenPGP Standard ist, und was er nicht ist. Danach bietet er ein paar Beispiele wie er genutzt werden kann.

Falls Sie nur für den praktischen Teil hier sind, springen Sie gern dorthin vor.

Was ist OpenPGP (nicht)?

Open Pretty Good Privacy (OpenPGP) ist ein offener Standard für mehrere Dateiformate im Kontext der Kryptografie. Seine bekannteste Anwendung ist die für Ende-zu-Ende Verschlüsselung von Emails, aber er kann auch genutzt werden, um beliebige Daten, auch andere OpenPGP Dateien, kryptografisch zu signieren.

Für den Fall, dass das Konzept von Signaturen Ihnen neu ist, befindet sich weiter unten ein oberflächliche Beschreibung.

Die erste Version des Standards stammt aus dem Jahre 1998 , die aktuellste (zum Zeitpunkt des Schreibens) Version 6 / RFC 9580 von 2024. Ein weiterer Meilenstein, welcher in diesem Artikel noch relevant werden wird, ist Version 4 / RFC 4880 von 2007.

Während seiner Lebenszeit wurde OpenPGP von vielen Personen und Produkten adaptiert, vor allem in der Cybersecurity Community, denn es ist ganz schön gut. Ebenfalls während und vor diesem Zeitraum wurden viele nah verwandte und nicht ganz optimal benannte Konzepte und Produkte entwickelt, was ganz schön verwirrend sein kann.

Um eine Idee davon zu bekommen, was OpenPGP ist, ist es vielleicht am besten, es mit dem zu vergleichen, was es nicht ist.

OpenPGP vs. RSA

RSA ist ein mathematischer Algorithmus für asymetrische Verschlüsselung. Es spezifiziert, wie ein öffentlicher und geheimer Schlüssel auszusehen haben, und wie sie genutzt werden können, um Daten zu verschlüsseln, zu entschlüsseln, zu signieren und zu verifizieren.

Es gibt mehrere solcher Algorithmen, aber RSA war für lange Zeit der am meisten genutzte, und ist es vermutlich noch immer.

OpenPGP auf der anderen Seite ist eine Abstraktion. Es ist möglichst Algorithmus-agnostisch designt, was bedeutet dass Sie die meiste Zeit gar nicht wissen müssen, welcher Algorithmus während einer Operation genutzt wird. Der Standard von 2024 enthält noch keine Unterstützung für Post-Quanten Verschlüsselungsalgorithmen, aber das deutsche Bundesamt für Sicherheit in der Informationstechnik (BSI) hat vor, dies mit einer zukünftigen Version zu ändern.

OpenPGP vs. PGP

OpenPGP ist ein Standard, also eine Reihe formaler Regeln, die ein Programm befolgen muss, um mit anderen Programmen desselben Standards kompatibel zu sein.

PGP ist ein solches Programm, welches den OpenPGP-Standard implementiert. Es ist sogar das erste Programm, welches den Standard implementiert, da es 1991 veröffentlicht wurde und damit sieben Jahre älter als OpenPGP ist. Der offene Standard wurde von PGP abgeleitet und nicht umgekehrt.

Als kommerzielles Programm hat PGP mehrmals den Eigentümer gewechselt und wird derzeit von Broadcom weiterentwickelt.

OpenPGP vs. GPG

GNU Privacy Guard (GPG) ist ein weiteres Programm, welches den OpenPGP-Standard implementiert. Im Gegensatz zum kommerziellen PGP-Programm wird es unter einer freien GNU General Public License vertrieben. Die Entwickler haben diskutiert , ob der Name zu sehr an PGP erinnert, und sind zu dem Schluss gekommen, dass dies nicht der Fall sei. Da GPG eine freie Software ist, steht Ihnen frei anderer Meinung sein.

Genauer gesagt ist GPG ein Programm, welches LibrePGP und OpenPGP Version 4 / RFC 4880 implementiert, aber nicht die aktuellere Version 6 / RFC 9580 .

OpenPGP vs. LibrePGP

Im Jahr 2023, als Version 6 / RFC 9580 des OpenPGP-Standards Version 4 / RFC 4880 aus dem Jahr 2007 ersetzen sollte, haben mehrere Personen die vorgeschlagenen Änderungen als zu disruptiv empfunden. Insbesondere die Entwickler von GPG und RNP (einer Erweiterung für Thunderbird) haben sich entschieden , den aktuelleren Standard nicht zu übernehmen und stattdessen den neuen, konkurrierenden Standard LibrePGP basierend auf OpenPGP Version 4 zu entwickeln.

Da GPG und seine Windows-Variante Gpg4win so weit verbreitet sind, ist es (zum Zeitpunkt der Erstellung dieses Artikels, Juli 2025) wahrscheinlich ratsam, den letzten gemeinsamen Vorgänger, Version 4 / RFC 4880, zu verwenden, bis beide Standards allgemein unterstützt werden.

OpenPGP vs. S/MIME

Secure Multipurpose Internet Mail Extensions (S/MIME) ist wie OpenPGP ein Standard, der primär auf die Ende-zu-Ende-Verschlüsselung von E-Mails abzielt. Die beiden Standards verfügen über ähnliche Funktionen, sind aber nicht interoperabel.

Der wichtigste konzeptionelle Unterschied zwischen S/MIME und OpenPGP liegt in der Beantwortung der Frage: „Kann ich diesem öffentlichen Schlüssel vertrauen?“

S/MIME basiert auf X.509-Zertifikaten , die eine „Vertrauenskette“ bilden. Den Anfang dieser Kette bildet eine zentrale Zertifizierungsstelle, die mit einem auf Ihrem Computer gespeicherten öffentlichen Schlüssel verknüpft ist. Diese Zertifizierungsstelle signiert andere Zertifikate (in der Regel gegen Bezahlung und Vorlage eines Ausweises) und signalisiert Ihrem Computer damit, dass er ihnen vertraut. Da Ihr Computer der Zertifizierungsstelle vertraut, vertraut er auch diesen signierten Zertifikaten.

OpenPGP hingegen nutzt ein „Vertrauensnetz“. Jeder kann die Authentizität anderer bestätigen. Wenn genügend Personen, denen Ihr Computer vertraut, ein bestimmtes Zertifikat signiert haben, kann Ihr Computer entscheiden, diesem Zertifikat ebenfalls zu vertrauen.

Im Kontext der E-Mail-Verschlüsselung ist S/MIME eine absolut valide Alternative zu OpenPGP, insbesondere für Unternehmen. BOMnipotent benötigt jedoch OpenPGP-Schlüssel.

OpenPGP nutzen

Zur Verwaltung von OpenPGP-Schlüsseln empfiehlt diese Anleitung die Verwendung des Kommandozeilentools Sequoia-PGP . Es handelt sich um eine kommerziell unterstützte Open-Source-Implementierung des OpenPGP-Standards. Das bedeutet, dass die Pflege des Projekts finanziell motiviert ist und der Code gleichzeitig von Sicherheitsforschenden eingesehen werden kann. Das Programm ist zudem sehr gut dokumentiert .

Installieren

Aus einem Repository

Die Sequoia-PGP-Dokumentation bietet verschiedene Möglichkeiten zur Installation des Programms auf verschiedenen Plattformen. Windows wird jedoch nicht direkt unterstützt. Stattdessen wird die Verwendung des Windows-Subsystems für Linux (WSL) empfohlen, das sich erfreulicherweise einfach aufsetzen lässt.

Aus dem Quellcode (Debian 12 und früher)

Regelmäßige Debian-Nutzer werden nicht überrascht sein, dass die Programmversion im Repository mehrere Jahre zurückliegen kann. Diese Anleitung basiert auf Sequoia-PGP Version 1.3.1, die mit Debian 13 “Trixie” ausgeliefert wird. Wenn Sie sich nicht sicher sind, welche Version Ihr Repository enthält, führen Sie Folgendes aus:

apt-cache policy sq

sq:
  Installed: (none)
  Candidate: 0.27.0-2+b1
  Version table:
     0.27.0-2+b1 500
        500 http://deb.debian.org/debian bookworm/main amd64 Packages

Für Debian 12 ergibt dies etwa “0.27.0”. In diesem Fall wird empfohlen, stattdessen die Schritte zum Bauen des Programms aus den Quellen zu befolgen (oder auf ein neueres Betriebssystem zu aktualisieren). Dies erfordert die Rust-Toolchain. Glücklicherweise ist die Installation auch erfreulich unkompliziert .

Windows-Nutzer, denken Sie daran die Linux-Installation innerhalb des WSL auszuführen.

Anschließend müssen Sie einige Systembibliotheken wie in der Anleitung beschrieben installieren, da Sequoia-PGP nicht in reinem Rust geschrieben ist (weshalb es nicht mit Windows kompatibel ist):

sudo apt install -y clang nettle-dev pkg-config libssl-dev capnproto libsqlite3-dev

Führen Sie abschließend den Befehl aus:

cargo install --locked sequoia-sq

Dadurch wird Sequoia-PGP gebaut und der Befehl “sq” in Ihrem Terminal verfügbar.

Schlüssel generieren

Nach der Installation von Sequoia-PGP können Sie mit folgendem Befehl einen neuen Schlüssel generieren:

sq key generate --shared-key --name "Your Name" --email info@example.com --profile rfc4880

Der Befehl fordert Sie zur Eingabe eines Passworts auf. Wenn Sie dieses leer lassen, ist die Datei unverschlüsselt.

Dadurch wird die Datei direkt Ihrem Schlüsselspeicher hinzugefügt, sodass Sequoia-PGP sie kennt. Der Schlüsselspeicher ist spezifisch für Sequoia-PGP, und unterscheidet sich leicht vom (betriebssystemweiten) Schlüsselbund.

Der Parameter “shared-key” teilt dem Programm mit, dass Sie diesem Schlüssel nicht die höchste Vertrauensstufe einräumen. Der andere mögliche Parameter ist “own-key”, was bedeutet, dass Sie ihm voll vertrauen. Einer der beiden muss im Befehl enthalten sein.

Die Parameter “name” und “email” dienen der Identifizierung des Schlüsselinhabers. Dies zeigt nicht nur anderen, wem dieser Schlüssel gehört, sondern erleichtert Ihnen auch die Interaktion mit Ihren Schlüsseln.

Die Option “profile” mit dem Wert “rfc4880” weist Sequoia-PGP an, Version 4 / RFC 4880 des OpenPGP-Standards zu verwenden. Dies entspricht zwar nicht dem neuesten Standard, stellt aber sicher, dass die Schlüssel mit Tools wie GPG kompatibel sind, die OpenPGP Version 6 / RFC 9580 weder unterstützen noch unterstützen werden.

Weitere Optionen finden Sie in der Dokumentation oder durch Aufruf von:

sq key generate --help

Sie können alle Ihre Schlüssel mit folgendem Befehl auflisten:

sq key list

Schlüssel exportieren

Öffentliche Schlüssel

Um einen öffentlichen Schlüssel (ein “Zertifikat”) aus Ihrem Schlüsselspeicher zu exportieren, rufen Sie Folgendes auf:

sq cert export --cert-email info@example.com --output=/home/example.cert

Dieser Befehl nutzt die Tatsache, dass Sie beim Generieren des Schlüssels eine E-Mail-Adresse angegeben haben. Andernfalls müssten Sie den Footprint herausfinden und verwenden, um den zu exportierenden öffentlichen Schlüssel zu identifizieren.

Ohne die Option “output” wird der Schlüssel einfach in der Standard-Ausgabe wiedergegeben.

Sie können diese Datei nun beispielsweise im Stammverzeichnis Ihres Servers hosten und im Bereich “encryption” Ihrer security.txt darauf verweisen.

Geheime Schlüssel

Damit BOMnipotent Dokumente für Sie signieren kann, müssen Sie außerdem Ihren geheimen Schlüssel exportieren:

sq key export --cert-email info@example.com --output=/home/example_secret.key

Diese Datei kann natürlich nicht frei weitergegeben werden, sondern sollte wie ein Passwort behandelt werden.

Signaturen

Grundlegendes Prinzip

Eine Signatur ist ein Objekt (man denke an eine Zeichenfolge, einige Bytes oder eine große Zahl), welches bestätigt, dass bestimmte Daten (eine E-Mail, eine Textdatei, ein Programm) von jemandem (dem Unterzeichner) im aktuellen Zustand freigegeben wurden. Wenn Sie dem Unterzeichner vertrauen und die Signatur überprüfen, können Sie sicher sein, dass die Daten nicht manipuliert wurden. Der gesamte Prozess funktioniert im Wesentlichen folgendermaßen:

1. Der Unterzeichner berechnet ein kryptografisches Hash der Daten. Ein Hash kann als lange Zeichenfolge betrachtet werden, die sich bei nur geringfügig abweichenden Dateneingaben stark unterscheidet.
2. Der Unterzeichner verschlüsselt dieses Hash mit dem geheimen Schlüssel so, dass es mit dem öffentlichen Schlüssel entschlüsselt werden kann. Das Ergebnis ist die Signatur. Beachten Sie, dass die Verwendung der Schlüssel hier genau gegenteilig zur typischen asymmetrischen Verschlüsselung ist.
3. Der Prüfer entschlüsselt die Signatur mit dem öffentlichen Schlüssel des Unterzeichners. Das Ergebnis ist das Hash. Der Prüfer weiß nun, dass das Hash vom Unterzeichner stammt, da nur dieser den geheimen Schlüssel besitzt, um eine Zeichenfolge so zu verschlüsseln, dass der öffentliche Schlüssel sie entschlüsseln kann.
4. Der Prüfer berechnet das Hash nun weiterhin selbstständig aus den Daten. Stimmt der Wert mit dem des Unterzeichners überein, weiß er, dass die Daten nicht verändert wurden.

Signaturen können entweder inline sein, werden also direkt an die zu signierenden Daten angehängt, oder sie können in einer separaten Signaturdatei vorliegen, wenn die Originaldaten das Anhängen einer Signatur nicht zulassen. Sequoia-PGP kann beide Fälle verarbeiten.

Cleartext vs. Message

Für Inline-Signaturen erkennt OpenPGP (und damit auch Sequoia-PGP) die Varianten “cleartext” (“Klartext”) und “mesage” (“Nachricht”).

Inline-signierte “cleartext” Daten sind in ihrer ursprünglichen Form in der Ausgabe enthalten. Die resultierende Struktur ist:

-----BEGIN PGP SIGNED MESSAGE-----
[Originaldaten]
-----BEGIN PGP SIGNATURE-----
[Signatur in Base64]
-----END PGP SIGNATURE-----

Dies ist nützlich, falls die Originaldaten von Menschen lesbar sind, und wird beispielsweise beim Signieren einer Security.txt empfohlen.

Bei der Variante “message” werden die Daten stattdessen in Base64 kodiert und mit der Signatur kombiniert. Die Ausgabe sieht dann folgendermaßen aus:

-----BEGIN PGP MESSAGE-----
[Daten und Signatur in Base64]
-----END PGP MESSAGE-----

Diese Variante ist kompakter, ein Mensch kann die Originaldaten jedoch vor der Dekodierung nicht mehr lesen.

Daten signieren

Um eine Inline-Signatur von (beispielsweise) einer Textdatei zu erstellen, rufen Sie Folgendes auf:

sq sign /home/message.txt --signer-file=/home/example_secret.key --output=/home/signed_message.txt --cleartext

Damit signiert Sequoia-PGP den Inhalt von “message.txt” mit dem geheimen Schlüssel in “example_secret.key” und speichert das Ergebnis in “signed_message.txt”.

Der Parameter “cleartext” gibt an, dass die Originaldaten in ihrer ursprünglichen Form in die Ausgabe übernommen werden (siehe oben ).

Wenn Sie die Daten nicht in die Ausgabe aufnehmen, sondern eine separate Signaturdatei erstellen möchten, rufen Sie Folgendes auf:

sq sign /home/message.txt --signer-file=/home/example_secret.key --signature-file=/home/signature.asc

Die Dokumentation enthält weitere Varianten zur Signaturerstellung.

Signaturen verifizieren

Die Überprüfung einer separaten Signaturdatei ist recht einfach:

sq verify /home/message.txt --signature-file=/home/signature.asc --signer-file=/home/example.cert

Authenticated signature made by DABBAD00DABBAD00DABBAD00DABBAD00DABBAD00 (Your Name)

1 authenticated signature.

Dieser Befehl gibt die Datei mit der Originalnachricht, die zugehörige Signaturdatei und den öffentlichen Schlüssel des Unterzeichners an.

Die Überprüfung einer Inline-Signatur funktioniert ähnlich:

sq verify /home/signed_message.txt --cleartext --signer-file=/home/example.cert

Authenticated signature made by DABBAD00DABBAD00DABBAD00DABBAD00DABBAD00 (Your Name)

1 authenticated signature.
[Your Message]

Die Option “cleartext” teilt Sequoia-PGP mit, dass die Datei signed_message.txt die Originalnachricht im Klartext enthält (siehe oben ).

Falls Ihre Annahme bezüglich des Formats falsch ist, erkennt Sequoia-PGP dies und korrigiert es für Sie. Warum wird der Parameter überhaupt benötigt, wenn alle Informationen bereits in der Nachricht gespeichert sind? Wahrscheinlich aus historischen Gründen.

Der Befehl gibt die Originalmeldung auf die Standardausgabe und die Auswertung (Signatur ist gültig / ungültig) auf die Standardfehlerausgabe aus. Wenn Sie nur die Auswertung benötigen, fügen Sie dem obigen Befehl " > /dev/null" hinzu, um die Standardausgabe zu ignorieren.