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

Angaben zu MDC im Artikel ungenau/irreführend

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  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. SIEM/SOC Consultant (m/w/d)
    ALDI International Services SE & Co. oHG, Mülheim an der Ruhr, Duisburg, Düsseldorf, Dortmund
  2. Systemingenieur*in
    Zweites Deutsches Fernsehen Anstalt des öffentlichen Rechts, Mainz
  3. Anwendungsberater / Experte (m/w/d) für M365
    Mainova AG, Frankfurt am Main
  4. IT-Mitarbeiter Application MES (m/w/d)
    Craemer GmbH, Herzebrock-Clarholz

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. (u.a. Devil May Cry HD Collection für 14,99€, Lords & Villeins für 14,99€)
  2. 4,99€
  3. 28,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Klimaschutz: Verbrennerkauf - warum der Verkehrsminister recht hat
Klimaschutz
Verbrennerkauf - warum der Verkehrsminister recht hat

Bundesverkehrsminister Volker Wissing (FDP) warnt vor dem Kauf neuer Autos mit Verbrennungsmotor, weil fossile Brennstoffe keine Lösung sind - auch nicht als E-Fuels.
Ein IMHO von Andreas Donath

  1. Elektroauto VW e-Up ab Mitte Februar wieder bestellbar
  2. Elektromobilität Renault will ab 2030 in Europa nur noch E-Autos anbieten
  3. Hengchi 5 Evergrande baut sein erstes Elektroauto

Aufbauspiel Angespielt: Die Siedler gewinnen Land mit Ingenieuren
Aufbauspiel Angespielt
Die Siedler gewinnen Land mit Ingenieuren

Nun geht es ganz schnell bei Die Siedler: Beta im Januar, Veröffentlichung im März 2022. Golem.de konnte das Aufbauspiel schon ausprobieren.
Von Peter Steinlechner

  1. Ubisoft Blue Byte Im Januar 2022 wuselt das neue Die Siedler weiter

Bundesservice Telekommunikation: Ist eine scheinexistente Behörde für Wikipedia relevant?
Bundesservice Telekommunikation
Ist eine scheinexistente Behörde für Wikipedia relevant?

Die IT-Sicherheitsexpertin Lilith Wittmann hat eine dubiose Bundesbehörde ohne Budget entdeckt. Reicht das für einen Wikipedia-Artikel?

  1. Wikimedia Enterprise Die Wikipedia bekommt ein kommerzielles Angebot