PGP-Schlüssel – besonders zur Ende-zu-Ende-Verschlüsselung von E-Mails verwendet – werden zumeist durch acht hexadezimale Zahlen (32 Bit) identifiziert. Zum Beispiel 6F9EA68A (einer meiner PGP-Schlüssel). Seit Jahren ist bekannt, daß diese 32-Bit-ID viel zu kurz ist:

Ein Angreifer kann recht einfach eigene PGP-Schlüssel erzeugen, deren ID auf die gleichen 32 Bit enden wie die des angegriffenen Schlüssels. Da viele Nutzer nur diese acht hexadezimalen Zeichen verwenden, wenn sie Schlüssel auf Keyservern nachschlagen, kann es so passieren, daß E-Mails an Schlüssel des Angreifers verschlüsselt werden, der als Man in the Middle die Nachrichten lesen könnte, was jedoch nicht die eigentlichen Empfänger mit ihren eigentlichen Schlüssel können. (Damit das bei den eigentlichen Empfängern nicht auffällt, die E-Mails bekommen, die sie nicht entschlüsseln können, könnte der Man in the Middle die von ihm entschlüsselten E-Mails nach dem Lesen/Kopieren an die eigentlichen Schlüssel verschlüsseln und weiterleiten.)

Wie einfach es ist, falsche Schlüssel zu einer kurzen ID zu erzeugen, wurde im Jahr 2014 mit »Evil 32«, gezeigt, wo das sogenannte Strong Set der am meisten untereinander beglaubigten/signierten PGP-Schlüssel im Web of Trust nachgebaut wurde – mit neuen Schlüsseln zu kurzen Key-IDs und sogar Signaturen von anderen falschen Schlüsseln.

Nun hat im Jahr 2016 jemand die falschen öffentlichen Schlüssel aus der Evil-32-Demonstration von 2014 genommen und auf die Schlüsselserver hochgeladen. Zwar haben die Urheber der Demonstration, die die privaten Schlüssel besitzen, die falschen öffentlichen Schlüssel widerrufen können (revoke). Aber übersichtlicher und einfacher wurde aufgrund dieses Vandalismus die PGP-Nutzung nicht gerade, im Gegenteil.

Echter und falscher Schlüssel zu meiner kurzen Key-ID auf einem Keyserver.

Fingerprints

Das ist nun der Anlaß, endgültig die Nutzung der kurzen, 32-bittigen Key-ID abzustellen. Die lange, 64-bittige Key-ID ist etwas besser – aber auch zu dieser lassen sich neue Schlüssel erzeugen. Wer sichergehen möchte, sollte immer den gesamten Fingerabdruck (Fingerprint) angeben und vergleichen. Und das Vergleichen über einen anderen Kommunikationskanal wie zum Beispiel persönlich oder bei bekannter Person telefonisch.

Übrigens: In der Regel sind bei modernen Schlüsseln die letzten 16 hexadezimalen Zeichen des Fingerprints die lange Schlüssel-ID, die letzten 8 Zeichen die kurze.

Meine PGP-Schlüssel sind zum Beispiel seit Anfang dieses Jahrtausends:

Mein aktuell bevorzugter Schlüssel, ein DSA-Schlüssel (dessen Fälschung aus dem Jahr 2014 interessanterweise ein RSA-Schlüssel wurde):

Fingerprint: 2B54 A24A FFE0 94A9 8925 35A5 DB82 40FE 6F9E A68A
Lang-ID: DB82 40FE 6F9E A68A
Kurz-ID: 6F9E A68A

Einer meiner alternativen, technisch veralteter RSA-Schlüssel mit PGP-2- bzw. Version-3-Schlüsselformat (hier sind die lange und kurze Key-ID nicht Bestandteil des Fingerprints) und MD5-Hash:

Fingerprint: 0D E1 E6 0A C5 56 E0 10 60 7C A4 68 CC 16 BC E5
Lang-ID: 8437 1543 5CA8 231B
Kurz-ID: 5CA8 231B

Und wo ich mir das so ansehe, fällt mir wieder auf, daß ich schon seit Jahren vor mir herschiebe, einen neuen RSA-Schlüssel mit 4096 Bit und Unterschlüsseln (Subkeys) zu erzeugen, verbreiten und Signaturen einzuwerben …

Ein bißchen wundert es mich übrigens, daß meine Schlüssel, die kaum von anderen signiert wurden, im Strong Set des Web of Trust sein sollen und deshalb mit angegriffen wurden.

GnuPG-Konfiguration

In der ~/.gnupg/gpg.conf sollte man unbedingt die Anzeige der langen Schlüssel-ID und des Fingerabdrucks einschalten:

keyid-format 0xlong
with-fingerprint

Und wenn man schon dabei ist, sollte auch überprüft werden, ob diese Einstellungen für verbesserte Verschlüsselung in der ~/.gnupg/gpg.conf vorgenommen wurden:

personal-cipher-preferences AES256 AES192 AES CAST5

personal-digest-preferences SHA512 SHA384 SHA256 SHA224
cert-digest-algo SHA512
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed

no-emit-version
no-comments

Außerdem sollte man einen Schlüsselserver einstellen, mit dem vorzugsweise transportverschlüsselt (HKPS) kommuniziert wird – dafür wird unter Debian GNU/Linux nicht nur das Paket gnupg, sondern auch gnupg-curl benötigt, ansonsten gibt es Fehlermeldungen (»gpgkeys: HTTP search error 1: unsupported protocol«).

keyserver hkps://hkps.pool.sks-keyservers.net
keyserver-options ca-cert-file=/PFAD/ZU/sks-keyservers.netCA.pem

Möchte man pool.sks-keyservers.net verwenden, so muß man deren CA-Zertifikat lokal abspeichern, da sie ein selbstsigniertes verwenden (ansonsten gibt es eine Fehlermeldung »gpgkeys: HTTP search error 60: server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none«).

Diese Einstellungen basieren auf den folgenden Dokumenten:

Aktuelle Problematik mit kurzen Key-IDs entdeckt durch Tweets von Jens Kubieziel und seinen Blogeintrag Vorsicht vor gefälschten PGP-Schlüsseln.

Nachtrag vom 2016-08-17: