Eigenen Prüfsumme Algo

[mhs]

Kaum auf den Algorithmus an, klar CRC32 (32 Bit) und MD5 (128 Bit) haben natürlich sehr viele Kollisionen, SHA-1 dagegen ist schon sehr sicher und bei SHA-2/3 mit 512 Bit sollte es eigentlich gar kein Thema mehr sein, sonst bleibt wirklich nur noch der Byteweise Vergleich....

[Kiffi]

oder aber man verwendet das Kommandozeilen-Tool fc (File Compare) --> https://en.wikipedia.org/wiki/Microsoft_File_Compare

[xXRobo_CubeXx]

Ich habe was geschrieben um indentische Dateien LAUT MD5 herauszufinden....

Code: Alles auswählen

UseMD5Fingerprint()
Global NewMap Liste.s()

Procedure Durchsuche(pfad.s)
  Protected dir=ExamineDirectory(#PB_Any, pfad, ""), Pruefsumme.s
  If dir
    While NextDirectoryEntry(dir)
      If DirectoryEntryType(dir) = #PB_DirectoryEntry_File
        Pruefsumme = FileFingerprint(pfad + DirectoryEntryName(dir), #PB_Cipher_MD5)
        If Liste(Pruefsumme) = ""
          Liste(Pruefsumme) = pfad + DirectoryEntryName(dir)
        Else
          If DirectoryEntryName(dir) <> GetFilePart(Liste(Pruefsumme))
            Debug "gefunden >>> " + Liste(Pruefsumme) + " === " + pfad + DirectoryEntryName(dir)
          EndIf
        EndIf
      ElseIf DirectoryEntryName(dir) <> "." And DirectoryEntryName(dir) <> ".."
        Durchsuche(pfad+DirectoryEntryName(dir)+"\")
      EndIf
    Wend
    FinishDirectory(dir)
  EndIf
EndProcedure

Durchsuche("C:\Daten\")

Wurden bei euch Dateien gefunden die LAUT MD5 gleich waren aber inhaltlich total unterschiedlich waren? Also ob Kolision stattfand? Bitte testen

[NicTheQuick]

Da gibt's nichts zu testen. Es ist Tatsache, dass es Kollisionen gibt, sie aber sehr unwahrscheinlich sind.

Worauf willst du eigentlich hinaus? Willst du nun einen eigenen Prüfsummenalgorithmus schreiben, der ein bestimmtes Problem löst? Oder willst du nur wissen, wie man vorhandene benutzt? Das kannst du aber ja offenbar schon.

[xXRobo_CubeXx]

>>>Willst du nun einen eigenen Prüfsummenalgorithmus schreiben
JA ich will ein eigenen BESSEREN und SICHEREN aber auch SCHNELLEREN Prüfsummenalgorithmus bauen sicher und schnell = ich weiss isn widerspruch aber vieleicht machbar? Oder ist das eine dumme Idee von mir?
thx Kifi. Wie schnell ist das Tool? Hat jemand schon die Zeit gemessen im vergleich zu anderen Vergleichsmethoden? und wie sicher ist es?

[NicTheQuick]

Wenn du einen besseren entwickeln willst, solltest du mit einem Informatik-Studium beginnen. Die Chance einen besseren als die bisher bekannten zu entwickeln, ist dennoch gering. Schneller als MD5 und dann noch sicher ist sehr unwahrscheinlich. Schnellere Hardware kaufen und Multicores ausnutzen ist günstiger und vor allem einfacher.

Was ist deine Definition von "sicher"? Dass keine unbeabsichtigten Kollisionen auftreten? Dass es schwer ist Kollisionen aus einer Datei zu erzeugen? Dass es schwer ist Kollisionen aus einer Prüfsumme zu erzeugen?

In Sachen Hash-Funktion für Passwörter ist es sicher, wenn der Algorithmus langsam ist (Bruteforce-Bremse) und man aus dem Hash-Wert nicht das ursprüngliche Passwort errechnen kann (Datenbank-Attacke).

[GPI]

Kaum auf den Algorithmus an, klar CRC32 (32 Bit) und MD5 (128 Bit) haben natürlich sehr viele Kollisionen, SHA-1 dagegen ist schon sehr sicher und bei SHA-2/3 mit 512 Bit sollte es eigentlich gar kein Thema mehr sein, sonst bleibt wirklich nur noch der Byteweise Vergleich....

Ganz gefährliche Denkweise.

512Bit = 64 Byte.

Wenn du jetzt 100 Byte große Dateien hast und davon alle möglichen Varianten, dann hast du schlicht mehr verschiedene Dateien als du Prüfsummen hast. Eine Kollision ist da rein von der Definition möglich und wird zu 100% zuschlagen.

Mir fällt auf, das du von Sicherheit sprichst - und da ist auch vermutlich der ganze Denkfehler, es geht dann darum, wie gut man bspw. Veränderungen an Dateien feststellen kann. Und da ist MD5 anscheinend deutlich schwächer. Auch beim Passwörterabgleich und ähnliches ist MD5 sogar richtig fatal. Das sind aber komplett andere Anwendungsgebiete.

Wenn du bspw. rausfinden willst, ob du doppelte Dateien auf deiner HDD hast, würde ich so vorgehen.
Inhaltsverzeichnis einlesen und die größe merken.
Wenn mehrere Dateien gleich groß sind, von jeder eine MD5-Summe errechnen und vergleichen. Wenn die MD5-Summe unterschiedlich ist, muss die Datei verschieden sein (umkehrschluss ist *NICHT* möglich).
Wenn man nur zwei Dateien hat oder mittels MD5-Überprüfung rausgefunden hat, das zwei dateien Identisch sein können, dann diese mittels byte für byte abgleichen.

Wenn du dir den letzten Schritt sparst, dann kann es irgendwann zu einer Kollision kommen, es ist nur eine Frage der Zeit. Und dann sieht dein Programm zwei unterschiedliche Dateien als identisch an. In diesen Fall wünsche ich dir viel Spaß Besonders bei der Fehlersuche, warum das jetzt so passiert ist.

[mhs]

Wenn du jetzt 100 Byte große Dateien hast und davon alle möglichen Varianten, dann hast du schlicht mehr verschiedene Dateien als du Prüfsummen hast. Eine Kollision ist da rein von der Definition möglich und wird zu 100% zuschlagen.

Ja natürlich kommt es naturgemäß durch die Hash Länge irgendwann zu einer Kollision. Allerdings stufe ich die Wahrscheinlichkeit, dass auf einem PC zwei gleich große Dateien sind, die den gleichen 512 Bit Hash Wert erzeugen als sehr gering ein. Vielleicht liege ich da auch falsch, kann sein.

Im Falle einer Dublettenbereinigung können wir also sagen, dass kein Weg am byteweisen Vergleich vorbei führt.

[xXRobo_CubeXx]

Gibt es Mathematiker unter euch? Könnt ihr damit ich mir was darunter vorstellen kann die Wahrscheinlichkeit zu einer Kolision in % ausrechnen? Einmal für MD5 und einmal mit SHA 512 Bit - das wäre nett

[matbal]

Hier meine Überlegung:

Bei MD5 mit 128 Bit gibt es theoretisch 2^128 verschiedene Prüfsummen, das sind ca. 3*10^38. Wenn ich die Zahl in Ziffern darstellen würde, wäre das eine 3 gefolgt von 38 weitere Ziffern.

Bei SHA512 sind 2^512 verschiedene Prüfsummen möglich, das sind ca. 10^154, also eine 1 gefolgt von 154 weiteren Ziffern.

Da die Zahlen ja den unterscheidbaren Dateien entsprechen, würde die Wahrscheinlichkeit entsprechend niedrig sein. Zusätzlich kommt es aber noch darauf an, wie gut der Algorithmus für die Prüfsummen ist...