© Ion Chiosea, 123RF

E-Mails sind auf ihrem Transportweg mitlesbar wie Postkarten. Deshalb sollte der Absender sie verschlüsseln. Doch PGP für E-Mails ist eine Qual und deshalb praktisch tot. Welche Alternativen gibt es?

Als Ray Tomlinson 1971 die erste E-Mail der Welt verschickte, konnte er nicht ahnen, welch riesiger Erfolg diesem Medium beschieden sein würde. Heute versenden die Internetnutzer mehr als 260 Milliarden E-Mails pro Tag – Tendenz noch immer stark steigend. Praktisch jede Art von Information wird per E-Mail verschickt: Von einfachen Grüßen bis hin zu streng vertraulichen Informationen. Gerade Letzteres ist allerdings eine Herausforderung. Zwar hat vor allem die IETF die E-Mail immer weiter standardisiert und um neue Features erweitert. Aber implizite Verschlüsselung ist dem Medium bis heute fremd.

Zum Glück gibt es PGP und Gnu PG, die mit Abstand am weitesten verbreitete offene Implementierung von PGP. Auf Basis von Gnu PG und einer entsprechenden Integration in E-Mail-Clients lassen sich Mails vor dem Versenden wirksam verschlüsseln. Problem gelöst? Leider nein: Wer beruflich E-Mails empfängt oder verschickt und schon mal den Versuch unternommen hat, Gnu PG flächendeckend einzuführen, gibt dieses Unterfangen meist schnell wieder auf.

Fast scheint es, als gäbe es eine unsichtbare Allianz gegen PGP und Gnu PG: Clientprobleme, Serverprobleme sowie mangelndes Wissen machen ihren Einsatz oft komplett unmöglich. Dieser Artikel erklärt, warum E-Mail-Verschlüsselung mit Gnu PG de facto gescheitert ist, und beschäftigt sich mit alternativen Wegen, um Informationen dennoch sicher auszutauschen.

Geek-Wissen nötig

Nach dem ersten grundlegenden Problem mit Gnu PG im Zusammenhang mit E-Mails sucht man nicht lange: PGP selbst garantiert zwar sichere Verschlüsselung, ist aber auch sehr komplex. Wer sich als Nutzer mit dem Thema E-Mail-Verschlüsselung beschäftigen will, hat eine steile Lernkurve vor sich: Wie funktioniert asymmetrische Verschlüsselung eigentlich? Was hat es mit privatem und öffentlichem Schlüssel auf sich? Wie greifen beide ineinander? Was haben Alice, Bob und Charlie damit zu tun?

Was aus der Sicht von Geeks, Nerds und gestandenen Admins plausibel und nachvollziehbar ist, stellt unbedarfte Endanwender schnell vor große Verständnisprobleme. Und das Wissen rund um PGP reicht im Grunde ja auch nicht aus. Wirklich sicher kommunizieren kann per PGP nur, wer beizeiten sein eigenes “Web of Trust” aufbaut.

Dazu lässt man sich von potenziellen Kommunikationspartnern deren Schlüssel-ID sowie ihren Ausweis zeigen und bestätigt anschließend per digitaler Signatur, dass der Schlüssel zu der Person gehört, die vorgibt, ihn zu besitzen. Ohne dieses Prozedere ist zwar das Versenden und Empfangen von verschlüsselten E-Mails möglich, aber die zweite wichtige PGP-Funktion – das Signieren, um die Echtheit des Absenders zu verifizieren – bleibt auf der Strecke.

Nutzer erwarten, dass Verschlüsselung in ihen Kommunikationswerkzeugen implizit funktioniert. Die Mühe, das Konzept hinter PGP zu verstehen, machen sich deshalb die meisten gar nicht. Entsprechend gering ist die Zahl der Kundigen. Man frage sich einfach, wann man die letzte mit GPG verschlüsselte E-Mail von einem Nicht-Geek bekommen hat.

Totalausfall: Windows

Macht sich ein Anwender dann doch mal die Mühe, PGP zu durchdringen, so steht er schnell vor dem nächsten Problem: Wie lässt sich die Theorie auf den gängigen Betriebssystemen in die Praxis umsetzen? Der Zustand der PGP-Unterstützung wäre bei den meisten E-Mail-Programmen mit verheerend noch wohlwollend beschrieben. Das verdeutlicht die folgende Bestandsaufnahme.

