Folgen (bei alten PGP-Keys) des zwingenden MDC Integritätsschutz seit Enigmal 2.0.5

Das ist eine Folge von EFail bzw. dem verbesserten Schutz davor. In den Release-Notes, die im Thunderbird auch angezeigt wurden, ist zu Enigmail 2.0.4 vermerkt:

Zitat

2. a workaround that stops decrypting PGP messages using old algorithms like CAST5 that are not MDC-protected

Das besagt aber auch, dass die E-Mails zuvor nicht mit AES sondern z.B. mit CAST5 verschlüsselt wurden. Der Algorithmus selbst gilt immer noch als sicher. Dessen Verwendung entspricht aber meines Wissens nicht den Standardeinstellungen von Enigmail sondern wurde wahrscheinlich durch den Benutzer festgelegt.

Sinnvoll ist hier, Änderungen an Konfigurationsdateien stets gut und mit Datum zu kommentieren.

Übersehen:

Zitat von Hanisch

Wie stelle ich ein, daß ich den Betreff nicht verschlüsseln will?

Eingmail-Einstellungen, Tab Erweitert.

Einige Erläuterungen, mit meinem Wissenstand dazu, der aber auch in den Jahren angelesen ist und daher teilweise aus dem Gedächtnis kommt:

Die Frage, welches symmetrische Verfahren für die Verschlüsselung Verwendung findet, entscheidet sich anhand der Präferenzen von Sender und Empfänger. Man kann sie zu jedem Schlüssel überprüfen

gpg2 --edit-key keyid showpref

Für einen alten, abgelaufenen Key von Werner Koch aus 1998 erhalte ich damit

Verschlü.: AES256, AES192, AES, CAST5, 3DES     
    Digest: SHA1, RIPEMD160     
    Komprimierung: ZLIB, ZIP, nicht komprimiert     
    Eigenschaften: MDC, Keyserver no-modify

Das fast gleiche Ergebnis erhalte ich für den aus 2006 stammenden aber gültigen Schlüssel des BSI für die Buerger-CERT Signatur. Dort ist ganz am Ende noch IDEA aufgenommen.

Neuere Schlüssel zeigen lediglich eine Änderung beim Digest.

Verschlü.: AES256, AES192, AES, CAST5, 3DES, IDEA
     Digest: SHA256, SHA1, SHA384, SHA512, SHA224
     Komprimierung: ZLIB, BZIP2, ZIP, nicht komprimiert
     Eigenschaften: MDC, Keyserver no-modify

Es spricht somit vieles dafür, dass die Reihenfolge in den Standardeinstellung in GnuPG bereits seit vielen Jahren AES256, AES192, AES, CAST5, 3DES lautet. Vielleicht war das PGP anders.

Beim Senden einer verschlüsselten E-Mail werden die Präferenzen des Empfängers mit denen des Absenders verglichen, um den besten gemeinsamen Algorithmus zu finden. Sofern nichts verändert wurde, wäre das vermutlich schon seit mindestens 1998 AES256 und kein alter Algorithmus wie CAST5.

Zitat von Hanisch

Von welchem Programm wird das ausgeliefert, wann und durch wen wird diese gpg.conf angelegt?

Die gpg.conf ist nicht zwingend erforderlich. Sie ist optional. Die wichtigsten Einstellung sind hart verdrahtet. Die gpg.conf wird nur benötigt, wenn man Standardeinstellungen verändert. Das kann über die Kommandozeile geschehen oder über graphische Oberflächen wie GPA oder Pinentry.

Ferner kann man über "--options filename" auch eine ganz andere Datei als Konfig-Datei angeben. Schlussendlich erlaubt Windows auch, die Einstellungen nicht nur für einen Benutzer sondern z.B. auch für alle festzulegen.

Ohne Einblick auf das konkrete Systems und die Historie ist es aus Ferne schwer zu beurteilen, welche Änderungen vorgenommen wurden und welche Konfiguration überhaupt greift.

Zitat von Thunder

Ich denke, dieses Thema könnte die Lösung sein:

Die Lösung ist es nicht in allen Fällen. Es beschreibt aber die Ursache, die wie gesagt darin liegt, dass Enigmail zum Schutz vor Efail nun auf MDC kontrolliert. Wie es in den Release Notes steht. GnuPG unterstützt das seit 17 Jahren. Ich meine, Patrick schreibt zurecht:

Zitat

and in the light of the severe weaknesses that have been discovered, it's about time to enforce it. We (the OpenPGP community) should have done this already many years ago.

Es gibt mehrere Wege, das Problem zu lösen.

