1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Hashfunktion: Der schwierige Abschied…

SHA1 != (noch nicht) komplett unütz

Expertentalk zu DDR5-Arbeitsspeicher am 7.7.2020 Am 7. Juli 2020 von 15:30 bis 17:00 Uhr wird Hardware-Redakteur Marc Sauter eure Fragen zu DDR5 beantworten.
  1. Thema

Neues Thema Ansicht wechseln


  1. SHA1 != (noch nicht) komplett unütz

    Autor: Gugge 30.03.17 - 15:54

    Für die Kollision brauch man Kontrolle über beide Files, d.h. ich kann jetzt nicht einfach ein File erzeugen dass den gleichen hash hat wie, z.B. ein repo release file oder git commit object.

    Ich muss vorher schon Kontrolle über jenes File haben und dieses verändern sodass ich ein zweites mit gleicher Hash summe erzeugen kann, zumindest mit dem aktuell bekannten Verfahren welches Google mit sehr viel Rechenleistung entdeckt hat.

    Also, auch wenn man generell schauen sollte von SHA1 weg zukommen - wie schon länger vorhersehbar war, ist es zurzeit nicht so tragisch Dinge damit zu machen.
    Git kann ja z.B. mit beiden PDFs im gleichen repo umgehen, und hat auch sonstige "Anti Corruption" Vorkehrungen. SVN hat da ja schon mehr Probleme gehabt.

    Grundsätzlich ist jede Hashing Funktion Kollisions-gefährdet, wie das halt so ist wenn man eine (quasi) unendliche Menge auf eine Endliche abbildet.

  2. Re: SHA1 != (noch nicht) komplett unütz

    Autor: Natanji 30.03.17 - 15:58

    Es macht aber einen Unterschied ob es eine praktische Kollisionsgefahr gibt oder nicht.

    Kollisionen kann ich z.B. auch nutzen, indem ich mir zwei verschiedene kryptografische Schlüssel mit dem gleichen SHA1-Hash erstelle. In GPG ist der Fingerprint (das was Leute prüfen, was sie vertrauen) nämlich der SHA1-Hash des Schlüssels.

    GPG-Signaturen kann man daher nicht mehr vertrauen, sobald sich Kollisionen erzeugen lassen.

  3. Re: SHA1 != (noch nicht) komplett unütz

    Autor: schap23 30.03.17 - 16:21

    Bitte noch mal den letzten Satz des ursprünglichen Beitrags lesen.

    Hashs ohne Kollisionen kann es nicht geben. Das ist per definitionem so. Die Frage ist nur, wie leicht es ist, eine Kollision herbeizuführen, insbesondere wenn eine Dokument vorgegeben ist, ein anderes zu erzeugen, das den gleichen Hash-Wert ergibt.

  4. Re: SHA1 != (noch nicht) komplett unütz

    Autor: Natanji 31.03.17 - 10:38

    Ja. Das meine ich mit "praktische Kollisionsgefahr". Die Gefahr, dass die Kollisionsresistenz von Hashfunktionen nicht gilt, dass ich x,y finden kann mit h(x)=h(y). Die ist halt n Problem.

  5. Re: SHA1 != (noch nicht) komplett unütz

    Autor: Gugge 31.03.17 - 14:35

    Dein Szenario ist aber etwas unpraktikabel, denn es setzt ja voraus dass du beide Keys erzeugst und über beide Kontrolle hast, ansonsten kannst du ja mit dem bekannten verfahren nichts machen.

    Und wenn ich dir grundsätzlich schon Vertraue macht es so ja mäßig Sinn für dich das zu machen, du hast ja keinen mehr Gewinn.

    Plus sing GPG keys ja nicht fälschbar, mit der Methode, AFAIK.

    Was ein Problem darstellen würde wäre folgendes - theoretisches - Beispiel:
    Ich gebe eine SHA-1 Signiertes Angebot raus, das billig ist, mein Opfer nimmt das an, ich habe aber zu Beginn schon ein zweites teures Angebot mit selbiger SHA Checksumme produziert.

    Nun zeig ich dir das und meine das du mir mehr schuldest als du glaubst.
    Recht absurd, da diese Attacke wirklich noch recht wenig praktikablen "kriminellen nutzen" hat.

    Software kann ich ja nicht fälschen damit den entweder a) es ist proprietär, da kann ich dir sowieso alles unterjubeln b) es ist opensource, da sehe ich im Quellcode das du auch mit am Orginal gepfuscht hast, ansonsten kommt die Kollision ja nicht zustande.

  6. Re: SHA1 != (noch nicht) komplett unütz

    Autor: Heinzel 31.03.17 - 20:29

    > b) es ist opensource, da sehe ich im Quellcode das du auch
    > mit am Orginal gepfuscht hast

    Als git noch recht frisch war hat Linus einen Vortrag gehalten und dargelegt warum ihm alle anderen Version-Control-Systeme nicht getaugt haben. Abgesehen von der Geschwindigkeit und Dezentralität ging es da auch darum, daß die anderen VCS nicht garantieren, daß das was du rausbekommst auch tatsächlich das ist, was du reingesteckt hast. Aber git garantiert das! Durch die Checksummen. Eigentlich.

    Solange der Hash nicht umfällt.

    Das Problem ist daß sich da eben alle drauf verlassen. Wenn git sagt es ist okay, dann ist es auch okay. git diff mag Änderungen anzeigen, aber da schaut man wenn überhaupt, dann halt nur die neusten an. Und wenns eine Zeile von Anfang an und nie geändert dann taucht das halt auch nie auf. Und wenn git blame sagt, das ist von 1999 dann muss das wohl auch so sein.

    Das Tool mit dem man den Sourcecode verwaltet darf eben nicht umfallen.

  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. Psychiatrisches Zentrum Nordbaden, Wiesloch
  2. SCHUFA Holding AG, Wiesbaden
  3. über duerenhoff GmbH, Raum Fuldatal
  4. AKKA, Neu-Ulm

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 4,99€
  2. (u. a. Warhammer 40,00€0: Gladius - Relics of War für 23,79€, Aggressors: Ancient Rome für 17...
  3. 58,48€ (PC), 68,23€ (PS4) 69,99€ (Xbox One)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Telekom, Vodafone: Wenn LTE schneller als 5G ist
Telekom, Vodafone
Wenn LTE schneller als 5G ist

Dynamic Spectrum Sharing erlaubt 5G und LTE in alten Frequenzbereichen von 3G und DVB-T. Doch wenn man hier nur LTE einsetzen würde, wäre die Datenrate höher.
Ein Bericht von Achim Sawall

  1. Telekom Große Nachfrage nach Campusnetzen bei der Industrie
  2. Redbox Vodafone stellt komplettes 5G-Netz in einer Box vor
  3. 5G N1 Telekom erweitert massiv das 5G-Netz mit Telefónica-Spektrum

Mehrwertsteuersenkung: Worauf Firmen sich einstellen müssen
Mehrwertsteuersenkung
Worauf Firmen sich einstellen müssen

Wegen der Mehrwertsteuersenkung müssen viele Unternehmen in kürzester Zeit ihre Software umstellen. Alle möglichen Sonderfälle müssen berücksichtigt werden, der Aufwand ist enorm.
Von Boris Mayer

  1. Raumfahrt Vega-Raketenstart während Corona-Ausbruchs verschoben
  2. Corona Google und Microsoft starten Weiterbildungsprogramme
  3. Kontaktverfolgung Datenschützer kritisieren offene Gästelisten

Außerirdische Intelligenz: Warum haben wir noch keine Aliens gefunden?
Außerirdische Intelligenz
Warum haben wir noch keine Aliens gefunden?

Seit Jahrzehnten gucken wir mit Teleskopen tief ins All. Außerirdische haben wir zwar bisher nicht entdeckt, das ist aber kein Grund, an ihrer Existenz zu zweifeln.
Von Miroslav Stimac