Eindeutige Prüfziffer aus einem String bilden

[hmm]

Hi Leute,

ich möchte aus einem sehr langen String (ca. 10 D4 Seiten reiner Text) eine Zahl berechnen. Diese Zahl soll immer gleich sein, wenn sich der text nicht verändert und anders wenn sich der Text geändert hat.

Mit hilfe dieser Zahl möchte ich dann schnell sehen können ob sich der zugrundeliegende Text geändert hat.

Wie mache ich das? Bzw. kennt ihr ein Packet in java das man dafür verwenden könnte?

[Matthias Apsel]

Hallo hmm,

ich möchte aus einem sehr langen String (ca. 10 D4 Seiten reiner Text) eine Zahl berechnen. Diese Zahl soll immer gleich sein, wenn sich der text nicht verändert und anders wenn sich der Text geändert hat.

md5("sehr langer String")?

Bis demnächst
Matthias

[hmm]

danke, der passt perfekt!

[hash]

md5("sehr langer String")?

Ein Hash ja, aber bitte nicht md5 (oder sha1); es gibt genug Hashes, die nicht gebrochen sind und wenn man sie nie verwendet, verwendet man sie nie an einem Ort, wo es drauf ankommt.

[Christian Kruse]

Hallo hash,

md5("sehr langer String")?

Ein Hash ja, aber bitte nicht md5 (oder sha1); es gibt genug Hashes, die nicht gebrochen sind und wenn man sie nie verwendet, verwendet man sie nie an einem Ort, wo es drauf ankommt.

Das ist richtig für sicherheitsrelevante Anwendungen (etwa dem speichern von Passwörtern). Wenn es aber um nur eine Prüfsumme geht, ist MD5 fine.

LG,
CK

[hmm]

Das ist richtig für sicherheitsrelevante Anwendungen (etwa dem speichern von Passwörtern). Wenn es aber um nur eine Prüfsumme geht, ist MD5 fine.

genau, ich brauchte nur einen übersichtlichen wert mit dem man schnell sehen kann ob sich etwas geändert hat. die datenübertragung läuft mit Signature.getInstance("SHA1withDSA", "SUN")

[hash]

Ein Hash ja, aber bitte nicht md5 (oder sha1); es gibt genug Hashes, die nicht gebrochen sind und wenn man sie nie verwendet, verwendet man sie nie an einem Ort, wo es drauf ankommt.

Das ist richtig für sicherheitsrelevante Anwendungen (etwa dem speichern von Passwörtern). Wenn es aber um nur eine Prüfsumme geht, ist MD5 fine.

Deswegen schrieb ich ja „wenn man sie nie verwendet, verwendet man sie nie an einem Ort, wo es drauf ankommt“. Es gibt keine Gründe md5/sha1 zu verwenden (nein, sie sind nicht schneller), aber in verschiedenen Situationen ist es gefährlich.

[dedlfix]

Tach!

Deswegen schrieb ich ja „wenn man sie nie verwendet, verwendet man sie nie an einem Ort, wo es drauf ankommt“.

Der Satz wird logisch nicht besser, wenn du ihn wiederholst. Wie soll man denn mit der Sache anfangen, wenn man sie doch wegen der bisherigen Nie-Verwendung auch weiterhin nie verwendet?

dedlfix.

[hash]

Deswegen schrieb ich ja „wenn man sie nie verwendet, verwendet man sie nie an einem Ort, wo es drauf ankommt“.

Der Satz wird logisch nicht besser, wenn du ihn wiederholst. Wie soll man denn mit der Sache anfangen, wenn man sie doch wegen der bisherigen Nie-Verwendung auch weiterhin nie verwendet?