Zunächst fällt der Blick unweigerlich auf den Betriebssystem-Primus, also Microsofts Windows: Seit Windows 7 kommt dort nicht mehr Outlook Express zum Einsatz, sondern dessen Nachfolger Windows Live Mail. Mit jenem Programm hat sich das Thema PGP schnell erledigt: Microsoft bietet keinen PGP-Support für Windows Live Mail und Plugins von Drittanbietern existieren nicht.

Wer noch ein betagteres Windows mit Outlook Express nutzt, installiert sich GPG4Win [1]: Das bringt alle nötigen Komponenten mit, um einen GPG-Schlüssel anzulegen und für den E-Mail-Verkehr zu nutzen. Zumindest ein bisschen jedenfalls: Bei Microsoft hat man es schließlich nicht für nötig befunden, Outlook mit einer offenen Plugin-Schnittstelle zu versehen. Das GPG4Win-Outlook-Plugin ist so keine sichere Bank, weil es jederzeit zu Fehlfunktionen kommen kann.

Alles halb so schlimm, möchte man denken, schließlich existiert für Windows auch Thunderbird, das mit dem Enigmail-Plugin ([2], Abbildung 1) PGP komplett abdeckt. Mit einem kleinen Schönheitsfehler: Die Mozilla Foundation hat ihren einstigen Klassenprimus in Sachen E-Mail schon vor Jahren offiziell abgekündigt und entwickelt ihn nicht weiter. Anwender müssten sich also ein Softwaremuseum installieren, um verschlüsselte E-Mails mit Windows zu versenden und zu empfangen. Falls sie das überhaupt können: In vielen Unternehmen ist Outlook der Standard.

Abbildung 1: Enigmail bietet PGP-Support in Thunderbird, das Mozilla allerdings schon vor Jahren offiziell abgekündigt hat.

Mit GPG4Win und dem Outlook-Privacy-Plugin lässt sich ein rudimentärer PGP-Support zwar für Outlook bis einschließlich 2016 einbauen, es darf aber bezweifelt werden, dass viele Unternehmen die Outlook-Stabilität auf diese Weise torpedieren wollen (Abbildung 2).

Abbildung 2: Mittels GPG4Win lässt sich Outlook zwar um GPG-Unterstützung erweitern, doch das ist kompliziert und unzuverlässig.

Mac OS: Seufz!

Nicht viel besser gestaltet sich die Integration auf Mac OS. Hier gibt es drei E-Mail-Programme, die erwähnenswerte Verbreitung erreichen konnten: Neben Thunderbird nutzen viele Unternehmen Outlook als Teil des Office-Pakets für Mac OS oder Mail, Apples hauseigenes E-Mail-Programm.

Für Outlook hat sich das Thema PGP-Support auf Macs freilich genauso schnell erledigt, wie es für Windows der Fall ist. Für Mail gibt es indes Hoffnung: Die Software GPG Suite [3] erweitert Apples Mail um Unterstützung für PGP via Gnu PG (Abbildung 3). Ein entsprechendes Gnu-PG-Framework bringt GPG Suite gleich mit, sodass es auch als Basis für das Enigmail-Plugin für Thunderbolt dient, das sich so auf Mac OS ebenso verwenden lässt.

Abbildung 3: GPG Suite erweitert Mail auf Mac OS um GPG-Unterstützung, doch die Entwicklung hinkt der von Mac OS ein gutes Stück hinterher.

Die Sache hat freilich einen Schönheitsfehler: Weil GPG Suite nicht direkt von Apple kommt, wird es auch nicht zusammen mit Mac OS verteilt. Stattdessen müssen die Entwickler der GPG Suite auf neue Mac-OS-Versionen reagieren und für ihr Produkt gegebenenfalls ein Update anbieten. Das kann dauern: Weil die GPG-Suite-Entwickler sich maßgeblich in ihrer Freizeit um das Produkt kümmern, verstreichen zwischen der Veröffentlichung einer Major-Version von Mac OS und dem Erscheinen einer kompatiblen GPG-Suite-Version gerne Wochen und Monate. Und selbst Minor-Updates von Mail können das dortige GPG-Suite-Plugin außer Gefecht setzen. Denn genauso wie Outlook hat auch Mail keine Plugin-Schnittstelle.

