OpenPGP-Schlüssel-Inspektor & Paket-Parser

PGP („Pretty Good Privacy“) wurde 1991 von Phil Zimmermann als Programm veröffentlicht, das jeder zum Verschlüsseln und Signieren von Nachrichten nutzen konnte. Um das Problem eines einzelnen Herstellers zu lösen, wurde das Nachrichtenformat als OpenPGP standardisiert (RFC 2440 im Jahr 1998, RFC 4880 im Jahr 2007, RFC 9580 im Jahr 2024). Heute ist GnuPG die häufigste Implementierung, und dasselbe Paketformat taucht auch in signierten Git-Commits, bei der Signatur von Softwarepaketen, auf Schlüsselservern und im DNS-Eintrag OPENPGPKEY auf.

Das Modell ist Ende-zu-Ende: Sie und Ihr Gegenüber erzeugen jeweils ein persönliches Schlüsselpaar; was für Sie verschlüsselt wird, kann nur mit Ihrem privaten Schlüssel entschlüsselt werden, der Ihren Rechner nie verlässt. Anstelle einer zentralen Zertifizierungsstelle (wie bei TLS) entsteht das Vertrauen in fremde Schlüssel durch das gegenseitige Signieren von Schlüsseln — das „Web of Trust“. Ob Sie dieses Netz nutzen oder einfach Fingerabdrücke außerhalb des Kanals vergleichen (Telefonat, Visitenkarte), bleibt Ihnen überlassen; das Format selbst erzwingt keines von beidem.

Ein OpenPGP-„Schlüssel“ ist eigentlich ein kleines Bündel von Paketen: ein Primärschlüsselpaket (Ihr Identitätsanker, meist zum Signieren berechtigt), ein oder mehrere Benutzer-ID-Pakete („Alice <alice@example.com>“), Selbstsignaturen, die diese IDs an den Primärschlüssel binden, und optional Unterschlüssel mit eigenen Bindungssignaturen — typischerweise ein separater Verschlüsselungs-Unterschlüssel, damit der wertvolle Primärschlüssel offline bleiben kann. Der gesamte Armor-Block, den Sie hier einfügen, ist genau dieses Bündel.

Der Fingerabdruck ist der Hash des Primärschlüsselpakets — SHA-1 (20 Byte) für v4-Schlüssel, SHA-256 (32 Byte) für v6-Schlüssel — berechnet nur über den öffentlichen Teil. Die Schlüssel-ID sind einfach die letzten 8 Byte eines v4-Fingerabdrucks (bei v5 die ersten 8). Fingerabdrücke vergleicht man außerhalb des Kanals, um sicherzugehen, dass niemand den Schlüssel auf dem Weg zu Ihnen getauscht hat; Schlüssel-IDs sind ein kurzer Bezeichner für Schlüsselserver und sind nicht kollisionssicher gegenüber einem entschlossenen Angreifer.

Algorithmus-ID	Name	Typische Verwendung in einem Schlüssel
1	RSA	Klassischer Alleskönner; 2048–4096 Bit, zum Signieren und/oder Verschlüsseln
19	ECDSA	NIST-Kurven (P-256 usw.), Signatur
18	ECDH	Curve25519/P-256-Schlüsselvereinbarung, Verschlüsselungs-Unterschlüssel
22	EdDSA	Ed25519-Signatur (der moderne Standard in GnuPG 2.4+)
25	X25519	Verschlüsselungs-Unterschlüssel zu Ed25519-Primärschlüsseln (Schlüssel v6)

Ein privater Schlüsselblock enthält nach dem öffentlichen Teil die geheimen Zahlen: ein S2K-Verwendungsoktett, das sagt, wie sie geschützt sind (0 = ungeschützt, 254/255 = passphrasenabgeleiteter Schlüssel mit einer Chiffre), danach die geheimen MPIs und eine Prüfsumme. Diese Seite zeigt diesen Schutzmodus, fragt aber nie nach einer Passphrase und versucht nie, das geheime Material zu entschlüsseln.

Unter der Armor ist jedes OpenPGP-Objekt eine Folge von Paketen. Jedes beginnt mit einem Tag-Byte: Das alte Format packt einen 4-Bit-Pakettyp und einen Längentyp hinein, das neue Format (CTB, Bit 6 gesetzt) verwendet einen 6-Bit-Typ und Längenbytes, die sogar Daten in Teilblöcken beschreiben können. Häufige Tags: 6 = öffentlicher Schlüssel, 5 = geheimer Schlüssel, 14 = Unterschlüssel, 13 = Benutzer-ID, 2 = Signatur, 4 = One-Pass-Signatur, 11 = Literaldaten, 8 = komprimierte Daten, 18 = verschlüsselte und MDC-geschützte Daten. Diese Seite gibt für jedes gefundene Paket Tag, Header-Format, Länge und einen Hex-Dump aus und meldet bei einem fehlerhaften Paketheader eine Byte-Position.