Ich möchte verhindern, dass die alten Hashes in neuen Anwendungen verwendet werden (für egal welchen Zweck). Würden bei der Verwendung von Crypto-Hashfunktionen immer nur (aktuell) sichere empfohlen werden, könnte eine hypothetische Situation in der hmm in Zukunft einen sicheren Hash bräuchte, sich daran erinnert, dass er ein für ihn ähnlich aussehendes Problem schon Code hat und diesen dann wiederverwendet, vermieden werden. Ich halte es für gefährlich jemandem einen teilweise defekten Algorithmus in die Hand zu drücken und darauf zu vertrauen, dass derjenige in Zukunft immer darüber nachdenken wird, bevor er ihn für einen anderen Zweck verwendet, vorallem wenn Alternativen existieren, die keine (aktuellen) Nachteile bieten. Ich wollte mit dem zitierten Satz also darauf hinaus, dass immer auf md5/sha1 zu verzichten immer sicher ist, wohingegen die Alternative mehr Denk- und Informationsaufwand benötigt und deshalb gefährlicher ist.

[Christian Kruse]

Hallo hash,

Ich möchte verhindern, dass die alten Hashes in neuen Anwendungen verwendet werden (für egal welchen Zweck). […]

Eine schlüssige Argumentation. Ich revidiere meinen Standpunkt: du hast recht, er sollte md5 nicht verwenden. Lieber einen Algorithmus aus der SHA2-Familie (SHA256 oder grösser).

LG,
CK

[hash]

Lieber einen Algorithmus aus der SHA2-Familie (SHA256 oder grösser).

Ich würde sogar noch weiter gehen und für neue Anwendungen etwas anderes empfehlen; es ist möglich, dass SHA2 leichter gebrochen werden wird, weil es die selbe Struktur hat wie MD5 und SHA1. Natürlich ist es auch möglich, dass SHA3, BLAKE2, etc. Probleme haben, die nur nicht offensichtlich genug waren bzw. die erst entdeckt werden, wenn es sich ausreichend lohnt sie anzugreifen.

[Auge]

Hallo

Lieber einen Algorithmus aus der SHA2-Familie (SHA256 oder grösser).

Ich würde sogar noch weiter gehen und für neue Anwendungen etwas anderes empfehlen; es ist möglich, dass SHA2 leichter gebrochen werden wird, weil es die selbe Struktur hat wie MD5 und SHA1. Natürlich ist es auch möglich, dass SHA3, BLAKE2, etc. Probleme haben, die nur nicht offensichtlich genug waren bzw. die erst entdeckt werden, wenn es sich ausreichend lohnt sie anzugreifen.

Es ist meiner Meinung nach so sicher, wie das Amen in der Kirche, dass irgendwann jedes Verfahren angreifbar sein wird bzw. für jedes der Verfahren Kollisionen bewiesen werden. Als Konsequenz hieße das nach deiner Argumentation, es einfach von vornherein sein zu lassen. Da es hier nicht um sicherheitsrelevante Daten geht, sondern um die Prüfung auf Änderungen, sollte aktuell ein aktuell ^[1] nicht als angreifbar erkanntes Verfahren reichen.

Tschö, Auge

---

1. Die zwei Vorkommen von „aktuell“ sind gewollt. ↩︎

[hash]

Es ist meiner Meinung nach so sicher, wie das Amen in der Kirche, dass irgendwann jedes Verfahren angreifbar sein wird bzw. für jedes der Verfahren Kollisionen bewiesen werden.

Ich bin mir da nicht sicher, beim Design/Test aktueller Crypto-Algorithmen wird meinem Empfinden nach deutlich mehr Sorgfalt auf die Zukunftssicherheit gelegt als früher.

Natürlich kann es sein, dass morgen jemand einen konstruktiven Beweis für $$P=NP$$ auf den Tisch legt oder einen Quanten-Computer hinstellt, der so ziemlich alle aktuell verwendete Crypto kaputt macht, aber ich halte das nicht für wahrscheinlich. Ich halte es für wahrscheinlicher, dass wir zu meiner Lebzeit tatsächlich Algorithmen nutzen werden, die in der Restexistenz der Menschheit nicht gebrochen werden (hey, eine Wette, die ich zu meiner Lebzeit nicht verlieren kann).

Als Konsequenz hieße das nach deiner Argumentation, es einfach von vornherein sein zu lassen.