Am Ende geht GPG mit Mac OS und Apple zwar irgendwie, doch zufriedenstellend ist dieses Sammelsurium von Technologien nicht. Und zuverlässig damit arbeiten lässt sich aufgrund der genannten Update-Problematik auch nicht. Wer möchte schon auf die Installation wichtiger Betriebssystem-Updates verzichten und so sein System zum Schweizer Käse werden lassen, nur um sichere E-Mail-Kommunikation zu ermöglich?

Linux hat’s drauf

Befriedigend ist die GPG-Unterstützung für E-Mails unter Linux. Kein Wunder: Hier haben Nutzer ein ganzes Füllhorn verschiedener E-Mail-Clients zur Auswahl. Kommandozeilen-Liebhaber kommen ebenso wie die Fans von GUIs auf ihre Kosten. Und die allermeisten E-Mail-Clients unter Linux bieten nativen Support für GPG. Dafür hat die Sache einen anderen Haken: Das Jahr von Linux auf dem Desktop ist zwar seit zehn Jahren endlich da – aber irgendwie auch nicht, der Marktanteil der gängigen Linux-Systeme auf Desktops ist verschwindend klein. Wer GPG mit Linux anbieten kann, findet trotzdem oft keine Partner für die verschlüsselte E-Mail-Kommunikation.

Krampf auch auf mobilen Geräten

Mindestens genauso frustrierend wie auf Mac OS und Windows ist die Situation auf mobilen Geräten. Sowohl auf I-OS als auch auf Android lassen sich zwar mit unterschiedlichen Apps verschlüsselte E-Mails öffnen. Doch die Handhabung vieler GPG-Anwendungen ist ein Krampf. Hinzu kommt, dass man seinen privaten Schlüssel eigentlich nicht auf einem portablen Gerät haben möchte, das gerne auch mal unfreiwillig den Besitzer wechselt. Wer GPG-Verschlüsselung auf Android oder im Apple-Universum auch nur ausprobiert, kehrt dem Thema meist schnell und sehr genervt wieder den Rücken.

Bastelei bei Webmail

Außen vor geblieben sind bei der bisherigen Betrachtung jene Anwender, die für E-Mails gar kein Tool mehr nutzen, sondern auf die Webmail-Anwendungen ihrer Provider zurückgreifen. Für die ist es – groteskerweise – noch mit am einfachsten, GPG zu nutzen: In Form von Mailvelope [4] steht für Chrome wie für Firefox ein Plugin bereit, das im Browser GPG-Funktionalität bietet. Das Produkt basiert auf einer Gnu-PG-Version, die in Javascript verfasst ist, und lässt sich auch auf Chrome OS und ähnlichen Systemen nutzen (Abbildung 4). Doch ist auch bei Mailvelope nicht alles Gold, was glänzt: Nutzer berichten regelmäßig von Abstürzen und Hängern, die ihnen die PGP-Verschlüsselung verleiden.

Abbildung 4: Mittels Mailvelope ist PGP-Support auch für die Nutzer von Webmail möglich, wie man am Beispiel von Gmail gut erkennen kann.

Das Zwischenfazit ist ernüchternd: PGP-Verschlüsselung gehört bei keinem am Markt etablierten E-Mail-Programm zum Lieferumfang. Entweder steht es gar nicht erst zur Verfügung oder es muss mittels kruder Plugins nachgerüstet werden, die sich oft genug negativ auf die Stabilität und Performance der Programme auswirken. Entsprechend unbeliebt sind sie.

Kollateralschaden auf dem Transportweg

Selbst wenn zwei Nutzer funktionierende Mailclients mit Unterstützung für PGP-Verschlüsselung haben, ist das keine Garantie dafür, dass der Austausch von verschlüsselten Daten tatsächlich funktioniert. Wenn in der Kette der Mailserver, die die E-Mail unterwegs verarbeiten, nämlich ein Exchange-Server ist, dreht dieser die PGP-verschlüsselte E-Mail kurzerhand durch den Wolf.

