OpenPGP ist ein standardisiertes Datenformat für verschlüsselte und digital signierte Daten. Auch wird das Format von Zertifikaten festgelegt, die landläufig auch als „Schlüssel“ bezeichnet werden.
Es basiert auf dem Format, das von PGP 5 eingeführt wurde, und ist im RFC 4880 standardisiert. Mit dem RFC 5581 wurde Camellia (ein weiterer symmetrischer Chiffrieralgorithmus) hinzugefügt. Das RFC 6637 ergänzte OpenPGP um Elliptic Curve Cryptography. Diese Erweiterungen sind aber ausdrücklich als „optional“ spezifiziert. Eine OpenPGP-konforme Anwendung ist also nicht gezwungen, diese beiden Erweiterungen zu implementieren.
Allgemeines
OpenPGP ist ein Binärformat. Eine OpenPGP-Nachricht besteht aus einem oder mehreren Datensätzen (), die aber aus historischen Gründen in der Originaldokumentation als , zu deutsch „Pakete“ bezeichnet werden.
Das PGP-Datenformat ist im Laufe der Zeit beständig erweitert worden und existiert in verschiedenen abwärtskompatiblen Versionen. Im Wesentlichen wird zwischen einem „alten“ Format (verwendet von PGP bis Version 2.6) und einem „neuen“ Format (ab PGP Version 3) unterschieden. Neuere PGP-Versionen können aber Nachrichten im alten Format lesen und – sofern der Inhalt auch im alten Format ausgedrückt werden kann – optional auch Nachrichten im alten Format erzeugen.
Jedes Paket beginnt mit einem genannten Byte, das den Typ und die Länge des nachfolgenden Pakets festlegt. Folgende Pakettypen sind bisher spezifiziert:
+ OpenPGP-Pakettypen nach RFC 4880 Nummer Typ Bemerkungen 0 Reserviert Ein Paket mit diesem Typ ist nicht erlaubt. 1 Public-Key Encrypted Session Key Packet Enthält den (mit dem Public Key des Empfängers verschlüsselten) genannten Schlüssel, mit dem die eigentlichen Nutzdaten (in Paket-Typ 9) verschlüsselt werden. 2 Signature Packet 3 Symmetric-Key Encrypted Session Key Packet Enthält den (mit einem symmetrischen Kryptoalgorithmus verschlüsselten) Schlüssel, mit dem die eigentlichen Nutzdaten (in Paket-Typ 9) verschlüsselt werden. 4 One-Pass Signature Packet 5 Secret-Key Packet Enthält einen privaten Schlüssel 6 Public-Key Packet Enthält einen öffentlichen Schlüssel 7 Secret-Subkey Packet 8 Compressed Data Packet Enthält Daten, die mit zlib (RFC 1950), Deflate (RFC 1951) oder Bzip2 komprimiert sind. 9 Symmetrically Encrypted Data Packet CFB-verschlüsselte Daten 10 Marker Packet 11 Literal Data Packet Enthält unverschlüsselte Binär- oder Textdaten und einen Dateinamen, unter dem die Daten abgespeichert werden können. 12 Trust Packet 13 User ID Packet Enthält üblicherweise Namen und E-Mail-Adresse eines Schlüsselinhabers. 14 Public-Subkey Packet 17 User Attribute Packet Enthält weitere Metadaten zum Schlüsselinhaber, z. B. ein JPEG-Bild. Weitere Metadatentypen sind bisher nicht spezifiziert worden. 18 Sym. Encrypted and Integrity Protected Data Packet Kann statt Pakettyp 9 verwendet werden, um verschlüsselte Daten mit einem Schutz vor versehentlicher oder absichtlicher Veränderung zu erzeugen. Dieser Schutz (, MDC genannt) ist kryptographisch schwächer als eine digitale Signatur oder ein MAC, aber einfacher zu erzeugen und besser als gar kein Schutz. 19 Modification Detection Code Packet Enthält die SHA1-Prüfsumme des mit Pakettyp 18 verschlüsselten Datenstroms. 60 bis 63 Private or Experimental Values
Da im „alten“ OpenPGP-Format nur 4 Bit zur Kodierung des Pakettyps zur Verfügung stehen, kann es nur die Pakettypen bis 15 beinhalten. Im „neuen“ Format stehen 6 Bit zur Kodierung des Pakettyps zur Verfügung, was zur Kodierung der möglichen Werte 0 bis 63 ausreicht.
Einige Pakettypen enthalten ihrerseits wiederum eine Versionskennung, wobei die Art und Anzahl der Dateninhalte i. d. R. mit steigender Versionsnummer zunehmen.
Verschlüsselung
Die Nutzdaten werden stets mit einem symmetrischen Verschlüsselungsalgorithmus und einem zufälligen „Session Key“ verschlüsselt und in einem Paket vom Typ 9 abgelegt. Dieser „Session Key“ wird nun wiederum asymmetrisch (Paket Typ 1) oder symmetrisch (Paket Typ 3) verschlüsselt und den verschlüsselten Nutzdaten vorangestellt. Damit zählt OpenPGP zu den hybriden Verfahren.
Paket Typ 1: „Public-Key Encrypted Session Key“
Eine verschlüsselte OpenPGP-Nachricht kann kein, ein oder mehrere Pakete vom Typ 1 enthalten. Üblicherweise wird für jeden Empfänger einer OpenPGP-Nachricht je ein Paket vom Typ 1 erzeugt.
Ein Typ-1-Paket enthält folgende Daten:
Eine Versionskennung, derzeit ist nur Version 3 definiert Eine 8 Byte lange Key-ID des Schlüssels, so dass ein Empfänger einfacher das für ihn bestimmte Paket finden kann. Es ist aber auch möglich, eine Null-ID anzugeben, so dass der Empfänger alle verfügbaren privaten Schlüssel durchprobieren muss. 1 Byte, das den verwendeten Public-Key-Algorithmus codiert (siehe Tabelle) Den verschlüsselten Session-Key
Folgende Public-Key-Algorithmen sind möglich:
+ Public-Key-Algorithmen ID Algorithmus Bemerkungen 1 RSA zum Verschlüsseln und Signieren 2 RSA nur zum Verschlüsseln 3 RSA nur zum Signieren 16 Elgamal nur zum Verschlüsseln 17 DSA nur zum Signieren 18 ECDH definiert in RFC 6637 19 ECDSA definiert in RFC 6637 20 reserviert 21 reserviert für Diffie-Hellman nach ANSI X9.42, wie für IETF-S/MIME definiert 100 … 110 reserviert für private / experimentelle Algorithmen
Für ECC-Schlüssel existieren verschiedene elliptische Kurven. Diese werden anhand ihrer OID identifiziert, so dass das Hinzufügen neuer Kurven keine Änderung am OpenPGP-Standard erfordert.
+ ECC-Kurven für OpenPGP Name Bitlänge OID Bemerkungen NIST curve P-256 256 1.2.840.10045.3.1.7 definiert in RFC 6637 NIST curve P-384 384 1.3.132.0.34 NIST curve P-521 521 1.3.132.0.35 Ed25519 255 1.3.6.1.4.1.11591.15.1 seit GnuPG 2.1.0, noch kein RFC Brainpool P256r1 256 1.3.36.3.3.2.8.1.1.7 Brainpool P384r1 384 1.3.36.3.3.2.8.1.1.11 Brainpool 512r1 512 1.3.36.3.3.2.8.1.1.13 secp256k1 256 1.3.132.0.10 seit GnuPG 2.1.0lists.gnupg.org
Paket Typ 3: „Symmetric-Key Encrypted Session Key“
Eine verschlüsselte OpenPGP-Nachricht kann kein, ein oder mehrere Pakete vom Typ 3 enthalten. Diese werden genutzt, um den Session Key nicht mit dem Public Key des Empfängers zu verschlüsseln, sondern mit einem symmetrischen Key, der aus einer Passphrase erzeugt wird. Pro Passphrase wird dabei je ein Paket vom Typ 3 erzeugt.
Ein Typ-3-Paket enthält folgende Daten:
Eine Versionskennung. Derzeit ist nur Version 4 definiert. Ein Byte, das den symmetrischen Chiffrier-Algorithmus codiert Eine Kennung variabler Länge, die angibt, wie der Schlüssel aus der Passphrase abgeleitet wird („string-to-key specifier“) gegebenenfalls der mit dem o. g. Verfahren verschlüsselte Session-Key
+ Symmetrische Chiffrier-Algorithmen ID Algorithmus Schlüssellänge Bemerkungen 0 unverschlüsselt – für Paket Typ 3 nicht erlaubt 1 IDEA 128 Bit einziger Algorithmus in PGP 2.6 2 TripleDES (DES-EDE) 168 Bit muss laut RFC implementiert werden 3 CAST5 128 Bit Default-Algorithmus in GnuPG 2.0 4 Blowfish 128 Bit 16 Runden 5 … 6 reserviert 7 AES 128 Bit Default-Algorithmus seit GnuPG 2.1 8 192 Bit 9 256 Bit 10 Twofish 256 Bit 11 Camellia 128 Bit definiert seit RFC 5581 12 192 Bit 13 256 Bit 100 … 110 reserviert für private / experimentelle Algorithmen
Alle Algorithmen außer TripleDES sind allerdings optional, eine standardkonforme Implementierung muss nur TripleDES beherrschen. RFC 4880 empfiehlt, dass jede Implementierung CAST5 und AES-128 beherrscht.
Anwendungen
Zwei der Hauptanwendungen sind die Signierung und die Verschlüsselung von E-Mails. Dafür müssen OpenPGP-Nachrichten geeignet kodiert werden, da eine E-Mail nach RFC 5322 nur aus druckbaren Zeichen aus dem ASCII-Zeichensatz und einigen wenigen Steuerzeichen bestehen darf.
Hierfür gibt es im Wesentlichen zwei Formate:
das ältere PGP/INLINE als Kompatibilitätsformat 15px Auch nutzbar (wenn auch nicht unproblematisch) mit Mailprogrammen, die OpenPGP nicht kennen (auch Webmail). Die E-Mail wird dabei von ihrer Struktur her als gewöhnliche Textmail erzeugt (Content-Type: text/plain), die verschlüsselten Text als Radix-64-kodierten Text enthält (Base64 plus Prüfsumme; ursprüngliches Textformat von PGP); signierter Text wird als Klartextsignatur eingefügt (Einleitungszeile, normaler Text, Signaturdaten als Radix-64). Dies ermöglicht nur das Signieren und Verschlüsseln einfachen Mailtextes (Mailbody). 15px Für HTML-Mails gibt es keine entsprechende Möglichkeit. 15px Dateianhänge können aber vorab verschlüsselt und/oder signiert werden (das übernehmen die Mailprogramme; im Fall von Webmail muss man das ohne entsprechendes Browser-Addon selber machen). Allerdings garantieren die Signaturen dann nicht die Integrität der Mail insgesamt. Signierte Teile können unbemerkt entfernt werden, in anderem Zusammenhang signierte Daten können hinzugefügt werden (was nur auffiele, wenn man sich die Mühe machte, die Zeitstempel der einzelnen Signaturen zu vergleichen). 15px Einer der Nachteile von PGP/Inline ist, dass Mailprogramme, die OpenPGP nicht verstehen, die Signatur im Text anzeigen, was viele Empfänger verwirrt. PGP/MIME als saubere technische Lösung (MIME-Erweiterung nach RFC 3156) 15px Dieses Verfahren deckt auch Dateianhänge und HTML-Mails ab. Für den Mailbody und alle Anhänge kann jeweils einzeln festgelegt werden, ob sie verschlüsselt und/oder signiert werden sollen; es wird technisch nur eine Signierung und/oder Verschlüsselung vorgenommen (bei PGP/Inline für den Textteil und jeden Dateianhang gesondert). 15px Auch dieses Verfahren schützt aber nur den Inhalt der Mail, nicht ihre Kopfdaten (vor allem Absender, Empfänger, Betreff, Datum). 15px Der Nachteil von PGP/MIME ist, dass Mailprogramme (oder Webmail-Implementierungen), die nicht einmal den grundlegenden Standard von 1995 (RFC 1847) unterstützen, der das grundsätzliche E-Mail-Format für verschlüsselte oder signierte Inhalte festlegt, im Zweifelsfall eine leere Mail mit Dateianhängen anzeigen, was noch irritierender und noch weniger benutzerfreundlich ist als eine Radix-64-Signatur im Text.
Manche Mailprogramme bieten die Möglichkeit, für die Adressbucheinträge festzulegen, in welchem Format OpenPGP-Nachrichten an die jeweilige Adresse geschickt werden sollen. Auf diese Weise kann man die Nachteile beider Verfahren minimieren.
OpenPGP und S/MIME (welches X.509-Zertifikate verwendet) sind die beiden wichtigsten Standards für E-Mail-Verschlüsselung. Eine weitere Hauptverwendung von OpenPGP ist die Absicherung der Softwareverteilung (Paketverwaltung) von z. B. Linux durch digitale Signaturen.
Geschichte Entstanden ist OpenPGP im Jahr 1998 als Reaktion auf diverse Entwicklungen:
Die in PGP verwendeten Algorithmen (IDEA und RSA) waren patentiert und konnten nicht beliebig verwendet werden. Insbesondere gab es in den USA Gesetze, die den Export von starker Verschlüsselung (ab 40 Bit) verboten. Das Programm PGP wurde kommerziell durch die Firma PGP Inc. vertrieben, und es gab unbelegte Gerüchte, dass eine Hintertür in das Programm eingebaut sei, da es über eine sogenannte ADK-Funktion (Additional Decryption Key) verfügte. Ende 1997 wurde PGP Inc. von Network Associates Inc. (NAI) bzw. McAfee übernommen, die zeitweilig den PGP-Quelltext verschlossen hielten, ADK-Funktionen einbauten und Mitglied der Key Recovery Alliance waren.
Das OpenPGP-Format wird mittlerweile von vielen Produkten implementiert. Prominente Vertreter sind das kommerzielle PGP und das freie Open-Source-Programm GnuPG (unter der GNU-GPL stehend).