Das ist eine selbst mir zu pessimistische Ansicht. Im einen Falle empfehle ich ein Verfahren, mit bereits bekannten Problemen im anderen eins bei dem ich zukünftige Probleme nicht mathematisch sicher ausschließen kann; da ist für mich ein ausreichend großer Abstand dazwischen.

Da es hier nicht um sicherheitsrelevante Daten geht,

Bist du sicher (ich würde auch vermuten, dass es so ist, aber sicher wäre ich mir nicht)? Falls es sich bei den nicht näher spezifizierten Texten z.B. um Mietverträge in PDF-Form handelt, wäre SHA-1 für den Zweck gefährlich: https://forum.selfhtml.org/self/2018/jan/3/eindeutige-pruefziffer-aus-einem-string-bilden/1711324#m1711324

SHA1 wird im Moment z.B. in git eingesetzt und vermutlich ist das nach aktuellem Stand kein Problem, aber auch da wäre es mir lieber, wenn SHA1 durch etwas besseres ersetzt würde, bevor es ein akutes Problem wird. Die Vergangenheit hat gezeigt, dass einen vorhandenen Angriff zu verbessern erheblich einfach ist, als einen komplett neuen Angriffsvektor zu finden.

sondern um die Prüfung auf Änderungen, sollte aktuell ein aktuell nicht als angreifbar erkanntes Verfahren reichen.

Auch hier die Frage: Was spricht für MD5?

[Auge]

Hallo

Es ist meiner Meinung nach so sicher, wie das Amen in der Kirche, dass irgendwann jedes Verfahren angreifbar sein wird bzw. für jedes der Verfahren Kollisionen bewiesen werden.

Ich bin mir da nicht sicher, beim Design/Test aktueller Crypto-Algorithmen wird meinem Empfinden nach deutlich mehr Sorgfalt auf die Zukunftssicherheit gelegt als früher.

Sorgfalt hin, Sorgfalt her. Früher als sicher angesehene Verfahren wurden irgendwann geknackt, sei es wegen konzeptioneller Schwächen oder wegen höherer verfügbarer Rechnerleistung oder hastenichjesehn. Ich wüsste nicht, warum das zukünftig anders sein sollte.

Wir wissen nicht, wie sich die Rechnerleistung entwickelt, wobei das wegen der Verfügbarkeit von mietbarer Rechnerleistung wohl nicht mehr die große Rolle spielt. Wir wissen auch nicht, ob in den Verfahren, bei denen „deutlich mehr Sorgfalt auf die Zukunftssicherheit gelegt [wurde] als früher“ nicht zukünftig Schwächen gefunden werden, die die Entwickler – geschweige denn wir – sich zum Zeitpunkt der Entwicklung des Verfahrens nicht hätten vorstellen können. Von Verfahren, die durch interessierte Seiten (z.B. Geheimdienste) schon bei deren Entwurf geschwächt werden, will ich erst gar nicht anfangen.

Meiner Meinung nach kann man prinzipiell alles kaputt machen.

Da es hier nicht um sicherheitsrelevante Daten geht,

Bist du sicher (ich würde auch vermuten, dass es so ist, aber sicher wäre ich mir nicht)?

Sicher? Nein. Aber nach den Beschreibungen der Aufgabe im Laufe der verschiedenen Postings vermute ich es nicht.

sondern um die Prüfung auf Änderungen, sollte aktuell ein aktuell nicht als angreifbar erkanntes Verfahren reichen.

Auch hier die Frage: Was spricht für MD5?

Was fragst du mich das? Ich habe und hätte MD5 nicht ins Spiel gebracht, zumal MD5 nicht in die Kategorie „aktuell nicht als angreifbar“ fällt.

Tschö, Auge

[ha]

Sorgfalt hin, Sorgfalt her. Früher als sicher angesehene Verfahren wurden irgendwann geknackt, sei es wegen konzeptioneller Schwächen oder wegen höherer verfügbarer Rechnerleistung oder hastenichjesehn. Ich wüsste nicht, warum das zukünftig anders sein sollte.

Falls wir irgendwann $$P \neq NP$$ beweisen sollten, könnte es darauf aufbauend beweisbar sichere Verfahren geben (ob die dann wiederum praktikabel wären, sei eine andere Frage), wenn ich mich nicht irre.

Wir wissen nicht, wie sich die Rechnerleistung entwickelt, wobei das wegen der Verfügbarkeit von mietbarer Rechnerleistung wohl nicht mehr die große Rolle spielt.

Wir können aber grob abschätzen wie groß die theoretisch mögliche Rechenkraft des sichtbaren Universums maximal sein kann (unter diversen nicht sicheren Voraussetzungen natürlich) und im Bereich der Post-Quantum-Cryptography sind das Dinge, mit denen meines Wissens nach durchaus hantiert wird auch wenn ich davon ausgehen würde, dass Crypto die zweimal länger hält als meine Lebenszeit ausreichend für meine Zwecke sein sollte.

Wir wissen auch nicht, ob in den Verfahren, bei denen „deutlich mehr Sorgfalt auf die Zukunftssicherheit gelegt [wurde] als früher“ nicht zukünftig Schwächen gefunden werden, die die Entwickler – geschweige denn wir – sich zum Zeitpunkt der Entwicklung des Verfahrens nicht hätten vorstellen können. Von Verfahren, die durch interessierte Seiten (z.B. Geheimdienste) schon bei deren Entwurf geschwächt werden, will ich erst gar nicht anfangen.

Korrekt, aber bei SHA2 wissen wir, dass durch zur MD5/SHA1-Cryptoanalyse verwandte Verfahren erste Erfolge zeigen und wie schon gesagt ist es erfahrungsgemäß einfacher bekannte Ideen zu verbessern als neue Ideen zu haben; das war schließlich der Grund für den SHA3-Wettbewerb.

Was fragst du mich das? Ich habe und hätte MD5 nicht ins Spiel gebracht, zumal MD5 nicht in die Kategorie „aktuell nicht als angreifbar“ fällt.

Ah sorry, ich wähnte mich im falschen Threadzweig.

[dedlfix]

Tach!

Würden bei der Verwendung von Crypto-Hashfunktionen immer nur (aktuell) sichere empfohlen werden, könnte eine hypothetische Situation in der hmm in Zukunft einen sicheren Hash bräuchte, sich daran erinnert, dass er ein für ihn ähnlich aussehendes Problem schon Code hat und diesen dann wiederverwendet, vermieden werden.

Dein Wunsch bleibt weiterhin ein Widerspruch in sich. Was machst du denn, wenn er sich in Zukunft an den heute als sicher angesehenen Mechanismus erinnert, der es dann aber nicht mehr ist?

Ich halte es für gefährlich jemandem einen teilweise defekten Algorithmus in die Hand zu drücken und darauf zu vertrauen, dass derjenige in Zukunft immer darüber nachdenken wird, bevor er ihn für einen anderen Zweck verwendet, vorallem wenn Alternativen existieren, die keine (aktuellen) Nachteile bieten.

Du nimmst also an, jemandem zu antworten, der nicht nachdenken möchte. Du drückst ihm zwar keinen aktuell als gebrochen angesehenen Mechanismus in die Hand, dafür aber einen, für den das lediglich noch nicht passiert ist. Ist das nicht genauso gefährlich?

Ich wollte mit dem zitierten Satz also darauf hinaus, dass immer auf md5/sha1 zu verzichten immer sicher ist, wohingegen die Alternative mehr Denk- und Informationsaufwand benötigt und deshalb gefährlicher ist.

Der Aufwand bleibt auch in Zukunft bestehen.

dedlfix.

[hash]

Würden bei der Verwendung von Crypto-Hashfunktionen immer nur (aktuell) sichere empfohlen werden, könnte eine hypothetische Situation in der hmm in Zukunft einen sicheren Hash bräuchte, sich daran erinnert, dass er ein für ihn ähnlich aussehendes Problem schon Code hat und diesen dann wiederverwendet, vermieden werden.

