Einzelnen Beitrag anzeigen

Delphi.Narium

Registriert seit: 27. Nov 2017
2.490 Beiträge
 
Delphi 7 Professional
 
#13

AW: Optimaler Hash-Algorithmus und Strategie für Dateivergleiche, Verzeichnisbaum

  Alt 4. Mai 2024, 11:30
Hab' einfach mal wieder die KI meiner Wahl befragt:
Zitat von Frage:
Wie hoch ist die Wahrscheinlichkeit, dass es bei der Verwendung eines MD5-Hashes beim Vergleich von Dateien zu einer Kollision kommt, d. h., das zwei unterschieldiche Dateien über einen identischen MD5-Hash verfügen?
Zitat von Antwort:
Die Wahrscheinlichkeit einer Kollision bei der Verwendung von MD5-Hashes hängt von der Anzahl der eindeutigen Eingaben ab, die gehasht werden. MD5 erzeugt einen Hash-Wert von 128 Bit, was bedeutet, dass es 2^128 oder etwa 3.4 x 10^38 eindeutige Hash-Werte gibt.

Die Wahrscheinlichkeit einer Kollision kann mit der Geburtstagsparadoxon-Formel berechnet werden. Wenn wir n als die Anzahl der eindeutigen Eingaben und d als die Anzahl der möglichen Hash-Werte betrachten, dann ist die Wahrscheinlichkeit P einer Kollision gegeben durch:

P ≈ n^2 / 2d

Für MD5, wenn wir annehmen, dass wir etwa 2^64 eindeutige Eingaben hashen (eine große, aber realistische Anzahl), dann ist die Wahrscheinlichkeit einer Kollision:

P ≈ (2^64)^2 / 2 * 2^128 = 1 / 2^64

Das ist eine sehr kleine Wahrscheinlichkeit, aber es ist nicht null. In der Praxis sind Kollisionen mit MD5 bekannt und das Verfahren wird daher für sicherheitskritische Anwendungen nicht mehr empfohlen. Es ist jedoch immer noch weit verbreitet für weniger kritische Anwendungen wie die Überprüfung der Integrität von Dateien.

Bitte beachten Sie, dass diese Berechnung eine Vereinfachung ist und die tatsächliche Wahrscheinlichkeit aufgrund verschiedener Faktoren, einschließlich der spezifischen Eigenschaften des MD5-Algorithmus, abweichen kann. Es ist auch wichtig zu beachten, dass selbst eine sehr geringe Kollisionswahrscheinlichkeit in bestimmten Kontexten ein Sicherheitsrisiko darstellen kann.
Zitat von Frage:
Wie verändert sich bei einem Dateivergleich die Wahrscheinlichkeit einer MD5-Hash-Kollision, wenn zusätzlich noch die Dateigröße und das Datum der letzten Dateiänderung mit berücksichtigt werden?
Zitat von Antwort:
Die Berücksichtigung zusätzlicher Informationen wie Dateigröße und Datum der letzten Änderung kann die Wahrscheinlichkeit einer Kollision beim Vergleich von Dateien erheblich reduzieren.

Wenn zwei Dateien denselben MD5-Hash haben, aber unterschiedliche Größen oder Änderungsdaten, dann können wir sicher sein, dass es sich um unterschiedliche Dateien handelt, auch wenn der MD5-Hash identisch ist. In diesem Fall würde die Kollision beim MD5-Hash nicht zu einer falschen Übereinstimmung führen, da die zusätzlichen Informationen (Dateigröße und Änderungsdatum) die Unterschiede aufzeigen.

Es ist jedoch wichtig zu beachten, dass diese Methode nicht vollständig vor Kollisionen schützt. Es ist theoretisch möglich (wenn auch extrem unwahrscheinlich), dass zwei unterschiedliche Dateien denselben MD5-Hash, dieselbe Größe und dasselbe Änderungsdatum haben. Aber die Wahrscheinlichkeit dafür ist so gering, dass sie in der Praxis vernachlässigbar ist.