Grundsätzlich gibt es zwei Methoden, eine E-Mail mit PGP zu verschlüsseln: Bei der ersten Variante verändert der ausführende PGP-Client – meist also Gnu PG – den Body der E-Mail, sodass darin letztlich der verschlüsselte Text steht. Diese Inline-Variante ist allerdings seit über zehn Jahren offiziell als “deprecated” eingestuft. Den Vorzug erhält eine andere Methode: Dabei ist der Mailclient des Absenders aktiv involviert. Denn sobald der Nutzer für die jeweilige E-Mail die Verschlüsselung aktiviert, verschickt der Mailclient eine Mail mit leerem Text und die eigentliche – verschlüsselte – E-Mail hängt er als Attachment mit entsprechendem MIME-Type (»application/pgp-encrypted«) an diesen leeren Body an. Das PGP/MIME-Verfahren gilt als gegenwärtiger Standard.

Exchange jedoch versteht sich bekanntlich nicht als schnöder Mailserver, sondern vielmehr als Groupware-Lösung, bei der die Emulation von SMTP für den Austausch mit anderen Mailservern nur eine von vielen Funktionen ist. Bei E-Mails mit PGP-Anhängen fackelt Exchance deshalb nicht lange und formatiert sie einfach um: Am Ende hat die E-Mail den MIME-Typ »multipart« und die ursprüngliche, verschlüsselte E-Mail hängt als eines von mehreren Attachments mit falschem MIME-Typ dran (Abbildung 5). Viele Mailclients erkennen den Unsinn mittlerweile und stellen den PGP-Teil der E-Mail trotzdem korrekt dar. Voraussetzen sollte man das aber nicht.

Abbildung 5: Bekommt ein Exchange-Server eine GPG-verschlüsselte E-Mail in die Finger, schreddert er sie nach allen Regeln der Kunst.

Damit ist klar: Exchange boykottiert die Nutzung von PGP-Verschlüsselung aktiv und formatiert die E-Mails entgegen dem gültigen Standard um. Das Beste kommt jedoch erst noch: Das Verhalten lässt sich Exchange auch nicht abgewöhnen. Stattdessen sind kryptische Fehlermeldungen das Resultat, sie verwirren den ohnehin kaum technikaffinen Anwender noch zusätzlich.

Gerade im Businessumfeld gerät PGP-Verschlüsselung jedoch noch aus einer Ecke unter Beschuss, aus der man im ersten Moment gar keine Probleme erwartet hätte. Qua Gesetz gelten E-Mails, die etwas mit einem laufenden Vertrag zu tun haben oder die dessen Abschluss dienen, nämlich als aufbewahrungspflichtige Dokumente. Eine Firma ist also gehalten, solche Dokumente über Jahre hinweg zu archivieren und auf Verlangen in lesbarer Form auszuhändigen, und zwar auch dann, wenn der ursprünglich verfassende Mitarbeiter gar nicht mehr im Unternehmen beschäftigt ist.

Daraus folgt, dass Firmen ihre Mitarbeiter eigentlich zwingen müssten, ihren privaten PGP-Schlüssel samt Passwort für den Fall der Fälle herauszugeben. Eine solche Praxis widerspräche jedoch in grundlegender Weise dem Funktionsprinzip von PGP und zusätzlich auch der Idee des Web of Trusts.

Was tun?

Die komplexe Gemengelage in Sachen Mailclient mit PGP-Unterstützung und der unsägliche Exchange-Unsinn liefern gute Anhaltspunkte dafür, warum sich PGP-Verschlüsselung bis heute nicht flächendeckend durchgesetzt hat. Und weil kaum damit zu rechnen ist, dass die Hersteller ihren Mailclients plötzlich PGP-Support spendieren, ist die traurige Feststellung: Echte Ende-zu-Ende-Verschlüsselung mit PGP für E-Mails ist praktisch tot – der Krampf, den die Umsetzung erfordert, ist unzumutbar.

Das ändert aber nichts an der Notwendigkeit, vertrauliche Informationen verschlüsselt auszutauschen. Welche Alternativen stehen zur Verfügung, um das zu tun? Die Antwort auf diese Frage hängt auch davon ab, ob die E-Mail als Transportmedium gesetzt ist oder ob andere Protokolle und Werkzeuge zum Einsatz kommen können.

Ein möglicher Ansatz für PGP-Support besteht darin, dem eigenen Mailserver ein PGP-Gateway voranzustellen. Die gesamte Verschlüsselung bleibt dabei vor den Augen der Nutzer versteckt. Stattdessen leitet der Mailserver alle E-Mails an einem entsprechenden weiteren Server vorbei, der die GPG-Signaturen oder die Verschlüsselung entsprechend vornimmt – oder vorhandene Signaturen auf ihre Echtheit hin überprüft und verschlüsselte E-Mails entschlüsselt.