Dein Wunsch bleibt weiterhin ein Widerspruch in sich. Was machst du denn, wenn er sich in Zukunft an den heute als sicher angesehenen Mechanismus erinnert, der es dann aber nicht mehr ist?

In einer wirklich guten Antwort hätte ich ihn darauf hingewiesen, dass er informiert bleiben muss, wie die Crypto-Analyse des gewählten Algorithmus sich entwickelt. Zumindest habe ich aber kein zum Zeitpunkt der Antwort als teilweise gefährliche bekanntes Werkzeug empfohlen.

Ich halte es für gefährlich jemandem einen teilweise defekten Algorithmus in die Hand zu drücken und darauf zu vertrauen, dass derjenige in Zukunft immer darüber nachdenken wird, bevor er ihn für einen anderen Zweck verwendet, vorallem wenn Alternativen existieren, die keine (aktuellen) Nachteile bieten.

Du nimmst also an, jemandem zu antworten, der nicht nachdenken möchte.

Nachdenken ist anstrengend und als fauler Mensch vermeide ich Anstrengung und ich projeziere, dass es anderen genauso geht.

Du drückst ihm zwar keinen aktuell als gebrochen angesehenen Mechanismus in die Hand, dafür aber einen, für den das lediglich noch nicht passiert ist. Ist das nicht genauso gefährlich?

Aus meiner Sicht nein, erstens kann prinzipbedingt ich keine 100-prozentige Sicherheit bieten und zweitens ist ein bekannt teilweise gebrochener Mechanismus etwas deutlich anderes als ein Mechanismus, bei dem nach aktuellem Stand der Forschung keine Fehler bekannt sind.

Ich wollte mit dem zitierten Satz also darauf hinaus, dass immer auf md5/sha1 zu verzichten immer sicher ist, wohingegen die Alternative mehr Denk- und Informationsaufwand benötigt und deshalb gefährlicher ist.

Der Aufwand bleibt auch in Zukunft bestehen.

Es ist aber ein kleinerer Aufwand: Statt verstehen zu müssen, welcher spezifische Angriff auf MD5/SHA1 funktioniert und welche Anwendungszwecke deshalb nicht mehr bzw noch ok sind, muss ich mir nur merken, SHA1 nicht mehr zu verwenden; und wenn für SHA2 und/oder Alternativen Angriffe existieren, füge ich diese halt der Liste hinzu. Sollten wir irgendwann in der Situation sein, dass keine unproblematischen Alternativen existieren, wäre diese Abwägung vielleicht nötig, aber im Moment sehe ich einfach keinerlei Gründe die für die Verwendung von MD5/SHA1 sprechen.

[chorn]

Geht nicht.

Falls zwei Dokumente verschiedene Hashwerte haben, ist gewiss, dass die Dokumente unterschiedlich sind. Die Umkehrung gilt jedoch nicht, da es viel mehr verschiedene mögliche Dokumente als mögliche Hashwerte gibt.

Ein Hash erfüllt Anforderung 1, gleich bleibt gleich; allerdings nicht 2, unterschiedlich ist unterschiedlich; aber Anforderung 3, schnell.

[hmm]

Ein Hash erfüllt Anforderung 1, gleich bleibt gleich; allerdings nicht 2, unterschiedlich ist unterschiedlich; aber Anforderung 3, schnell.

hm, mist. muss ich austesten inwieweit das meine anwendung beeinflusst.

[dedlfix]

Tach!

Ein Hash erfüllt Anforderung 1, gleich bleibt gleich; allerdings nicht 2, unterschiedlich ist unterschiedlich; aber Anforderung 3, schnell.

hm, mist. muss ich austesten inwieweit das meine anwendung beeinflusst.

