Responsible Disclosure braucht Verantwortung: Einordnung aktueller Sicherheitsmeldungen zu GnuPG

Veröffentlicht am 22. Januar 2026 von Alexander Kulbartsch, Meik Michalke

In einem Vortrag auf dem 39. Chaos Communication Congress (39C3) wurden mehrere Beobachtungen zu Signaturprüfungen in GnuPG vorgestellt. Diese Beobachtungen sind auf der begleitenden Website gpg.fail dokumentiert.

Die gewählte Form der Darstellung vermittelt den Eindruck, GnuPG sei von gravierenden Sicherheitsproblemen betroffen und wir würden unserer Verantwortung als Maintainer nicht gerecht.

Tatsächlich haben wir jede der gemeldeten Beobachtungen sorgfältig geprüft und den beteiligten Sicherheitsforscher:innen zeitnah Rückmeldung gegeben. Ein konstruktiver fachlicher Austausch kam dabei jedoch nicht zustande.

Öffentliche Darstellung und technische Einordnung

Nach der Veröffentlichung des Vortrags erreichten uns viele Rückfragen: Ist GnuPG noch sicher? Kann die Software weiterhin eingesetzt werden?

Die kurze Antwort lautet: ja.

In diesem Beitrag erläutern wir die veröffentlichten Beobachtungen und ihren technischen Hintergrund. Wir zeigen, welche davon tatsächliche Programmfehler waren und welche nicht.

Programmfehler haben wir bereits im Oktober und November 2025 behoben. Andere Beobachtungen betreffen bekannte Eigenschaften der Software oder bewusste Designentscheidungen. Warum wir diese nicht geändert haben, erläutern wir im Abschnitt Warum nicht jede Sicherheitsmeldung zu einem Fix führt.

Verantwortung der Maintainer: Sicherheit, Stabilität und Verhältnismäßigkeit

Als Maintainer von GnuPG entscheiden wir fortlaufend, wie die Software weiterentwickelt wird. Diese Verantwortung geht über die Pflege einer über Jahrzehnte gewachsenen Codebasis hinaus. Sie umfasst sowohl die Weiterentwicklung der Software als auch den Umgang mit Anforderungen aus der Community und von Kund:innen.

Ebenso müssen wir sicherstellen, dass GnuPG zuverlässig und stabil bleibt. Die Software wird in sicherheitskritischen, mitunter sogar lebenswichtigen Kontexten eingesetzt.

Ein weiterer zentraler Aspekt ist die Abwärtskompatibilität. GnuPG muss mit früheren Versionen ebenso zusammenarbeiten wie mit Softwareprodukten, die seit vielen Jahren auf GnuPG aufbauen oder es als Ersatz verwenden.

Sichere Nutzung von GnuPG erfordert Fachwissen und Verantwortungsbewusstsein

Hinweis: GnuPG besteht aus mehreren Werkzeugen. Ob die Nutzung sicher ist, hängt davon ab, wie sie eingesetzt werden. Wer mit GnuPG arbeitet, sollte grundlegende Sicherheitskonzepte verstehen.

GnuPG kann auch auf eine Weise eingesetzt werden, die riskant sein kann. Das liegt nicht am Code, sondern an Fehlbedienung oder falschen Annahmen darüber, was tatsächlich geprüft oder abgesichert wird.

Verantwortung endet daher nicht beim Programmcode. Sie betrifft auch den bewussten und informierten Umgang mit den Werkzeugen. Ein sicherer Einsatz erfordert entsprechend geschulte Nutzer:innen.

Warum nicht jede Sicherheitsmeldung zu einem Fix führt

Nicht jede Sicherheitsmeldung führt zu einer Änderung am Code. In diesem Abschnitt erklären wir, warum das so ist und in welchen Fällen wir uns bewusst gegen eine Anpassung entscheiden.

Warum sich das Userinterface von GnuPG selten ändert

GnuPG wird seit vielen Jahren so entwickelt, dass es auch mit älteren Versionen zusammenarbeitet. Diese Abwärtskompatibilität reicht bis zu PGP zurück, das bereits 1991 veröffentlicht wurde.