Insgesamt kann die Berücksichtigung von Dateigröße und Änderungsdatum bei der Verwendung von MD5-Hashes zur Dateivergleichung die Sicherheit erheblich verbessern. Es ist jedoch immer noch empfehlenswert, sicherere Hash-Funktionen wie SHA-256 zu verwenden, insbesondere für sicherheitskritische Anwendungen.
Zitat von Frage:
Es ist aber doch im Rahmen des Möglichen, dass zwei Dateien mit gleichem MD5-Hash und identischer Dateigröße, aber unterschiedlichen Änderungszeitpunkten identisch sind, z. B. weil eine Datei von einem Datenträger auf einen andern kopiert wurde oder nur ein Kopieren unter einem anderen Dateinamen oder in ein anderes Verzeichnis erfolgte. Wäre es in diesem Falle nicht zielführender zum Vergleich nur Dateigröße und erst bei identischer Dateigröße zusätzlich den MD5-Hash zu verwenden? Wie würde sich dadurch die Wahrscheinlichkeit eines Kollision der MD5-Hashs verändern?
Zitat von Antwort:
Sie haben absolut recht. In der Praxis ist es durchaus möglich, dass zwei Dateien mit demselben MD5-Hash und der gleichen Größe, aber unterschiedlichen Änderungsdaten tatsächlich identisch sind. Dies könnte der Fall sein, wenn eine Datei kopiert oder unter einem anderen Namen gespeichert wurde.

In solchen Fällen könnte es sinnvoll sein, zuerst die Dateigröße zu vergleichen und nur bei Übereinstimmung der Größe den MD5-Hash zu berechnen und zu vergleichen. Dies könnte die Effizienz des Vergleichsprozesses verbessern, insbesondere wenn eine große Anzahl von Dateien verglichen wird, da die Berechnung von Hashes rechenintensiv sein kann.

Was die Wahrscheinlichkeit einer Kollision betrifft, so würde sich diese nicht ändern, da die Wahrscheinlichkeit einer Kollision nur von der Anzahl der eindeutigen Eingaben und der Größe des Hash-Raums abhängt (bei MD5 sind das 2^128 mögliche Hashes). Die Reihenfolge, in der Sie die Größe und den Hash vergleichen, hat keinen Einfluss auf die Wahrscheinlichkeit einer Kollision. Es ändert jedoch die Wahrscheinlichkeit, dass eine Kollision zu einer falschen Übereinstimmung führt, da Dateien mit unterschiedlichen Größen bereits vor der Hash-Berechnung ausgeschlossen werden.

Es ist jedoch wichtig zu beachten, dass diese Methode immer noch nicht vollständig vor Kollisionen schützt. Es ist theoretisch möglich (wenn auch extrem unwahrscheinlich), dass zwei unterschiedliche Dateien denselben MD5-Hash und dieselbe Größe haben. Aber die Wahrscheinlichkeit dafür ist so gering, dass sie in der Praxis vernachlässigbar ist. Für sicherheitskritische Anwendungen wird daher empfohlen, sicherere Hash-Funktionen wie SHA-256 zu verwenden.
Mein Fazit:

Eine Tabelle mit Dateinamen, Dateigröße, MD5-Hash und den Änderungsdaten sollten für die gestellte Aufgabe ausreichend sein.

Das Erstellen einer Baumstruktur ist nicht erforderlich, es sei denn, man möchte es für die Anwender schön aussehen lassen. Dann reicht es aber aus die Baumstruktur nur für die Daten zu erstellen, die die Anwender auch zu Gesicht bekommen sollen und zwar erst dann, wenn die Daten zur Anzeige gebracht werden.

Mein Vorgehen wäre:

Rekursives Einlesen der Verzeichnisstruktur(en) und je Datei Pfad und Name, Dateigröße und Änderungsdaten in einer Tabelle speichern, dazu reichen FindFirst und FindNext mit TSearchRec aus.

In der so erstellten Tabelle alle Sätze suchen, bei denen die Dateigröße mehr als einmal vorkommt:
SQL-Code:
select * from tabelle a where exists (
  select 1 from tabelle b
  where a.dateigroesse = b.dateigroesse
  group by b.dateigroesse having count(*) > 1
)
order by a.Dateigroesse;
Für die so ausgewählten Dateien den MD5-Hash berechnen und in der Tabelle speichern.

Anschließend die Dateien suchen lassen, bei denen die Kombination aus Dateigröße und MD5-Hash mehr als einmal vorkommen.
SQL-Code:
select * from tabelle a where exists (
  select 1 from tabelle b
  where a.dateigroesse = b.dateigroesse
  and a.md5 = b.md5
  group by b.dateigroesse, b.md5 having count(*) > 1
)
order by a.Dateigroesse, a.md5;
Aus dem Ergebnis wird dann die Anzeige für die Anwender befüllt, egal ob als TreeView, ListView oder auch einfach nur in 'nem DBGrid.
  Mit Zitat antworten Zitat