Hashing hat immer Kollisionen - prinzipbedingt. Die Frage ist nur, wie wahrscheinlich ist es, eine solche zu bekommen. Üblicherweise ist es im Normalbetrieb sehr unwahrscheinlich, dass eine solche auftritt, wenn man es nicht speziell darauf anlegt. Selbst wenn Wege bekannt sind, für ein bestimmtes Verfahren Kollisionen zu erzeugen, muss das noch kein Ausschlusskriterium sein, für das was man vorhat. Je komplexer das Berechungsverfahrten ist, desto mehr belastet es auch den Server. Es ist eine Abwägungssache zwischen "schnell aber unter Umständen unsicher" oder "nicht ganz so schnell, aber bislang als sicher angesehen". Vielleicht reicht in dem Fall sogar ein CRC-Verfahren, das noch ein wenig schneller ist, dafür aber auch anfälliger für bewusst herbeigeführte Kollisionen.

dedlfix.

[chorn]

Man kann das Prüfungsverfahren ja zumindest erstmal abkürzen und definitive Änderungen detektieren (filtern?), vielleicht reicht das ja auch schon. Oder zwei unterschiedliche Hashes benutzen. Aber das wird dann halt immer langsamer, und braucht mehr Speicher, bis die direkte Prüfung effizienter ist. Ggf. mal beschreiben, was überhaupt das Ziel ist, vielleicht fällt jemandem dann noch ein besseres Verfahren ein.

[dedlfix]

Tach!

Ggf. mal beschreiben, was überhaupt das Ziel ist, vielleicht fällt jemandem dann noch ein besseres Verfahren ein.

Vielleicht ist der Fall ja so einfach, dass ein Vergleich des Änderungsdatums schon reicht.

dedlfix.

[hmm]

meine anwendung schaut alle paar minuten in die datenbank und zieht sich alle daten und bildet zu diesen daten eine prüfsumme.

der anwender soll dann sehen können:

datum1 | prüfsumme1 datum2 | prüfsumme1

-> aha es hat sich nichts in der datenbank geändert

datum3 | prüfsumme2

-> ah, jetzt hat sich etwas geändert

um sicherheit geht es nicht, sondern nur darum die information "es hat sich etwas geändert" in einem überschaubaren string darzustellen

der md5 ist injektiv, ist also die prüfsumme gleich, so ist die datenbank nicht geändert worden. ist die prüfsumme verschieden könnte es sein das sie geändert wurde.

meine überlegung: der md5 macht in dem fall pi mal daumen was er soll, weil die prüfsumme regelmäßig neuberechnet wird. in den meisten fällen wird eine andere prüfsumme auf eine geänderte db schließen lassen. oder sehe ich das falsch?

[Christian Kruse]

Hallo hmm,

der anwender soll dann sehen können:

datum1 | prüfsumme1 datum2 | prüfsumme1

-> aha es hat sich nichts in der datenbank geändert

datum3 | prüfsumme2

-> ah, jetzt hat sich etwas geändert

Technisch reicht dafür ein Verfahren wie MD5 völlig aus.

Mal die Frage nach dem Prinzip: warum brauchst du da die Prüfsumme? Warum zeigst du dem User nicht einfach direkt an, ob sich etwas geändert hat oder nicht?

LG,
CK

[hmm]

Mal die Frage nach dem Prinzip: warum brauchst du da die Prüfsumme? Warum zeigst du dem User nicht einfach direkt an, ob sich etwas geändert hat oder nicht?

weil ich die alten daten nicht speichere, sondern nur die prüfsummen. auf verschiedenen servern liegen die datenbanken und mein programm liegt ebenfalls auf verschiedenen servern, die prüfsummen werden dann von den instanzen meines programms so verschickt das jeder server alle prüfsummen hat. ich mache das im rahmen meiner masterarbeit, wo ich austesten soll wie gut blockchains funktionieren.

[Regina Schaukrug]

wo ich austesten soll wie gut blockchains

Da war doch was mit sha256: "Neue Blocks werden in der Bitcoin-Blockchain mit dem SHA-256-Hashing-Algorithmus berechnet."

[hmm]

