eine etwas andere zusammenfassung

[Anonymer Nutzer]

mal meine version der klarstellung.

* gnupg und opengpg wurden beide nicht geknackt. beide enthalten keinen fehler.

* mdc schützt nachgewiesen. das geben auch die autoren des papers zu. tatsache ist, dass sie ganz explizit diese sicherheitsmaßnahme, die gnugp bei aes verschlüsselten email verlangt, in ihrem paper ausgeschlossen haben. gnupg bricht mit einem fehler ab. eine sicherheitsmaßnahme auszuschließen, würd bedeuten, dass man auch tls 1.3 angereifen kann, wenn clients die zertifikate nicht prüfen. ist deshalb tls 1.3 geknackt? offensichtlich nein, sondern nur falsch verwendet.

* _manche_ email programme ignorieren den fehler von gnupg und sind deshalb dahingehend zu fixen. gnupg kann nichts dafür, wenn andere programme fehler ignorieren.

* gnupg kann definitiv nichts dafür, wenn email programme ohne jeden ersichtlichen grund, mime parts verbinden. es ist einfach ein bug in den email programmen.

* alle diese bugs können in meinen augen leicht gefixt werden. die aussage des autors des papers, es ginge nicht, kann ich nicht im geringsten nachvollziehen.

* es wurde von den autoren des papers mit absoluter absicht sowohl in den tweets als auch im titel des papers suggeriert, dass gnupg oder opengpg hier fehler enthielten. dies entspricht nicht der wahrheit.

* golem hat bei den amd bugs massiv dagegen geredet und hätte dann zugeben müssen, dass die bugs sehr wohl existieren. hier hat golem einfach den autoren nachgeblabbert, ohne selbst zu recherchieren. das gleiche gilt für heise. auch den anderen großen medien muss man hier die schuld geben, dass nicht anständig recherchiert wurde. keiner hat hier den hausverstand mal angeschalten und kurz überlegt, ob eine kleine fh aus deutschland wirklich besser ist als die nsa, die gnupg nicht knacken hatte können. war es ein zu großer hura-patreotismus, in deutschland vermeintlich etwas geschafft zu haben, was die große nsa nicht konnte? ein wichtiger journalistischer grundsatz darf bleiben, dass man nachrichten auf glaubwürdigkeit hin prüft und skeptisch bleibt. vor allem, wenn etwas derart mediengrecht dargestellt wird. wieso wurde das bei den amd lücken getan, hier aber nicht?

* ich muss noch einen kommentator aus dem forum hier erwähnen, der das opengpg bashing nicht lassen kann. grundsätzlich hat er nicht unrecht, aber auch nicht recht. wie die autoren ignoriert er, dass gnupg seit 2015 mdc zwingend für aes verlangt. dh, gnupg liefert seit drei jahren einen fehler zurück und nicht nur eine warnung. mdc ist auch nicht geknackt worden und schützt vor einer der beiden sicherheitslücken zuverlässig. mit welchem algorithmus etwas verschlüsselt wird, bestimmt nicht der angreifer. dh, es gibt keine downgrade attacken auf 3des oder ähnliches, bei denen gnupg keine mdc verlangt. in den letzten 15 jahren sollten so gut wie alle mit gpg verschlüsselten emails standardmäßig mit aes verschlüsselt gewesen sein.

ich finde es schade, dass immer wieder versucht wird, verschlüsselungstechnologien schlecht zu machen. leider passiert das sehr oft. dnssec und hpkp sind ein andere beispiele. meistens liegt es daran, dass sich selbsternannte sicherheitsexperten eine umfassende lösung erwarten, die alles in einem fixt, was aber offensichtlich nicht möglich ist. sicherheit ist aktuell immer ein flickenteppich. das ist eine tatsache, die man akzeptieren lernen muss. oder man vernadert halt jede teillösung als fehlerhaft, weil sie ja problem X nicht fixt.
tatsache ist auch, dass wir bezüglich sicherheitstechnologien eine große menge an werkzeugen haben, die aktuell aber nicht überall alle eingesetzt werden. die welt wärer definitiv it-sicherer, würden wir alle diese existierenden technologien einsetzen.



1 mal bearbeitet, zuletzt am 15.05.18 09:13 durch bjs.

[Mingfu]

bjs schrieb:
--------------------------------------------------------------------------------
> * gnupg und opengpg wurden beide nicht geknackt. beide enthalten keinen fehler.
>
> * mdc schützt nachgewiesen. das geben auch die autoren des papers zu. tatsache
> ist, dass sie ganz explizit diese sicherheitsmaßnahme, die gnugp bei aes
> verschlüsselten email verlangt, in ihrem paper ausgeschlossen haben. gnupg bricht
> mit einem fehler ab.

Falsch. Es gibt einen Fehlercode zurück, nachdem es den entschlüsselten Klartext herausgereicht hat. Statt als verantwortliches Sicherheitsprogramm in solchen Fällen die Entschlüsselung zu verweigern, tut es also so, als würde alles normal laufen und sagt, nachdem die Sache praktisch schon erfolgreich beendet ist, dass die Entschlüsselung angeblich gescheitert wäre.

Wobei es dem jeweiligen Aufrufer überlassen ist, die Fatalität des Fehlers zu erkennen, den GnuPG gerade begangen hat. Denn die Sicherheit gegen Orakelangriffe hängt dann nur noch davon ab, dass der Aufrufer nicht den gleichen Fehler macht wie GnuPG und ebenfalls erst einmal das Ergebnis rausreicht und dann höchstens hinterherschiebt, dass damit irgendwas nicht stimmt.

