1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › PGP/SMIME: Angreifer können sich…

Angaben zu MDC im Artikel ungenau/irreführend

  1. Thema

Neues Thema Ansicht wechseln


  1. Angaben zu MDC im Artikel ungenau/irreführend

    Autor: chithanh 14.05.18 - 23:11

    Auf die Tatsache, dass bei einem MDC-Fehler/-Fehlen dennoch entschlüsselte Daten ausgegeben werden nimmt Werner Koch in seinem Mailinglistenpost von heute morgen ausdrücklich Stellung. Hier hätte auch Golem differenziert berichten können.

    > When giving a filename on the command line an output file is even not created. This can't be done in pipe mode because gpg allows to process huge amounts of data.

    Wenn GPG auf Dateien operiert, wird bei einem MDC-Fehler genau garnichts ausgegeben. Nur wenn auf eine Pipe ausgegeben wird, kann prinzipbedingt ein auftretender Fehler jeglicher Art bereits ausgegebene Daten nicht zurückrufen. Alternativ müsste GPG den ganzen Datenstrom puffern, was andere Nachteile hat. Wenn sich der MUA für den Pipe-Modus entscheidet, musse er die Fehlermeldungen unbedingt beachten, bevor er die Daten weiterverarbeitet.

  2. Re: Angaben zu MDC im Artikel ungenau/irreführend

    Autor: Mingfu 14.05.18 - 23:41

    Die Begründung ist wirklich mal "speziell": GnuPG kann bei Ausgabe im Pipe-Modus also die Nachricht nicht puffern, weil die viel zu groß sein könnte für eine Pufferung. Das aufrufende Programm dagegen muss die Nachricht puffern und zurückhalten, weil man es über einen Entschlüsselungsfehler erst im Nachhinein informieren kann...

    Wobei dann GnuPG grundsätzlich ein Sicherheitsproblem hat, weil anzunehmen ist, dass dann auch im Dateimodus die Datei zunächst geschrieben wird und erst anschließend wieder eine Löschung erfolgt, wenn sich herausstellt, dass der MDC nicht passt. Aber insbesondere auf SSDs oder Flashspeichern bekommt man einmal geschriebene Daten eben nicht mehr zuverlässig gelöscht.

    Wenn man mit so großen Nachrichten rechnet, dass eine Pufferung zur Entscheidung über die Datenintegrität nicht möglich ist, wäre vielleicht ein Protokoll ganz gut, welches die Datenintegrität in kleineren Blöcken prüfen kann, so dass nur Daten ausgegeben werden, deren Integrität auch sichergestellt ist.

  3. Re: Angaben zu MDC im Artikel ungenau/irreführend

    Autor: chithanh 15.05.18 - 01:15

    Das ist doch kompletter Unsinn was du da schreibst.

    Das aufrufende Programm bekommt so oder so die komplette Nachricht (es sei denn, es piped sie lediglich weiter, in dem Fall sollte es auch Fehlermeldungen weiterleiten). GnuPG braucht sich aber lediglich um den aktuellen Block sowie den Zustand seiner Hashfunktion zu kümmern.

    Und die Datei brauchen nicht "sicher" gelöscht zu werden, nur halt am Ende nicht verschoben in den spezifizierten Ausgabepfad um eine Weiterverarbeitung effektiv zu unterbinden.

    Wenn du die Datenintegrität in kleinen Blöcken prüfen willst (d.h. jeder Block einzeln signiert), dann ist am Ende die Größe der Signatur in O(n) was in vielen Fällen nicht praktikabel ist.

  4. Re: Angaben zu MDC im Artikel ungenau/irreführend

    Autor: Mingfu 15.05.18 - 05:51

    Wenn das aufrufende Programm die gesamte Nachricht halten kann und muss, dann kann das auch GnuPG. Also ist das Argument, dass GnuPG das nicht kann, damit kompletter Blödsinn.

    Und natürlich reicht es nicht, wenn die Weiterverarbeitung einer Datei mit kompromittierenden Daten unterbunden wird. Sondern letztlich ist der Umstand kritisch, dass solche kompromittierenden Daten da sind. Denn wenn ein Angreifer die Möglichkeit hat, auf irgendeine Weise die Klartexte der von ihm gezielt manipulierten Schlüsseltexte auszulesen, dann ist die Sicherheit des Systems gebrochen.

    Schließlich solltest du noch den Unterschied zwischen einem MAC und einer digitalen Signatur beachten. Es geht hier nämlich nicht um Signaturen. Damit ist das also ein komplettes Nichtargument. Wenn man beispielsweise pro Megabyte ein paar Byte Overhead für einen MAC hat, spielt das gar keine Rolle.

  5. Re: Angaben zu MDC im Artikel ungenau/irreführend

    Autor: Mr Miyagi 15.05.18 - 15:08

    Mingfu schrieb:
    --------------------------------------------------------------------------------
    > Wenn das aufrufende Programm die gesamte Nachricht halten kann und muss,
    > dann kann das auch GnuPG. Also ist das Argument, dass GnuPG das nicht kann,
    > damit kompletter Blödsinn.

    Natürlich *kann* es das. GnuPG könnte auch ein Abbild Deiner ganzen Mailbox im Speicehr halten, aber wozu? Das ist Resourcenverschwendung. GnuPG nutzt genau soviel Speicher wie unbedingt nötig und das ist auch der richtige Weg. Der Mailclient muß die gesamte Mail ohnehin zur Anzeige im Speicher halten. Es gibt nicht einen einzigen Grund hier die doppelte Speichermenge zu verschwenden.

    > Und natürlich reicht es nicht, wenn die Weiterverarbeitung einer Datei mit
    > kompromittierenden Daten unterbunden wird. Sondern letztlich ist der
    > Umstand kritisch, dass solche kompromittierenden Daten da sind. Denn wenn
    > ein Angreifer die Möglichkeit hat, auf irgendeine Weise die Klartexte der
    > von ihm gezielt manipulierten Schlüsseltexte auszulesen, dann ist die
    > Sicherheit des Systems gebrochen.

    Die Sicherheit ist gebrochen weil der Mail Client, *nicht* GnuPG ungefragt Daten ins Netz hinausposaunt und zwar weil Features (aka Bugs) unterstützt werden, die nicht Teil des E-Mail Standards sind. Namentlich "HTML-EMails". Genau die sind das Problem und *nur* die. Und wo sind diese implementiert? Im Mail-Client! Vorbei an jedem Standard.

    Insofern, ja die Sicherheit "des Systems" ist gebrochen. Und das System ist hier ausschliesslich die proprietäre Implementierung von Mailclients. Nicht GnuPG und erst recht nicht der E-Mail Standard.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Stromnetz Hamburg GmbH, Hamburg
  2. Deutsche Gesellschaft für Internationale Zusammenarbeit (GIZ) GmbH, Bonn-Röttgen
  3. Kirsch Pharma GmbH, Salzgitter
  4. Fachhochschule Südwestfalen, Iserlohn

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. täglich neue Deals bei Alternate.de