Signaturpakete tragen ihre Metadaten in gehashten und nicht gehashten Unterpaket-Bereichen. Nur der gehashte Bereich wird von der Signatur selbst abgedeckt; der nicht gehashte Bereich (früher für die Schlüssel-ID des Ausstellers genutzt) kann von jedem unterwegs frei umgeschrieben werden, daher müssen Leser ihn als Hinweis, nie als Tatsache behandeln. Die Selbstsignatur auf einer Benutzer-ID ist das, was den Namen tatsächlich an den Schlüssel bindet; ein allein eingefügtes Schlüsselpaket beweist nichts darüber, wem es gehört.

ASCII-Armor ist die Texthülle: -----BEGIN PGP PUBLIC KEY BLOCK-----, optionale Header wie Version: oder Comment:, Base64 des Paketstroms und eine abschließende Zeile =xxxx mit einer 24-Bit-CRC. Diese CRC erkennt nur Übertragungsfehler — kippen Sie ein Base64-Zeichen, markiert diese Seite es — sie ist aber keine Signatur und beweist nichts über die Urheberschaft.

• Einem Schlüssel vertrauen, ohne Fingerabdrücke zu vergleichen. Jeder kann einen Schlüssel mit einem beliebigen Namen erzeugen. Der Vergleich der Fingerabdrücke über einen Kanal, dem Sie bereits vertrauen (persönlich, telefonisch), ist der gesamte Authentifizierungsschritt.
• Die Armor-CRC mit einer Signatur verwechseln. Ein Abzeichen „CRC OK“ bedeutet nur, dass das Base64 die Übertragung überstanden hat, mehr nicht. Die Prüfung ist eine kryptografische Operation, die diese Seite bewusst nicht ausführt.
• Schlüssel-IDs als Identität verwenden. 64-Bit-Schlüssel-IDs lassen sich von einem Angreifer mit bescheidener Rechenleistung fälschen (eine „Schlüssel-ID-Kollision“); zitieren Sie immer vollständige Fingerabdrücke.
• Echte private Schlüssel in Webseiten einfügen. Selbst eine lokale Seite ohne Upload wie diese ist eine Gewohnheit, die man sich nicht angewöhnen sollte. Die Beispiele hier sind Wegwerfschlüssel, die für die Demonstration erzeugt wurden.
• Anzunehmen, dass „PGP MESSAGE“ verschlüsselt bedeutet. Die Armor-Beschriftung sagt nichts über den Inhalt aus — die Beispielnachricht auf dieser Seite ist signiert, aber im Klartext; was verschlüsselte von Literaldaten unterscheidet, ist das Pakettag 18 gegenüber 11.
• Import von v3-Schlüsseln. Schlüssel der Version 3 (Entwurf vor 1996, schwache 16-Bit-Schlüssel-IDs) sind seit 2014 veraltet; dieser Inspektor lehnt sie absichtlich ab.

Prüft das Werkzeug Signaturen? Nein. Es parst und zeigt an. Eine Signaturprüfung braucht die vollständige Hash-Trailer-Konstruktion nach RFC 9580, den öffentlichen Schlüssel des Unterzeichners und die Entscheidung, ob Sie diesem Schlüssel vertrauen — das ist die Aufgabe von GnuPG oder einer OpenPGP-Bibliothek.

Worin unterscheidet sich das von openpgp.js? openpgp.js ist eine vollständige Implementierung (verschlüsseln, entschlüsseln, signieren, prüfen), die Sie in Ihre App einbetten; diese Seite ist ein abhängigkeitsfreier Inspektor zum Lesen und Prüfen von OpenPGP-Strukturen im Browser.

Kann es meinen GnuPG-Export lesen? Ja — Schlüssel der Versionen v4, v5 und v6, losgelöste Signaturen und Nachrichten. Schlüssel der Version 3 werden mit einem Hinweis abgelehnt (seit 2014 veraltet).

Warum gibt es einen Hex-Eingabemodus? Rohe OpenPGP-Daten sind binär; wenn Sie einen Hex-Dump eines Schlüsselbundes oder einer .gpg-Datei haben, fügen Sie das Hex ein, und der Parser behandelt es genau wie die dekodierten Bytes.

Wird etwas hochgeladen? Nein. Parsen, Fingerabdruck-Berechnung und Berichterstellung finden alle in diesem Tab statt; die Seite läuft vollständig in Ihrem Browser.