Diese Lösungen sind komfortabel: Sie bieten ein grafisches Managementwerkzeug und erlauben es, die PGP-Konfiguration fein granuliert vorzunehmen. Mit ihnen lässt sich PGP auch dort nutzen, wo es sonst unmöglich wäre, etwa bei Ticketsystemen, die von Haus aus PGP nicht unterstützen. Sogar das beschriebene Problem im Hinblick auf gesetzliche Aufbewahrungsfristen umgehen diese Lösungen: Weil die PGP-Schlüssel der Mitarbeiter ohnehin zentral hinterlegt sind, muss sich ein Unternehmen keine Sorgen um den Zugriff auf verschlüsselte Daten machen.

Die Strecke, die die E-Mail vom Mailprogramm des Nutzers bis zum beschriebenen Verschlüsselungsgateway zurücklegt, ist aber unverschlüsselt. Setzt also ein Angreifer bereits hier an, erhält er Mails im Klartext. Und das ist nicht der einzige Schönheitsfehler dieses Ansatzes.

Denn im PGP-Kontext ist es nach allgemeiner Lehre sehr wichtig, dass jedem digitalen Schlüssel ein einzelner Nutzer zugeordnet ist, der exklusiv Zugriff auf den jeweiligen privaten Schlüssel hat. Genau das ist bei dieser Lösung aber eben nicht der Fall. Denn die Mitarbeiter selbst haben auf den Schlüssel ihres PGP-Key im genannten Szenario gar keinen Zugriff. Wer den Gateway für Verschlüsselung kontrolliert, hat dagegen vollen Zugriff auf alle Daten.

Was im Unternehmen möglicherweise noch akzeptabel ist, macht PGP für private Anwendungszwecke völlig uninteressant. Zumal Verschlüsselungsgateways gerne Preise aufrufen, die private Anwender kaum bezahlen wollen.

Andere Kommunikations-wege

Wenn es lediglich um den schnellen und verschlüsselten Austausch von Text geht – also um Chats und dergleichen –, ist das Medium E-Mail nicht zwingend notwendig. Hier haben sich am Markt mehrere Alternativen etabliert: Jabber mit Client-seitiger OTR-Verschlüsselung sowie Instant-Messaging-Programme wie Signal oder Threema.

Von besonderer Bedeutung ist dabei, dass es sich um eine Lösung mit echter Ende-zu-Ende-Verschlüsselung handelt. Das heißt, dass der versendende Client den Inhalt der Kommunikation mit dem öffentlichen Key des anderen Gesprächsteilnehmers verschlüsselt. Mit dessen privatem Schlüssel kann der die Entschlüsselung vornehmen und den Text lesen. Jeder, der die Nachricht unterwegs abfängt, sieht nur Datensalat.

Wer auf Jabber mit OTR-Verschlüsselung setzt, hat auf Mac OS Adium oder auf Linux-basierten Systemen Pidgin mit OTR-Plugin als Client. Dieses Gespann ist in der Lage, Ende-zu-Ende-Verschlüsselung zu bieten. Conversation für Android ist ebenfalls OTR-fähig. Die Kombination von festem und stationärem Client mit OTR ist allerdings wenig komfortabel: Verschlüsselte Nachrichten des Computers kann das Smartphone nicht entschlüsseln und vice versa.

Wer also ein Gespräch am Computer mit OTR-Verschlüsselung beginnt und unterwegs fortsetzen will, läuft Gefahr, dass sich die beiden OTR-Clients ins Gehege kommen. Das immerhin lässt sich durch händisches Deaktivieren der OTR-Funktion auf dem einen oder dem anderen Gerät verhindern.

Programme wie Whatsapp, Threema oder Signal sind komfortabler – verrichten ihren Dienst aber nur auf mobilen Geräten. Zwar existieren sowohl für Signal als auch für Whatsapp Desktop-Schnittstellen, diese lassen sich aber nur mit einem Webbrowser nutzen.

Besondere Vorsicht ist bei Skype geboten: Das behauptet zwar, dass es umfassende Verschlüsselung beherrscht. Nach der Übernahme durch Microsoft hat Skype allerdings einen komplett neuen Crypto-Unterbau bekommen, der deutlich schwächer ist als jener der Vorversion. Denn die neue Implementierung beherrscht keine Ende-zu-Ende-Verschlüsselung mehr. Auf den Microsoft-Servern liegen also sowohl Chats als auch die Daten aus Anrufen oder Videogesprächen im Klartext. Für vertrauliche Kommunikation ist Skype so nicht geeignet.

