Kreuvfs Allerweltsblog » GnuPG: Empfänger verstecken

2015-09-19

GnuPG: Empfänger verstecken

Abgelegt unter Software von Kreuvf um 18:08:43

Gerade für Anfänger ist die Art und Weise wie asymmetrische Verschlüsselung funktioniert in der Regel schwer verständlich. Mein letzter Beitrag zum Thema GnuPG beschäftigte sich daher auch mit einer eher trivialen Frage: GnuPG und digitales Signieren.

Mit der Zeit habe ich aber immer mal wieder ein wenig mehr mit GnuPG zu tun gehabt und dabei einige sehr spannende Dinge gelernt. Eines davon möchte ich heute vorstellen, nämlich wie man eine gültige verschlüsselte Nachricht schreibt, die aber nicht von sich aus weiß, mit welchem Schlüssel man sie entschlüsseln kann.

Eine GnuPG-Nachricht besteht nicht nur aus der verschlüsselten Botschaft, sondern ist deutlich komplexer aufgebaut: zum einen kann der zu verschlüssende Text komprimiert werden, was das Phänomen erklärt, dass eine verschlüsselte Botschaft kleiner ist als der Klartext. Die Nachricht wird auch nicht wirklich mit dem öffentlichen Schlüssel des Empfängers verschlüsselt, sondern mit einem sogenannten „Session Key“, zu Deutsch: Sitzungsschlüssel. Dieser wird benutzt, um mittels eines symmetrischen Verfahrens die Nachricht zu verschlüsseln. Der Sitzungsschlüssel wird dann mit dem öffentlichen Schlüssel des Empfängers verschlüsselt und gespeichert. Das hat den Vorteil, dass bei Nachrichten, die an mehrere Empfänger gehen sollen, der gesamte Klartext nur einmal verschlüsselt werden muss und nur die vergleichsweise geringe Informationsmenge, die der Sitzungsschlüssel darstellt, für alle Empfänger mit deren öffentlichen Schlüssel verschlüsselt werden muss. Damit der Empfänger die Nachricht möglichst schnell entschlüsseln kann, enthält sie daher auch einen Hinweis auf den für die Entschlüsselung notwendigen Schlüssel.

Will man allerdings möglichst anonym kommunizieren, das heißt so kommunizieren, dass ein Beobachter, der die Nachricht mitschneidet, nicht weiß, an wen die Nachricht gerichtet ist, darf kein Hinweis auf den Empfänger vorhanden sein. Dies lässt sich bewerkstelligen, indem man den Hinweis auf den für die Entschlüsselung notwendigen Schlüssel entfernt beziehungsweise erst gar nicht speichert. Beim Empfänger führt dies dazu, dass er jeden einzelnen seiner geheimen Schlüssel ausprobieren muss, in der Hoffnung, dass einer davon passt.

Dies lässt sich von der Kommandozeile aus wie folgt bewerkstelligen:
$ gpg --armor -R 'Anonymer Empfänger <anonymous@example.com>' --encrypt blogsnippet.txt

Wichtig ist hierbei, dass keine Signatur erzeugt wird, also „–sign“ fehlt, da sonst durch Mitschneiden der Nachricht bekannt wäre, wer der Absender ist. Der dazugehörige Abschnitt aus der man page:

       --hidden-recipient name

       -R     Encrypt for user ID name, but hide  the  key
              ID  of this user's key. This option helps to
              hide the receiver of the message  and  is  a
              limited countermeasure against traffic anal‐
              ysis. If this option or --recipient  is  not
              specified, GnuPG asks for the user ID unless
              --default-recipient is given.

Eine solche Nachricht (blogsnippet.txt.asc) sieht dann wie folgt aus:

Der Versuch sie zu entschlüsseln, wenn der passende geheime Schlüssel fehlt, sieht wie folgt aus (IDs unkenntlich gemacht):
$ gpg --decrypt blogsnippet.txt.asc gpg: anonymous recipient; trying secret key 00000000 ... gpg: anonymous recipient; trying secret key 00000001 ... gpg: anonymous recipient; trying secret key 00000002 ... gpg: anonymous recipient; trying secret key 00000003 ... gpg: encrypted with RSA key, ID 00000000 gpg: decryption failed: secret key not available

Vielleicht hat da draußen ja jemand mehr Glück und kann die Nachricht da oben entschlüsseln ;)

Es versteht sich von selbst, dass diese Methode nicht geeignet ist, um in E-Mails benutzt zu werden. E-Mails enthalten Empfänger- und Absenderinformationen (und den Betreff) grundsätzlich unverschlüsselt, es macht also Verschlüsselung nur umständlicher und bringt keinen Sicherheitsgewinn. Wie auch in der man page angesprochen, ermöglicht dies nur eine eingeschränkte Verteidigung gegenüber Verkehrsanalysen. Bei niederfrequenter Kommunikation auf von vielen Nutzern besuchten Diensten dürfte dies allerdings für eine deutliche Erschwerung der Verkehrsanalyse sorgen.