Änderungen am Verhalten der gpg-Kommandozeile haben direkte Folgen. Dazu gehören zum Beispiel andere Standardwerte oder veränderte Ein- und Ausgabeformate. Solche Änderungen können bestehende Abläufe stören oder automatisierte Prozesse zum Stillstand bringen.

Das betrifft nicht nur aktuelle Open-Source-Projekte. Auch viele proprietäre und interne Systeme setzen gpg seit Jahrzehnten produktiv ein. Sie sind darauf angewiesen, dass sich das Verhalten nicht ändert.

Deshalb vermeiden wir Änderungen am Userinterface, wann immer es möglich ist. Wir folgen damit der Linux-Philosophie Don't break user space. Bestehende Benutzerumgebungen sollen durch inkompatible Änderungen am Userinterface nicht beeinträchtigt oder unbrauchbar werden.

Cleartext-Signaturen: bekannte Einschränkungen und empfohlene Nutzung

Cleartext-Signaturen werden aus historischen Gründen bis heute in vielen kritischen Systemen eingesetzt. Wir gehen davon aus, dass sie in der Praxis meist korrekt verwendet werden.

Gleichzeitig haben Cleartext-Signaturen seit jeher technische Einschränkungen. Aus heutiger Sicht gelten sie deshalb als problematisch. Wir empfehlen grundsätzlich, auf ihre Verwendung zu verzichten.

Lässt sich der Einsatz von Cleartext-Signaturen nicht vermeiden, sollte zumindest die Option --output verwendet werden. So wird sichergestellt, dass nur der tatsächlich signierte Inhalt weiterverarbeitet wird.

Weiterführende Informationen: Eine ausführliche technische Einordnung zu Cleartext-Signaturen finden Sie im Blogbeitrag: https://www.gnupg.org/blog/20251226-cleartext-signatures.html

Social Engineering: Grenzen technischer Schutzmaßnahmen

Ein weiteres Angriffsszenario zielt darauf ab, Nutzer:innen dazu zu bringen, schädliche Befehle selbst auszuführen. Dabei handelt es sich nicht um ein technisches Problem, sondern um Social Engineering. Vergleichbar ist dies mit bekannten „Tipps“ aus Foren, etwa sudo rm -rf / einzugeben, um ein System angeblich zu „beschleunigen“. (Bitte nicht ausprobieren!)

Ähnlich funktioniert es, wenn Nutzer:innen dazu verleitet werden, einen manipulierten Keyring zu importieren, anstatt die vorgesehenen Befehle gpg --import oder gpg --export zu verwenden.

Solche Social-Engineering-Angriffe lassen sich nicht allein durch technische Maßnahmen verhindern. Wirksam eindämmen lassen sie sich nur durch Aufklärung über Risiken und typische Vorgehensweisen.

Hinweis (nicht nur für GnuPG): Kopieren Sie niemals Befehle aus dem Internet in Ihre Kommandozeile, solange Sie diese nicht vollständig verstanden haben. Es gibt kein Werkzeug, das Sie davor schützen kann, wenn Sie dies dennoch tun.

Unerfahrenen Nutzer:innen empfehlen wir, unsere grafische Anwendung Kleopatra für die Verwaltung von Zertifikaten und kryptografischen Diensten zu verwenden. Sie reduziert typische Fehlbedienungen und bietet wirksamen Schutz vor vielen dieser Angriffsszenarien.

Einordnung der im Vortrag erhobenen Kritikpunkte

Im Vortrag wurden mehrere Beobachtungen zu GnuPG genannt. Nur ein kleiner Teil davon betraf tatsächliche Programmfehler. Diese haben wir behoben.

In allen anderen Fällen haben wir den Code bewusst nicht geändert. Die Beobachtungen betreffen bekannte Nutzungsrisiken, insbesondere Social Engineering in Verbindung mit Cleartext-Signaturen. Die vorgeschlagenen Gegenmaßnahmen zielen auf Änderungen am Userinterface ab, die wir aus Gründen der Abwärtskompatibilität nicht umsetzen.

Zusammenfassung: Wir haben einen Programmfehler mit einem nicht ausnutzbaren 1-Byte-Speicherüberlauf sowie zwei weitere Fehler behoben. Keiner dieser Fehler stellte eine in der Praxis ausnutzbare Sicherheitslücke dar.

Alle weiteren Meldungen betreffen kein Fehlverhalten im Code, sondern Social Engineering, meist in Verbindung mit einer unterlassenen Prüfung der signierten Daten.

Die folgende Darstellung folgt der Reihenfolge im Vortrag. Die einzelnen Punkte lassen sich durch Klick auf die jeweilige Überschrift ein- und ausklappen.

▶ Nr. 1: Multiple Plaintext Attack on Detached PGP Signatures in GnuPG (detached)

Unser Ticket: https://dev.gnupg.org/T7903
Status: behoben am 22. Oktober 2025
Beschreibung: Ein Angreifer kann zusätzlichen Klartext in eine sogenannte detached signature einfügen. Wird diese anschließend mit gpg --decrypt verarbeitet, kann der eingefügte Klartext angezeigt werden. Nutzer:innen könnten dadurch getäuscht oder zumindest verwirrt werden.
Voraussetzung: Damit dieses Szenario greift, müssen Anwender:innen dazu gebracht werden, die Signatur nicht wie vorgesehen zu prüfen, sondern sie stattdessen zu entschlüsseln.
Einordnung: Bei korrekt erstellten und unveränderten detached Signaturen erzeugt der Befehl gpg --verify keinerlei Ausgabe des signierten Inhalts. Detached Signaturen enthalten keine Nutzdaten, sondern dienen ausschließlich der Prüfung der Signatur selbst. Eine Anzeige von Klartext ist in diesem Fall daher nicht möglich bzw. sinnvoll.

▶ Nr. 2: GnuPG Accepts Path Separators and Path Traversals in Literal Data "Filename" Field (filename)

Unser Ticket: https://dev.gnupg.org/T7908
Status: kein Programmfehler (Social Engineering und notwendige Änderungen am Userinterface, siehe Hinweis oben)
Beschreibung: Im PGP-Kompatibilitätsmodus, ohne explizite Angabe eines Befehls, kann ein Dateiname aus dem Literal-Data-Feld übernommen werden. Aus diesem Grund wird seit jeher empfohlen, gpg mit einem expliziten Befehl aufzurufen und dabei einen Zieldateinamen anzugeben.
Voraussetzung: Anwender:innen müssen dazu gebracht werden, sich auf den vorgeschlagenen Dateinamen zu verlassen.
Einordnung: Der im Literal-Data-Feld enthaltene Dateiname stellt lediglich einen Vorschlag dar. Er ist keine zwingende Vorgabe und ersetzt nicht die explizite Festlegung eines Zieldateinamens durch die Nutzer:innen.

Ursprünglich speicherte PGP Dateien automatisch unter dem im Literal-Data-Feld angegebenen Namen und überschieb dabei gegebenenfalls bereits vorhandene Dateien. Dieses Verhalten konnte zu Sicherheitsproblemen führen.

GnuPG hat dieses Verhalten bewusst geändert. Wird gpg ohne expliziten Befehl oder Zieldateinamen aufgerufen, erfolgt kein automatisches Überschreiben bestehender Dateien. Stattdessen fragt GnuPG aktiv nach, ob eine vorhandene Datei ersetzt werden soll:

File 'test.txt' exists. Overwrite? (y/N)

Die Voreinstellung ist hierbei ausdrücklich „N“ für „Nein“. Wird die Eingabe bestätigt oder „N“ gewählt, fordert GnuPG zur Angabe eines neuen Dateinamens auf. Ein unbeabsichtigtes Überschreiben wird so verhindert.

Unabhängig davon gilt: In älteren OpenPGP-Spezifikationen war der Dateiname nicht Bestandteil der Signatur. In der aktuellen LibrePGP-Spezifikation wird der Dateiname hingegen mit signiert – ein Verhalten, das von GnuPG selbstverständlich unterstützt wird. Auch in diesem Fall handelt es sich jedoch weiterhin um einen Vorschlag für einen Dateinamen, nicht um eine verbindliche Anweisung.

Aus diesem Grund empfehlen wir weiterhin, gpg stets mit einem konkreten Befehl (zum Beispiel --decrypt) aufzurufen und den gewünschten Zieldateinamen explizit anzugeben.

▶ Nr. 3: Cleartext Signature Plaintext Truncated for Hash Calculation (formfeed)

Unser Ticket: https://dev.gnupg.org/T7909
Status: kein Programmfehler (Social Engineering, falsche Nutzung von Cleartext-Signaturen und notwendige Änderungen am Userinterface, siehe Hinweis oben)
Beschreibung: In diesem Punkt wurde beschrieben, dass bei Cleartext-Signaturen der für die Hash-Berechnung herangezogene Klartext von dem mit einfachen Werkzeugen wie cat angezeigten Text abweichen kann. Der mit gpg --output ausgegebene Inhalt entspricht dabei weiterhin dem tatsächlich signierten Klartext.
Voraussetzung: Nutzer:innen verlassen sich auf die Anzeige des Klartexts mit cat und prüfen nicht den tatsächlich signierten Inhalt.
Einordnung: Die Signaturprüfung selbst ist korrekt. Die beschriebene Abweichung entsteht ausschließlich dann, wenn der angezeigte Klartext nicht mit dem signierten Inhalt abgeglichen wird.

Sich allein auf die Ausgabe von cat zu verlassen, ist grundsätzlich unsicher. cat zeigt nicht immer alles an, was tatsächlich in Dateien enthalten ist. Schon die Verwendung von cat -v hätte sichtbar gemacht, dass zusätzliche Steuerzeichen enthalten sind und der angezeigte Text nicht dem tatsächlichen Inhalt entspricht.

Die empfohlene Nutzung von gpg --output hätte dieses Szenario zuverlässig verhindert (siehe oben).

▶ Nr. 4: Encrypted Message Malleability Checks Are Incorrectly Enforced Causing Plaintext Recovery Attacks (malleability)

Unser Ticket: https://dev.gnupg.org/T7907
Status: kein Programmfehler (Social Engineering, falsche Nutzung von Cleartext-Signaturen und notwendige Änderungen am Userinterface, siehe Hinweis oben)
Kurzfassung: Nutzer:innen müssen eine von gpg ausgegebene Fehlermeldung („decryption failed“) ignorieren und anschließend dennoch mit der ausgegebenen Datenmenge weiterarbeiten oder diese signieren.
Beschreibung: Es wird behauptet, ein Angreifer könne manipulierte verschlüsselte Nachrichten so gestalten, dass trotz eines Entschlüsselungsfehlers verwertbarer Klartext ausgegeben werde.
Voraussetzung: Empfänger:innen ignorieren eine explizite Fehlermeldung von gpg und arbeiten dennoch mit den ausgegebenen Daten weiter.
Einordnung: Unter diesen Voraussetzungen liegt kein Programmfehler vor.

1. Behauptung laut gpg.fail

In the interest of a timely disclosure, we cannot provide an refined end-to-end demonstration of the issue. However, under the following assumptions we can demonstrate relevant parts of the attack. In combination with the buggy code pointed out above, we believe that there is sufficient risk of a serious vulnerability to warrant investigation and fixes by GnuPG maintainers.

We assume that:

We have access to the encrypted data

The encrypted data is exactly 64 bytes of total entropy

Bob uses GnuPG 2.4.8

Bob has no non-standard config and uses head -c64 /dev/urandom | gpg -e -r online to encrypt his data

Deutsche Übersetzung:

Im Interesse einer zeitnahen Veröffentlichung können wir keine vollständige End-to-End-Demonstration des Problems liefern. Unter den folgenden Annahmen können wir jedoch relevante Teile des Angriffs demonstrieren.

Wir gehen davon aus, dass:

Zugriff auf die verschlüsselten Daten besteht,

die verschlüsselten Daten exakt 64 Byte Entropie enthalten,

Bob GnuPG 2.4.8 verwendet,

Bob keine abweichende Konfiguration nutzt und die Daten mit head -c64 /dev/urandom | gpg -e -r online verschlüsselt.

2. Beschriebenes Angriffsszenario

Zur Erläuterung der behaupteten Auswirkungen wird auf der Webseite ein Angriffsszenario beschrieben.