Da war doch was mit sha256: "Neue Blocks werden in der Bitcoin-Blockchain mit dem SHA-256-Hashing-Algorithmus berechnet.„

der inhalt der blockchain an der ich sitze sind dann wiederum die prüfsummen.

[Gunnar Bittersmann]

@@hmm

der anwender soll dann sehen können:

datum1 | prüfsumme1 datum2 | prüfsumme1

-> aha es hat sich nichts in der datenbank geändert

datum3 | prüfsumme2

-> ah, jetzt hat sich etwas geändert

Und die Aufgabe „prüfsumme1“ mit „prüfsumme1“ zu vergleichen, willst du einem Menschen aufbürden (sogar mehreren), obwohl das ein Computer doch viel besser kann?

Was der Anwender zu sehen bekommen sollte:

datum1 | Version 1 datum2 | — datum3 | Version 2

(wobei „—“ für „keine Änderung“ steht)

LLAP 🖖

[hmm]

da hast du recht, danke.

aktuell bin ich aber noch bei keiner visualisierung, sondern nur beim speichern der relevanten daten und da speichere ich für jeden messzeitpunkt eine prüfsumme, weil ich die zwischen den clients meiner dezentralen datenbank verschicken muss. die clients wiederum legen fest welche prüfsumme wann zuerst gebildet wurde.

[encoder]

meine anwendung schaut alle paar minuten in die datenbank und zieht sich alle daten und bildet zu diesen daten eine prüfsumme.

Schlechter Ansatz. Da lastest du den Rechner ganz schön aus.

ist also die prüfsumme gleich, so ist die datenbank nicht geändert worden. ist die prüfsumme verschieden könnte es sein das sie geändert wurde.

Andersherum! Ist die Prüfsumme gleich, wurde wahrscheinlich nichts geändert, vielleicht aber doch. Ist sie verschieden könnte es nicht nur sein dass was geändert wurde, sondern es ist zu 100% der Fall.

Speichere in der Datenbank bei jeder Änderung das aktuelle Datum (mit genügender Auflösung) oder ein Identity oder irgendetwas anderes eindeutiges. Dann brauchst du nur nachsehen ob dieser eindeutige Wert immer noch gleich ist oder nicht.

[hmm]

Schlechter Ansatz. Da lastest du den Rechner ganz schön aus.

entscheidung meines chefs und server der firma die meine MA betreut.

Andersherum! Ist die Prüfsumme gleich, wurde wahrscheinlich nichts geändert, vielleicht aber doch. Ist sie verschieden könnte es nicht nur sein dass was geändert wurde, sondern es ist zu 100% der Fall.

bei wikipedia steht das md5 eine kryptografische hashfunktion ist und das solche aufjedenfall injektiv sein müssen.

d.h. f(x1) = f(x2) => x1 = x2 für alle strings x1, x2 und deren prüfsummen f(x1), f(x2)

oder versteh ich jetzt was vollkommen falsch?

diese injektivität heißt ja gerade: ist die prüfsumme gleich so sind die dahinterliegenden strings gleich. sind die prüfsummen ungleich, so wäre es möglich, dass die strings verschieden sind, aber sie könnten auch gleich sein

[Auge]

Hallo

diese injektivität heißt ja gerade: ist die prüfsumme gleich so sind die dahinterliegenden strings gleich.

Nein, wie im hiesigen Thread schon mehrfach geschrieben, können auch unterschiedliche Strings den selben Hashwert nach Verfahren X haben. Solche Kollisionen sind sowohl für MD5 als auch für SHA1 nachgewiesen. Die Frage nach der Wahrscheinlichkeit einer solcher Kollision sei dahingestellt.

Tschö, Auge

[hash]

Nein, wie im hiesigen Thread schon mehrfach geschrieben, können auch unterschiedliche Strings den selben Hashwert nach Verfahren X haben. Solche Kollisionen sind sowohl für MD5 als auch für SHA1 nachgewiesen. Die Frage nach der Wahrscheinlichkeit einer solcher Kollision sei dahingestellt.