Ähnliches gilt für andere Dienste, die meist auf HTTPS basieren: Hier sind zwar die Transportwege verschlüsselt, aber beim Anbieter – etwa Slack oder Hip Chat – liegen alle Daten im Klartext vor.

Verschlüsselte Dateien

Signal & Co. sind für verschlüsseltes Instant-Messaging gut geeignet. Zum Teil unterstützen sie auch den Austausch von Dateien; diese Funktion ist in der Regel jedoch auf bestimmte Inhalte beschränkt, etwa auf Bilder. Wer in großem Umfang verschlüsselte Dateien zur Verfügung stellen möchte, wird das in der Regel auch nicht per Smartphone tun wollen. Tatsächlich nutzen viele Unternehmen für diese Aufgabe heute zentrale Storage-Dienste wie Google Drive oder Dropbox. In Unternehmen verbietet sich dieser Ansatz aber meist, oft schon aus Compliance-Gründen.

Welche Möglichkeiten gibt es also, Dateien sinnvoll verschlüsselt anzubieten? Zunächst besteht die Möglichkeit, auf Google Drive oder ähnlichen Diensten ein verschlüsseltes Volume zu hinterlegen und anderen den Zugriff auf das Volume zu ermöglichen. Veracrypt ist dafür eine gute Option: Sowohl für Windows als auch für Mac OS und für Linux steht das Programm bereit. Diese Lösung ist zumindest universell nutzbar, ob sie in Sachen Usability so viel besser ist als PGP-Verschlüsselung für E-Mails muss der Anwender entscheiden.

Wer die Möglichkeit hat, selbst einen Server zu hosten, greift alternativ auf Owncloud oder Nextcloud zurück. Die laufen auf einem normalen Ubuntu, das bei Bedarf auch verschlüsselte Blockgeräte bietet. Wenn sichergestellt ist, dass der Zugriff auf die Speicherlösung nur per HTTPS-Protokoll erfolgt, ist dieser Weg komplett: Die Daten liegen auf einem Server, der unter der eigenen Kontrolle steht, und werden nur auf verschlüsselten Übertragungswegen verteilt.

Echte Ende-Zu-Ende-Verschlüsselung ist das aber auch nicht: Bricht in den aktiven Server jemand ein, hat er dort Zugriff auf die Daten im Klartext. Entschädigt werden Anwender dieser Lösung immerhin durch eine umfassende Riege an Clients für mobile wie stationäre Systeme.

Wer Owncloud oder Nextcloud nicht traut, findet am Markt eine große Menge kommerzieller Lösungen mit ähnlicher Funktionalität: Je nach gewählter Option und gegen Einwurf entsprechend vieler Münzen bieten jene Lösungen ganz ähnliche Funktionen. Aber eine sorgfältige Marktanalyse sowie die genaue Evaluation verschiedener potenzieller Lösungen anhand der eigenen Anforderungen ist unbedingt notwendig.

Fazit

Das Thema PGP-Verschlüsselung für E-Mails ist damit erledigt: Zu komplex ist PGP selbst, zu gering ist die Bereitschaft der Hersteller, die Lösung zu nutzen, und zu gering ist entsprechend die Benutzerbasis. Eigentlich schade, denn PGP-verschlüsselte E-Mails wären eine einfache und dennoch absolut sichere Möglichkeit, vertrauliche Informationen über ein standardisiertes Protokoll auszutauschen. Und echte Ende-zu-Ende-Verschlüsselung gehört bei PGP ebenso zum Lieferumfang. Doch wenn sich keine Kommunikationspartner finden und am Ende eigentlich unbeteiligte Dritte – nämlich kaputte Exchange-Server – das Prinzip torpedieren, hilft der schönste Standard nicht.

Wer dennoch verschlüsselt Text austauschen will oder muss, der greift als Alternative am besten zu einer der zahlreichen Chat-Lösungen, die wie PGP echte Ende-zu-Ende-Verschlüsselung bieten. Ein genereller Ratschlag für den verschlüsselten Austausch von Dateien ist leider unmöglich. (jcb)