Mallory is an attacker who either later gets access to an encrypted message, or as as an active MITM. Mallory's goal is to decrypt an encrypted message that Alice encrypted for Bob.

Alice has Bob's public key

Alice encrypts the plaintext "SECRET" to Bob's public key, and sends the ciphertext as a PGP message to Bob.

Mallory gets access to the encrypted message, and would like to decrypt it, so Mallory modifies the message to be a public key.

Mallory sends Bob the modified message, asking for a signature on the public key—a common not suspicious action for PGP users.

Bob decrypts and signs the apparent public key, and publishes the signature along with the public key to a keyserver.

Mallory fetches the key from the keyserver and retrieves the accidentally decrypted plaintext

Deutsche Übersetzung:

Mallory ist ein Angreifer, der entweder nachträglich Zugriff auf eine verschlüsselte Nachricht erhält oder als aktiver Man-in-the-Middle agiert. Mallorys Ziel ist es, eine Nachricht zu entschlüsseln, die Alice für Bob verschlüsselt hat.

Alice besitzt Bobs öffentlichen Schlüssel.

Alice verschlüsselt den Klartext „SECRET“ mit Bobs öffentlichem Schlüssel und sendet die verschlüsselte Nachricht als PGP-Nachricht an Bob.

Mallory erhält Zugriff auf die verschlüsselte Nachricht und manipuliert sie so, dass sie wie ein öffentlicher Schlüssel aussieht.

Mallory sendet Bob die manipulierte Nachricht und bittet ihn, den angeblichen öffentlichen Schlüssel zu signieren – ein für PGP-Nutzer:innen üblicher und nicht verdächtig wirkender Vorgang.

Bob entschlüsselt den vermeintlichen öffentlichen Schlüssel, signiert ihn und veröffentlicht die Signatur zusammen mit dem öffentlichen Schlüssel auf einem Keyserver.

Mallory ruft den Schlüssel vom Keyserver ab und erhält dadurch den unbeabsichtigt entschlüsselten Klartext.

3. Einschränkungen und Annahmen des Angriffs

Soweit wir der Darstellung entnehmen können, basiert der Angriff im Wesentlichen darauf, dass Mallory Bob eine manipulierte Nachricht zusendet und ihn um eine Signatur für den öffentlichen Schlüssel bittet – ein für PGP-Nutzer:innen üblicher und nicht verdächtig wirkender Vorgang. Bob entschlüsselt den vermeintlichen öffentlichen Schlüssel, signiert ihn und stellt die Signatur zusammen mit dem öffentlichen Schlüssel auf einen Keyserver.

Allerdings ignoriert Bob dabei, dass die Entschlüsselung fehlgeschlagen ist, und signiert damit etwas, bei dem er sich nicht sicher sein kann, was er überhaupt unterschreibt. Der Zweck hinter authentifizierter Verschlüsselung (AD) – entweder mittels CFB+MDC (seit Version 1.0.2 im Jahr 2000) oder OCB (seit Version 2.3.0 im Jahr 2021) – besteht genau darin, eine derart veränderte verschlüsselte Nachricht zu erkennen.

4. Weitere Behauptungen zur Fehlerbehandlung und Einordnung

In der Angriffsbeschreibung wird weiter ausgeführt:

Packets can be modified by an attacker to output a failure that appears harmless to the user, such as truncation, and

it does not discard inputs known to be a security problem and continues processing the data.

Deutsche Übersetzung:

Pakete können von einem Angreifer so verändert werden, dass ein Fehler ausgegeben wird, der für den Benutzer harmlos erscheint, etwa eine Verkürzung, und

es verwirft Eingaben, von denen bekannt ist, dass sie ein Sicherheitsproblem darstellen, nicht, sondern verarbeitet die Daten weiter.

Diese Darstellung setzt voraus, dass eine von gpg ausgegebene Fehlermeldung gezielt verharmlost oder ignoriert wird. Die in diesem Zusammenhang genannte Meldung lautet:

gpg: decryption failed: Invalid packet

Das „erscheint für den Benutzer harmlos“ setzt somit Social Engineering voraus, um diese Fehlermeldung kleinzureden oder wegzudiskutieren.

