DEUTSCHE GNUPG ANLEITUNG

E-Mail Nachrichten im PGP/MIME Format

Neben den bekannten "PGP/INLINE" signierten oder verschlüsselten Nachrichten, wo der Ciphertext, bzw. die Signatur immer den gesamten Body einer Nachricht darstellt, besteht die nach PGP/MIME signierte oder verschlüsselte Nachricht aus mehreren MIME Anteilen.

PGP/MIME basiert auf drei IETF Standardentwürfen (sog. Drafts), bzw.Standards:

  • RFC 2440 "OpenPGP Message Format" (ersetzt RFC 1991 "PGP Message Exchange Formats")
    beschreibt die Methoden und den Aufbau OpenPGP verschlüsselter, bzw. signierter Daten
  • RFC 3156 "MIME Security with Pretty Good Privacy (PGP)" (löst RFC 2015 "MIME Security with Pretty Good Privacy (PGP)" ab),
    RFC 3156 "übersetzt" die im RFC 1847 "Security Multiparts for MIME Multipart/Signed and Multipart/Encrypted" definierten MIME Inhaltstypen in OpenPGP spezifische Inhaltstypen zur Verschlüsselung und Signierung und führt dadurch die drei Subtypen "application/pgp-encrypted", "application/pgp-signature" und "application/pgp-keys" ein.

    MIME steht für "Multipurpose Internet Mail Extensions" und definiert grundlegend das Format, das E-Mail Nachrichten zur Übertragung von textuellen und nicht-textuellen Bodyinhalten aufweisen.
    Nach RFC 822 Standard for the format of ARPA internet text messages besteht eine Nachricht nur aus Text, der aus 7-Bit Zeichen des US-ASCII Zeichensatzes besteht. Eine Nachricht enthält danach weder Umlaute, bzw. sprachspezifische Zeichen noch andere 8-Bit Zeichen, wie sie in multimedialen, binären Inhalten wie Audio- oder Videodaten vorkommen.
    Um diese Beschränkungen aufzuheben, wurden Codierungsanweisungen für verschiedene Nachrichteninhalte festgelegt, die im Header einer E-Mail in mehreren Feldern festgehalten werden:
    Ein Feld gibt die MIME-Version an, das Content-Type Feld die Art des Inhalts und das Content-Transfer-Encoding Feld das verwendete Kodierungsverfahren. Über den Content-Type: Multipart kann der Nachrichtenbody in mehrere Abschnitte verschiedenen Inhalts unterteilt werden. Es ist auch möglich, eigene Nachrichteninhaltstypen zu definieren.

    RFC 1847 definiert also, wie per MIME und E-Mail verschlüsselte und signierte Bodyinhalte formatiert werden, RFC 3156 wie das mittels OPenPGP geschieht.
    Somit stellt PGP/MIME den eigentlichen Standard für die Übertragung von Nachrichten dar, die mit OpenPGP kompatiblen Programmen wie GnuPG oder PGP signiert und/oder verschlüsselt werden.

Leider ist die Unterstützung und die Bekanntheit von PGP/MIME abhängig davon, ob die Hersteller von E-Mail Clients PGP/MIME implementieren.
Wird PGP/MIME bei den Linux Mailclients weitestgehend abgedeckt, steht dies bei den Mail Clients unter Windows noch aus. Mail Clients wie z. B. The Bat oder Microsoft Outlook haben es bisher versäumt, PGP/MIME zu implementieren. Das ist auch der Grund, warum viele User derartiger Mail Clients mit PGP/MIME konformen Nachrichten zuerst nichts anfangen können.
Auf folgenden Sites finden sich Übersichten zum Grad der PGP/MIME Unterstützung bei verschiedenen E-Mail Clients:

Die Daten, die per PGP/MIME verschlüsselt werden, bzw. die mittels PGP/MIME erzeugten Signaturen liegen zuerst als 8-bit binärer Output vor.
Um eine Beschädigung der Signatur durch Mail Gateways zu verhindern, werden die Daten mittels quoted-printable oder Base64 nachträglich in 7-bit umcodiert .

PGP/MIME verschlüsselte Nachricht