Haben wir etwas übersehen?

E-Mail an news@golem.de


The Secret of Monkey Island: Ich bin ein übelriechender, groggurgelnder Pirat!
The Secret of Monkey Island
"Ich bin ein übelriechender, groggurgelnder Pirat!"

Das wunderbare The Secret of Monkey Island feiert seinen 30. Geburtstag. Golem.de hat einen neuen Durchgang gewagt - und wüst geschimpft.
Von Benedikt Plass-Fleßenkämper


    Corsair K60 RGB Pro im Test: Teuer trotz Viola
    Corsair K60 RGB Pro im Test
    Teuer trotz Viola

    Corsair verwendet in der K60 Pro RGB als erster Hersteller Cherrys neue preiswerte Viola-Switches. Anders als Cherrys günstige MY-Schalter aus den 80ern hinterlassen diese einen weitaus besseren Eindruck bei uns - der Preis der Tastatur hingegen nicht.
    Ein Test von Tobias Költzsch

    1. Corsair K100 RGB im Test Das RGB-Monster mit der Lichtschranke
    2. Corsair Externes Touchdisplay ermöglicht schnelle Einstellungen
    3. Corsair One a100 im Test Ryzen-Wasserturm richtig gemacht

    Yakuza und Dirt 5 angespielt: Xbox Series X mit Rotlicht und Rennstrecke
    Yakuza und Dirt 5 angespielt
    Xbox Series X mit Rotlicht und Rennstrecke

    Abenteuer im Rotlichtviertel von Yakuza und Motorsport in Dirt 5: Golem.de konnte zwei Starttitel der Xbox Series X ausprobieren.
    Von Peter Steinlechner

    1. Next-Gen GUI der PS5 mit höherer Auflösung als Xbox Series X/S
    2. Xbox Series X Zwei Wochen mit Next-Gen auf dem Schreibtisch
    3. Next-Gen PS5 und neue Xbox wollen Spieleklassiker aufhübschen