Die Aussage, GnuPG würde problematische Eingaben nicht verwerfen, beruht zudem auf einem Missverständnis der Arbeitsweise von Unix-Werkzeugen. Ein klassisches Unix-Werkzeug schreibt nicht zwingend direkt in eine Datei, sondern arbeitet häufig in einer Pipeline. Daten, die bereits an die Ausgabe geschrieben wurden, können nachträglich nicht mehr zurückgenommen werden. Erst nach vollständiger Verarbeitung kann festgestellt werden, ob die Daten insgesamt gültig waren.

Spezialisierte Anwendungen oder grafische Oberflächen können hier anders reagieren. Sie puffern die entschlüsselten Daten vollständig und fragen vor dem Speichern nach. So wird sichergestellt, dass fehlerhafte Daten nicht weiterverwendet werden.

Unter diesen Voraussetzungen liegt kein Programmfehler vor.

▶ Nr. 5: Memory Corruption in ASCII-Armor Parsing (memcpy)

Unser Ticket: https://dev.gnupg.org/T7906
Status: behoben am 6. November 2025 für VSD, am 19. November 2025 für 2.5 und am 30. Dezember 2025 für 2.4
Beschreibung: Bei diesem Fehler kann maximal ein einzelnes Byte überschrieben werden. Dieses Byte könnte den Anfang des nächsten Blocks im Heap betreffen und dabei das dort üblicherweise verwendete Tag verändern.
Einordnung: Abhängig von der jeweiligen malloc(3)-Implementierung wäre es vor etwa 20 Jahren unter Umständen noch möglich gewesen, daraus einen Exploit zu entwickeln. Heute ist dies jedoch ausgeschlossen: Moderne malloc-Implementierungen überprüfen Pointer und Größen konsistent und lösen bei Unstimmigkeiten einen harten Abbruch des Prozesses aus.