eine OpenPGP PGP/MIME verschlüsselte Nachricht besteht aus einem speziellen Header und zwei Body Anteilen:
  1. im Header der Nachricht wird in der Headerzeile
    Content-Type: multipart/encrypted; protocol="application/pgp-encrypted";
    boundary="string"
    der MIME Inhaltstyp nach RFC 1847 bestimmt und über den Protokoll Parameter der Subtyp, der auf den ersten Teil des Bodys verweist
  2. der erste Body Anteil [application/pgp-encrypted] enthält die Kontrollinformationen, bzw. -anweisungen, die eigentlich nur aus der "Version: 1" Angabe bestehen, da alle weiteren Informationen in den Paketen der OpenPGP Verschlüsselung gespeichert sind .
  3. der zweite Body Anteil [application/octet-stream] enthält die eigentlichen Daten, die verschlüsselt wurden.
Da der zweite Body Anteil als Attachment abgespeichert werden kann und die gleiche Form aufweist wie die bekannten "PGP/INLINE" Ciphertexte können Personen, deren E-Mail Clients nicht PGP/MIME fähig sind, einfach diesen Body Anteil als Datei abspeichern und per Kommando, bzw. Datei entschlüsseln Menübefehl der GUI's entschlüsseln.

PGP/MIME signierte Nachricht

eine OpenPGP PGP/MIME signierte Nachricht besteht aus einem speziellen Header und zwei Body Anteilen:
  1. im Header der Nachricht wird in der Headerzeile
    Content-Type: multipart/signed; protocol="application/pgp-signature";
    micalg="pgp-ripemd160"; boundary="string"
    der MIME Inhaltstyp nach RFC 1847 bestimmt, über den Protokoll Parameter der Subtyp der auf den Body Anteil verweist und über den micalg (Message Integrity Check Algorithm) Parameter der verwendete Digest Algorithmus (in diesem Beispiel RIPEMD160)
  2. der erste Body Anteil besteht aus der Nachricht in Klarform, die signiert wurde
  3. der zweite Body Anteil [application/pgp-signature] enthält die eigentiche Signatur.

PGP/MIME verschlüsselte und signierte Nachricht

bei einer Kombination aus Verschlüsselung und Signierung wird die Nachricht entweder zuerst signiert und danach die Nachricht mit der Signatur in eine Verschlüsselung eingekapselt, so dass nach der Entschlüsselung eine nachträgliche Verifizierung vorgenommen wird oder Signierung und Verschlüsselung werden in einer Nachricht parallel durch- und zusammengeführt.

 

Kryptografische Algorithmen

Bei GnuPG können folgende Algorithmen eingesetzt werden:

Verschlüsselungsalgorithmen (Cipher)
- symmetrisch
(IDEA*), 3DES, CAST5, BLOWFISH, TWOFISH, RIJNDAEL, RIJNDAEL192, RIJNDAEL256
Signieralgorithmen (Pubkey) DSA, ELG, RSA, RSA-S
Verschlüsselungsalgorithmen (Pubkey) RSA, RSA-E, ELG, ELG-E
Hashalgorithmen (Digest) MD5, SHA1, RIPEMD160 (TIGER, SHA256/384/512*)
Kompressionsalgorithmen ZIP (RFC 1951) compress-algo 1
ZLIB (RFC 1950) compress-algo 2

* mit Kryptomodul idea-, tiger- und sha2.dll

Eine Auflistung der Verschlüsselungs (Cipher & Pubkey)- und Hashalgorithmen (Digest) wird mit dem Befehl
LW:\>gpg --version angezeigt

Laut OpenPGP Standard gibt es folgende Identifizierungsnummern und Bezeichnungen für die einzelnen Algorithmen:

Public Key Algorithmen

1 RSA (Encrypt or Sign)
2 RSA Encrypt-Only
3 RSA Sign-Only
16 Elgamal (Encrypt-Only)
17 DSA (Digital Signature Standard)
18 Elliptic Curve (reserviert)
19 ECDSA (reserviert)
20 Elgamal (Encrypt or Sign)
21 Diffie-Hellman (X9.42, IETF-S/MIME) (reserviert)
100-110 private/experimentelle Algorithmen