[Anonymer Nutzer]

ha, auf genau dich hab ich gewartet. :-) ich seh das eben anders. wenn ein programm einen fehler zurück gibt, gibt es einen fehler zurück.

noch ein beispiel, um meine sicht der dinge zu verdeutlichen: denk dir, du kopierst etwas mit rsync. rsync beginnt jetzt zu arbeiten und scheitert aber an ein paar dateien. wegen was auch immer. rsync gibt dann einen fehlercode zurück und sagt damit "da hat was nicht so funktioniert wie gewollt". ist jetzt rsync fehlerhaft, weil es einen teil der aufgabe schon gemacht hat und den fehlercode erst später zurückgibt? ist es für dich dann ok, den fehlercode von rsync einfach zu ignorieren? mit dem argument, rsync hat ja was gemacht, also muss es passen. fehlercodes von programmen sind immer zu prüfen. ruft man ein programm auf, das einen fehlercode zurückgibt, so ist der aufruf als ganzes als fehlgeschlagen zu erachten. deine sicht der dinge mag eine andere sein, aber sie ist bei weitem nicht die einzige und auch nicht die beste.



2 mal bearbeitet, zuletzt am 15.05.18 09:58 durch bjs.

[Mingfu]

Mein Browser gibt auch auf fast jeder Website unzählige Fehlermeldungen in der Konsole aus. Was soll man dann aber mit dieser Information anfangen? Kann man diese Fehlermeldung ignorieren? Sollte man sie zumindest mitloggen? Sollte man den Nutzer sichtbar informieren? Sollte man ihn gar fragen, wie er damit zu verfahren gedenkt? Oder sollte man die gerade erhaltenen Daten sofort verwerfen und keinesfalls irgendwo verwenden?

Sollte es auf letzteres hinauslaufen, dann ist das ein hochgefährliches Szenario, wenn umfangreiche Sicherheitsannahmen nur noch darauf gründen, dass jemand Externes, der vermutlich gar keinen Einblick in all die impliziten Sicherheitsannahmen des Programmes hat, dort die Gefährlichkeit der Situation erkennen und sich unbedingt für die einzig richtige Fehlerbehandlungsalternative entscheiden muss. Zumal die eben nicht einmal naheliegend ist, weil die eigentliche Entschlüsselung augenscheinlich zunächst funktioniert und Daten ausgibt, die durchaus darstellbar sind.

Da hat man als Sicherheitsprogrammentwickler etwas falsch gemacht, wenn man das, wozu man selbst nicht in der Lage ist, nämlich die Ausgabe kompromittierter Informationen zu verhindern, auf den Aufrufer des Programms verlagert.

[Anonymer Nutzer]

du definierst dir die dinge aber halt auch sehr stark so zusammen, dass die aussage raus kommt, die du haben willst: gnupg und opengpg sind mist. das halte ich einfach für zu vereinfachend.

[larix]

Das Mailprogramm macht das genau das selbe: Es zeigt den Inhalt und die Fehlermeldung an.
Wieso ist das bei GnuPG nun OK, beim Mailprogramm aber nicht?
Zumal es die Aufgabe des Mailprogramms ist, den Inhalt der Mail anzuzeigen und gegebenenfalls zu interpretieren, was es auch fehlerfrei tut.
Aufgabe von GnuPG hingegen ist es, die Kommunikation abzusichern und gerade dieses Programm liefert problematischen Inhalt an das Mailprogramm.

Dein Dateimanager zeigt doch die übertragenen Dateien auch trotz der Fehlermeldung an und verhält sich somit exakt wie das Mailprogramm.

Von einem Programm, das für vertrauliche Kommunikation da ist, erwartet man einfach keine Ausgabe, die genau das Gegenteil bewirkt.
Und korrekt abgefangen werden soll dies dann von einem Programm, das mit dieser vertraulichen Kommunikation nur sehr am Rande was zu tun hat?

[joo]

bjs schrieb:
--------------------------------------------------------------------------------
> ich finde es schade, dass immer wieder versucht wird,
> verschlüsselungstechnologien schlecht zu machen. leider passiert das sehr
> oft. dnssec und hpkp sind ein andere beispiele. meistens liegt es daran,
> dass sich selbsternannte sicherheitsexperten eine umfassende lösung
> erwarten, die alles in einem fixt, was aber offensichtlich nicht möglich
> ist. sicherheit ist aktuell immer ein flickenteppich. das ist eine
> tatsache, die man akzeptieren lernen muss. oder man vernadert halt jede
> teillösung als fehlerhaft, weil sie ja problem X nicht fixt.
> tatsache ist auch, dass wir bezüglich sicherheitstechnologien eine große
> menge an werkzeugen haben, die aktuell aber nicht überall alle eingesetzt
> werden. die welt wärer definitiv it-sicherer, würden wir alle diese
> existierenden technologien einsetzen.

+1!

Zum einen wird sich beklagt, dass Endnutzer keinen Wert auf Sicherheit legen und existierende Lösungen nicht nutzen, weil die Thematik zu kompliziert ist. Zum anderen werden laufend schon ganz gute, wenn auch nicht perfekte Produkte von Fachleuten so schlecht geredet, dass alle glauben es sei eh alles nutzlos. Die Katze beißt sich in den Schwanz... Eine etwas differenziertere Sicht und Berichterstattung wäre bei solchen Themen wünschenswert.