Selbst wenn es gelingen sollte, den nächsten Block im Heap gezielt zu beeinflussen, ist darüber – etwa über free() – keine Codeausführung möglich (vgl. „Vudo Malloc Tricks“, Phrack #57, 2001, https://phrack.org/issues/57/8.html).

▶ Nr. 6: Kein GnuPG-Thema (minisign)

Einordnung: Die in diesem Zusammenhang erwähnten Beobachtungen beziehen sich auf minisign und nicht auf GnuPG. Sie betreffen weder die Funktionalität noch die Sicherheit von GnuPG und fallen daher nicht in unseren Verantwortungsbereich.

▶ Nr. 7: Cleartext Signature Forgery in the NotDashEscaped Header Implementation in GnuPG (notdash)

Unser Ticket: https://dev.gnupg.org/T7901
Status: kein Programmfehler (Social Engineering, falsche Nutzung von Cleartext-Signaturen und notwendige Änderungen am Userinterface, siehe Hinweis oben)
Einordnung: Die betroffene Funktionalität wurde in GnuPG 2.5.16 als obsolet markiert. Sie kann nur noch mit einem speziellen Flag überprüft werden und war Teil eines Release-Prozesses, der heute nicht mehr verwendet wird.

▶ Nr. 8: OpenPGP Cleartext Signature Framework Susceptible to Format Confusion (notsoclear)

Unser Ticket: https://dev.gnupg.org/T7902
Status: kein Programmfehler (Social Engineering, falsche Nutzung von Cleartext-Signaturen und notwendige Änderungen am Userinterface, siehe Hinweis oben)
Beschreibung: In dem beschriebenen Szenario wird das Format einer Cleartext-Signatur manipuliert, indem im Header -----BEGIN PGP SIGNED MESSAGE------ ein zusätzliches Minuszeichen enthalten ist.
Voraussetzung: Nutzer:innen prüfen die signierte Ausgabe nicht und akzeptieren die manipulierte Struktur.
Einordnung: Die beschriebene Verwechslung setzt Social Engineering voraus und beruht auf einer nicht vorgesehenen Nutzung von Cleartext-Signaturen.

Ergänzende technische Einordnung

Damit dieses Szenario greift, müssen Nutzer:innen die Eingabedaten betrachten, ohne zu bemerken, dass der Header der Cleartext-Signatur minimal, aber gezielt verändert wurde. Ein zusätzliches Minuszeichen kann dabei leicht übersehen werden.

Gerade aus diesem Grund ist es wichtig, sich nicht auf die Eingabedaten zu verlassen, sondern die von gpg erzeugte Ausgabe zu prüfen. Wie bereits oben beschrieben, lässt sich dies durch die Nutzung von --output zuverlässig sicherstellen.

▶ Nr. 9: GnuPG Output Fails To Distinguish Signature Verification Success From Message Content (noverify)

Unser Ticket: https://dev.gnupg.org/T7909
Status: kein Programmfehler (Social Engineering, falsche Nutzung von Cleartext-Signaturen und notwendige Änderungen am Userinterface, siehe Hinweis oben)
Beschreibung: In diesem Szenario enthalten die verschlüsselten Daten selbst eine gefälschte Erfolgsmeldung von gpg, die wie eine erfolgreiche Signaturprüfung aussieht.
Voraussetzung: Nutzer:innen müssen diese Meldung als vertrauenswürdig ansehen, ohne das tatsächliche Ergebnis der Signaturprüfung zu beachten.
Einordnung: Die Irreführung beruht auf gezieltem Social Engineering und darauf, dass die Ausgabe der signierten Daten nicht geprüft wird. Ein Fehler in der Signaturprüfung selbst liegt hierbei nicht vor.

▶ Nr. 10: Cleartext Signature Forgery in GnuPG (nullbyte)

Unser Ticket: https://dev.gnupg.org/T7900
Status: kein Programmfehler (Social Engineering, falsche Nutzung von Cleartext-Signaturen und notwendige Änderungen am Userinterface, siehe Hinweis oben)
Beschreibung: In dem beschriebenen Szenario wird der Eindruck einer gültigen Cleartext-Signatur erweckt, obwohl der tatsächlich geprüfte Inhalt davon abweicht.
Voraussetzung: Nutzer:innen betrachten die ursprüngliche Eingabe, nicht jedoch die von gpg validierte Ausgabe der Signaturprüfung.
Einordnung: Die Irreführung entsteht ausschließlich dadurch, dass die geprüfte Ausgabe der Signaturprüfung nicht beachtet wird. Sie setzt gezieltes Social Engineering sowie eine nicht vorgesehene Nutzung von Cleartext-Signaturen voraus.

▶ Nr. 11: Radix64 Line-Truncation Enabling Polyglot Attacks (polyglot)

Unser Ticket: https://dev.gnupg.org/T7905
Status: kein Programmfehler (Social Engineering, falsche Nutzung von Cleartext-Signaturen und notwendige Änderungen am Userinterface, siehe Hinweis oben)
Beschreibung: In dem beschriebenen Szenario werden Daten so manipuliert, dass signierte und nicht signierte Daten nebeneinander erscheinen.
Voraussetzung: Nutzer:innen müssen bei der Entschlüsselung eine von gpg ausgegebene Fehlermeldung ignorieren und sich dennoch auf die angezeigten Daten verlassen.
Einordnung: Eine erfolgreiche Ausnutzung setzt voraus, dass die ausgegebene Fehlermeldung bewusst ignoriert wird.

▶ Nr. 12: GnuPG May Downgrade Digest Algorithm to SHA1 (sha1)

Unser Ticket: https://dev.gnupg.org/T7904
Status: behoben am 22. Oktober 2025
Beschreibung: Durch einen Programmfehler konnte GnuPG den verwendeten Hash-Algorithmus auf SHA-1 herabstufen.
Einordnung: Es handelt sich hierbei um einen tatsächlichen Programmfehler. Um diesen Bug praktisch auszunutzen, wäre jedoch ein Second-Preimage-Angriff auf SHA-1 erforderlich. Ein solcher Angriff ist für SHA-1 derzeit nicht möglich.

▶ Nr. 13: GnuPG Trust Packet Parsing Enables Adding Arbitrary Subkeys (trust)

Status: kein Programmfehler (Social Engineering, siehe Hinweis oben)
Beschreibung: In dem beschriebenen Szenario wird behauptet, dass manipulierte Trust-Pakete im Keyring dazu führen könnten, dass zusätzliche Subkeys berücksichtigt werden.
Voraussetzung: Nutzer:innen müssen dazu gebracht werden, einen für sie nicht verständlichen und bösartigen Befehl auf der Kommandozeile auszuführen.
Einordnung: Der Angriff setzt voraus, dass Nutzer:innen einen manipulierten Keyring aus einer externen Quelle übernehmen und diesen anschließend für kryptografische Operationen verwenden, um mit darin enthaltenen, manipulierten Zertifikaten zu verschlüsseln.

Im normalen Einsatz werden öffentliche Schlüssel oder Zertifikate ausgetauscht, nicht jedoch vollständige Keyrings. Das dargestellte Szenario ist daher nur unter gezielten Social-Engineering-Annahmen relevant und erfordert eine Nutzung der Kommandozeile außerhalb der vorgesehenen Anwendungsfälle.

▶ Nr. 14: Kein GnuPG-Thema (minisign)

Einordnung: Die in diesem Zusammenhang erwähnten Beobachtungen beziehen sich auf minisign und nicht auf GnuPG. Sie betreffen weder die Funktionalität noch die Sicherheit von GnuPG und fallen daher nicht in unseren Verantwortungsbereich.

Klarstellung zur Signierung: Commits und Releases sind durchgängig signiert

Gegen Ende des Vortrags entsteht der Eindruck, wir würden auf das Signieren von Git-Commits verzichten oder diesem Thema keine besondere Bedeutung beimessen. Das ist nicht zutreffend.

Commits in unseren offiziellen Git-Repositorys werden seit vielen Jahren konsequent digital mit GnuPG signiert. Zur Absicherung der geheimen Schlüssel setzen wir dabei standardmäßig Smartcards ein.

Darüber hinaus sind selbstverständlich auch alle unsere Release-Tarballs und Release-Tags digital signiert. GnuPG war das erste Projekt, das diese Praxis eingeführt hat – vor über 25 Jahren. Bis heute bieten viele andere, teils kritische und weit verbreitete Bibliotheken und Werkzeuge keine Möglichkeit, die Authentizität ihrer Veröffentlichungen kryptografisch zu überprüfen.

Responsible Disclosure und Verantwortung in der Sicherheitskommunikation

Wir begrüßen Sicherheitsforschung und Hinweise auf mögliche Probleme ausdrücklich. Solche Rückmeldungen sind wichtig. Sie tragen dazu bei, sicherheitskritische Software weiterzuentwickeln.

Im konkreten Fall enthielten die veröffentlichten Beobachtungen keine neuen Hinweise auf sicherheitsrelevante Programmfehler. Echte Bugs haben wir – wie immer – klar benannt und zügig behoben. Alles andere betraf bekannte Eigenschaften der Software oder bewusste Designentscheidungen.

Das eigentliche Problem liegt nicht in den Beobachtungen selbst, sondern in ihrer Darstellung. Die Liste auf gpg.fail stellt sehr unterschiedliche Sachverhalte nebeneinander, ohne sie einzuordnen oder voneinander abzugrenzen. Dadurch entsteht der Eindruck, es handele sich um eine Reihe schwerwiegender Sicherheitslücken.

Tatsächlich beschreiben viele dieser Beobachtungen Varianten desselben Grundproblems: Es wird etwas anderes geprüft als das, was später als „signiert“ oder „verifiziert“ wahrgenommen wird. Das ist kein neues Phänomen und in weiten Teilen eine Eigenschaft des zugrunde liegenden Standards.

Responsible Disclosure heißt nicht: veröffentlichen und fertig. Wer öffentlich auftritt, muss einordnen, präzise bleiben und die Wirkung bedenken.

Für Software wie GnuPG, die in sensiblen und sicherheitsrelevanten Umgebungen eingesetzt wird, ist diese Verantwortung besonders hoch. Öffentliche Aussagen müssen diesem Kontext gerecht werden.

Die Beobachtungen hätten sachlich und differenziert dargestellt werden können, ohne rhetorische Zuspitzung. Das hätte zur technischen Einordnung beigetragen. Stattdessen entsteht ein Bild, das weder technisch gerechtfertigt ist noch der Verantwortung entspricht, die mit der Kommunikation über sicherheitskritische Software einhergeht.