Symmetrische Key Algorithmen (S)

0 Klartext
1 IDEA
2 Triple-DES
3 CAST5-128
4 Blowfish-128
5 SAFER-SK128
6 DES/SK (reserviert)
7 AES-128
8 AES-192
9 AES-256
10 Twofish
100-110 private/experimentelle Algorithmen

Kompressions Algorithmen (Z)

0 unkomprimiert
1 ZIP (RFC 1951)
2 ZLIB (RFC 1950)
100-110 private/experimentelle Algorithmen

Hash Algorithmen (H)

1 MD5 "MD5"
2 SHA-1 "SHA1"
3 RIPE-MD/160 "RIPEMD160"
4 SHA-2 (reserviert)
5 MD2 "MD2"
6 TIGER/192 "TIGER192" (reserviert)
7 HAVAL "HAVAL-5-160" (reserviert)
100-110 private/experimentelle Algorithmen


Einsatz bevorzugter Verschlüsselungs-, Digest und Kompressionsalgorithmen

Welche Algorithmen zur Verschlüsselung, bei Verschlüsselung + Signierung und zur Kompression vom Key-Benutzer, z. B. dem E-Mailpartner, bevorzugt zu verwenden sind, kann bei GnuPG im Key gespeichert werden.
Die Standardeinstellung ist für die bevorzugten Verschlüsselungsalgorithmen AES128-CAST5-3DES-IDEA, für die Hashalgorithmen SHA1-RIPEMD160 und für die Kompressionsalgorithmen ZLIB-ZIP.

Vorgehensweise:

  1. LW:\>gpg --edit-key Key-ID ruft den Bearbeitungsmodus auf
  2. Befehl>showpref zeigt die aktuellen Präferenzen mit Nennung der verwendeten Algorithmen an
    Befehl>pref zeigt die aktuellen Präferenzen in der Kurzform Kürzel ID an.
  3. Befehl>setpref S(1-10) H(1-3) Z(1-2) stellt die Reihenfolge um (man orientiere sich bei der Eingabe an der Ausgabeform von pref und der Algorithmen-Tabelle)
  4. Befehl>updpref aktualisiert die gespeicherten Präferenzen mit der neuen Reihenfolge
  5. Befehl>save speichert die vorgenommenen Änderungen

mit dem Eintrag default-preference-list S(1-10) H(1-3) Z(1-2) in der gpg.conf werden die Präferenzen dauerhaft festgelegt, d. h. bei einer Keyerstellung, einem Update der Präferenzen im Key Editiermodus mit 'updpref' oder einer Verschlüsselung werden automatisch die Einstellungen übernommen.
Zum Beispiel legt 'default-preference-list S10 S9 S8 S7 S1 S2 S4 H3 H2 Z2 Z1' fest, dass für neue Keys
Twofish-AES256-AES196-IDEA-3DES-Blowfish RIPEMD160-SHA1 ZLIB-ZIP verwendet wird.

Damit die Algorithmuspräferenzen des Kommunikationspartners respektiert werden, wenn man selbst dessen Key benutzt, dürfen der Verschlüsselungs-, Digest- und Kompressionsalgorithmus nicht mit den Optionen cipher-algo, digest-algo und compress-algo in der gpg.conf festgeschrieben werden, da mit diesen Optionen die vom Kommunikationspartner gewünschten Algorithmen überschrieben werden.
Stattdessen gibt man die eigenen, bevorzugten Algorithmen zur Verschlüsselung mit personal-cipher-preferences S(1-10), zum Erzeugen des Hashes mit personal-digest-preferences H(1-4) und zur Kompression mit personal-compress-preferences Z(1-2) in der gpg.conf an.
Auf diese Weise werden bei der Verschlüsselung und bei der Verschlüsselung + Signierung aus der Präferenzenkette des Empfänger Public-Keys und den eigenen, bevorzugten Präferenzen eine neue Präferenzenkette gebildet, die aus den Algorithmen besteht, die beide, also Keybesitzer (Empfänger) und Keyanwender (Absender) gemeinsam haben, bzw. die auf beiden Seiten in den Präferenzen genannt werden.