1. Bei Enigmail entscheidet man sich, E-Mails ohne MDC nach einer entsprechenden Warnung doch noch zu entschlüsseln. Das kann dann frühestens in einer der nächsten Versionen der Fall sein.
2. Man entschlüsselt alte E-Mails ohne MDC noch mit einer 1.9.x und speichert die E-Mails entschlüsselt ab. Wem es wichtig ist, die Mails weiterhin verschlüsselt abzuspeichern, der kann die Mails entweder erneut verschlüsseln oder auf einer verschlüsselten Partition speichern.

Wer CAST5 oder 3DES verwendet hat, sollte die Gelegenheit nutzen und darüber nachdenken, seine Schlüssel anzupassen und neu zu verteilen. Bei einer alten Version zu bleiben, nur um weiterhin mit veralteten Algorithmen zu verschlüsseln, ist nicht zu empfehlen. Das ist ja Vogel-Strauß-Verhalten.

Zitat von Hanisch

basta!

Das hätte ich gleich für den ersten Beitrag gewünscht. Dann hätte ich Bescheid gewusst und mir Zeit sparen können, die ich auch nicht im Überfluss habe. Solche Argumente signalisieren mir Desinteresse an Erklärungen und der Lösung. Da steige ich aus.

In der Zwischenzeit kam ein neuer Beitrag von Thunder rein, der die genannten Optionen ebenfalls auflistet. Sorry für das doppelte Posting.

Kein "normaler" Nutzer wird das verstehen.

Enigmail ist schon ein wenig benutztes Nischenprodukt, das wird wohl so bleiben bzw. sich verschärfen, wenn man die Anwender derart vor den Kopf stößt. Die wollen funktionierende Software und nicht kryptische Befehle auf der Kommandozeile eintippen.

Zitat von Hanisch

Ich will alle meine verschlüsselte e-Mails von heute und von vor Jahren unkompliziert lesen können (...)

Kann ich gut verstehen. Wichtige Mails (sonst wären sie ja wohl nicht verschlüsselt) plötzlich nicht mehr bzw. nur mit großem Aufwand lesbar?

Ich hoffe mal, daß sich Patrick das überlegt und es bald eine echte Lösung gibt.

Grüße, muzel

Vorhin wollte ich in meinem Beitrag noch erwähnen, dass ich über die Komplexität, die sich hier zeigt, enttäuscht bin, weil einige Freunde und ich seit Jahren versuche, andere zur Verschlüsselung zu bewegen.

Ich habe es dann wieder gelöscht, weil ich festgestellt habe, dass die Aussage in dieser Form nicht stimmt.

Efail und vor allem die in den ersten Stunden hektische, unsachliche und teilweise falsche Darstellung in den Medien, haben sicherlich Schaden angerichtet. Der wird sich möglicherweise nicht so schnell wieder gutmachen lassen.
Verschlüsselung ist dadurch aber weder schwieriger geworden noch ist unsicher.

In einem ersten Gedanken war ich zunächst auch der Meinung, Enigmail sollte eine Funktion erhalten, nach Bestätigung auch E-Mails zu entschlüsseln, die MDC nicht unterstützen.
Inzwischen bin ich zu dem Schluss gekommen, dass es besser wäre, eine solche Funktion nicht zu implementieren.

Was sind meine Gründe?

Die Änderung in Enigmail dienen der Sicherheit der Verschlüsselung. Efail ist nicht wirklich neu. Ähnliche Angriffe wurden bereits in der Vergangenheit durchgeführt. Deshalb hat GnuPG bereits vor 17 Jahren MDC eingeführt. Der Rest der Community hat leider nicht darauf reagiert.

Jemand, der wirklich so vertrauliche Dokumente per E-Mail versendet, die eine sichere Verschlüsselung zwingend erforderlich machen, der sollte so gut es geht geschützt werden. Enigmail sollte deshalb keine alten, unsichereren Verfahren unterstützen.

Wenn Enigmail die Verwendung von Nicht-MDC-Algorithmen wie CAST5 und 3DES weiterhin erlauben würde, dann werden vermutlich weitere 17 Jahre vergehen, bis diese Algorithmen endlich verschwunden sein werden. Wenn überhaupt.

Dieser Faden bestätigt das. Betroffen sind nur Anwender, die oder deren Mailpartner es in all den Jahren nicht geschafft haben, Schlüssel zu verwenden, die MDC unterstützen.

Ich kann den Ärger um den nun erforderlichen Aufwand gut verstehen. Trotzdem, es ist ein Widerspruch einerseits Vertraulichkeit und Sicherheit zu erwarten, andererseits aber so alte und angreifbare Verfahren einzusetzen. Wenn es die Sicherheit nicht Wert ist, endlich auf geeignete Verfahren umzusteigen, dann kann der Bedarf an Vertraulichkeit nicht so hoch sein.