Für md5 und sha1 ist nachgewiesen, dass es möglich ist, Kollisionen in relativ kurzer Zeit vorsätzlich zu erzeugen, die einem ebenfalls von mir vorgegebenen Format folgen; dass ein allgemeiner Hash, der kürzer ist als der Originaltext immer zufällige Kollisionen haben muss, ist eine deutlich schwächere Aussage. Google hat letzten Sommer gezeigt, dass sie zwei PDF mit derselben SHA1-Prüfsumme und Dateigröße erzeugen können, die sich visuell nur wenig unterscheiden (statt die Farbe zu ändern, könnte man z.B. auch den Text eines Vertrages ändern). Bei der Verwendung eines nicht gebrochenen Hashes soll ich mich ja tatsächlich relativ^[1] sicher darauf verlassen können, dass aus gleichen Hashes gleicher Inhalt folgt.

---

1. Falls jemand also zu einem Datei zufällig auf eine Kollision stößt, so ist diese einfach (unterschiedliche Dateigröße, entspricht nicht dem Originalformat, Inhalt ist zufällig) zu erkennen. ↩︎

[1unitedpower]

bei wikipedia steht das md5 eine kryptografische hashfunktion ist und das solche aufjedenfall injektiv sein müssen.

Nope, bei Wikipedia steht:

Eine Hashfunktion ist eine Funktion, die eine Zeichenfolge beliebiger Länge auf eine Zeichenfolge mit fester Länge abbildet. Mathematisch ist diese Funktion nicht injektiv (linkseindeutig) und nicht notwendigerweise surjektiv (rechtstotal).

[encoder]

Schlechter Ansatz. Da lastest du den Rechner ganz schön aus.

entscheidung meines chefs und server der firma die meine MA betreut.

Dann frag ihn doch bis wann er deine MA fertig hat, wenn er weiß wie es geht :-) Nee so lustig ist das nicht, das ist das Hauptproblem mancher Chefs. Sie geben alles vor denn sie haben irgendwo etwas gehört... so könnte es gehen, siehe da erster Versuch mit zwei Eingaben funktioniert, also mach es so. Aber kaum gibts ein Problem sind sie dann raus, ohne rot zu werden.

Ich will nicht sagen dass mein Vorschlag der allerbeste ist, vor allem da ich das Umfeld deines Programms ja gar nicht kenne. Falls es eine sinnvollere, weniger aufwendige, skalierbarere oder einfach gesagt elegantere Lösung gibt, würde ich aber schon ein bisschen drum kämpfen.
Denke daran dass deine Masterarbeit nicht nur vom Betreuer sondern auch vom Korrekteur gelesen wird, der sie benotet. Vielleicht auch vom zukünftigen Vorgesetzten?
Falls das Programm das du gerade machst weiterhin im Einsatz bleibt und von jemand anderem weiterentwickelt wird, machst du dir auch keinen guten Ruf.

[Regina Schaukrug]

dafür aber auch anfälliger für bewusst herbeigeführte Kollisionen.

Naja. crc() sollte man nicht für große Dateien nehmen. Es mag schnell sein, aber bei einem Wertebereich von 16^8 (00000000 - ffffffff) oder eben 4.294.967.296 (crc32) geht das mit den Kollisionen zu schnell. Aus diesem Grund wird es praktisch nur genutzt, um die Übertagung von kleinen Datenmengen oder Blöcken abzusichern.

crc32 ${DATEI};

Kandidaten:

1. SHA1

Das schnelle SHA1 hat 40 hexadezimale Stellen. Damit findet die erste Kollision zwingend erst beim 1461501637330902918203684832716283019655932542976 + 1 Dokument statt.

openssl sha1 < ${DATEI} | sed "s/.*= //";

2. MD5

MD5 hat 32 hexadezimale Stellen. Damit findet die erste Kollision zwingend erst beim 340282366920938463463374607431768211456 + 1 Dokument statt.

openssl md5 < ${DATEI} | sed "s/.*= //";