Die leidige Ausnahme stellt der Fall der reinen Signierung dar. Hierbei wird ja nur der eigene Key herangezogen.
Selbst wenn in der im Key gespeicherten Präferenzenkette eine bestimmte Rangfolge mit H(1-4) besteht und mit personal-digest-preferences H(1-4) eine Rangfolge angegeben wurde, wird immer SHA-1 benutzt, sofern nicht mit digest-algo (MD5|SHA1|RIPEMD160) der gewünschte Digestalgorithmus angegeben wurde.
Setzt man aber die digest-algo Option dauerhaft, wird im Falle der Verschlüsselung + Signierung der vom Empfänger gewünschte Digestalgorithmus überschrieben.
Also muss man die digest-algo Option entweder fallweise GnuPG als Kommandozeile übergeben oder man richtet sich für verschiedene PGP/GnuPG Benutzer, bzw. Signierzwecke verschiedene gpg.conf Dateien ein, in denen die digest-algo Option gesetzt ist oder nicht.

 

Andere GnuPG Versionen - IDEA (und TIGER, SHA-2) Kompilate

GnuPG kann mit zusätzlichen Kryptomodulen um weitere Algorithmen ergänzt werden.
IDEA ist davon offiziell ausgespart, da GNU Software nur patentfreie Programme einsetzt.
IDEA wird nur benötigt, wenn an Anwender verschlüsselt werden muss, die PGP 2.6.3 oder ältere PGP 5/6 Versionen einsetzen. Für Linuxanwender ist es möglich, IDEA Module für GnuPG selbst zu kompilieren. Der IDEA Sourcecode für Linuxanwender und ein vorkompiliertes IDEA Modul (idea.dll) für Windowsanwender kann hier per FTP heruntergeladen werden.
Ab Version 1.0.5 ist die Funktion ladbarer Kryptomodule auch unter Windows verfügbar.
Neben der offiziellen GnuPG Version benötigt man dazu nur die kompilierten Kryptomodule in Form der typischen DLL-Bibliotheken.

Mit der Version 1.0.5 ist es nicht mehr notwendig, fremdkompilierte GnuPG-Versionen zum Einsatz zu bringen.
Trotzdem an dieser Stelle der Hinweis, dass Keith Ray ebenfalls eine GnuPG Version anbietet, in die er die jeweils aktuellen Updates und Patches einpflegt.
Auf seiner Site und in der GnuPG Version enthalten, finden sich auch die GnuPG-Kryptomodule für IDEA, TIGER-192, SHA-2 von Disastry (siehe Hinweise zu TIGER und SHA-2 weiter unten).

Die dll Kryptomodule werden einfach in der Optionendatei gpg.conf mit dem Befehl
load-extension LW:\Pfad\kryptomodul.dll
eingebunden

Hinweise

  • Bei installiertem GnuPG und nachträglicher Installation des GPA verändern sich die GnuPG Registryeinträge, so dass die Module nicht mehr aufgefunden und geladen werden können.
  • Der SHA-2 Algorithmus ist noch nicht offizieller Bestandteil des OpenPGP Standards und wird von keiner anderen PGP-Versionen unterstützt. Er befindet sich noch in der Entwurfsphase beim NIST und soll in Ergänzung zum AES und einem überarbeitetem DSA/DSS-Standard (der größere Keylängen vorsieht) 2001/2002 als offiziell genehmigter Hashing-Standard SHA-1 ablösen.
    Gegenwärtig können (ohne Änderungen am GnuPG Quellcode) SHA-2 Signaturen nur erzeugt, aber nicht verifiziert werden.
    Der TIGER Algorithmus, von Ross Anderson und Eli Biham im Jahr 1996 veröffentlicht, ist ebenfalls nur für die Aufnahme in den OpenPGP-Standard vorgesehen, aber noch nicht offizieller Bestandteil.
  • Vom Einsatz von SHA-2 und TIGER im Kommunikationsverkehr ist aktuell abzuraten
  • siehe auch Schlüsselerzeugung und Empfehlungen zur Schlüssellänge der PGP Anleitung