CRC32, MD5 oder SHA1?

[Snoopy69]

Ich verifiziere meine wichtigsten Daten immer mit MD5. (mit Total Commander)
Nun hab ich letztens SHA1 benutzt und stellte fest, dass das verifizieren viel länger dauert (und kürzer mit CRC32).

Arbeitet SHA1 genauer bzw. CRC32 ungenauer?
Mit anderen Worten könnte ein Fehler in der Datei sein, den CRC32 nicht aufspürt, SHA1 jedoch schon?

[Tesseract]

zum überprüfen von (runtergeladenen) dateien reicht md5 vollkommen aus. bessere hashalgorithmen haben zwar (je nach digest-länge bzw. komplexität) bessere kollisionseigenschaften aber das ist nur für die kryptographie interessant. es wäre höchstens denkbar, dass du mit vorsatz und sehr viel rechenpower eventuell eine zweite datei erstellen könntest, die den selben hash liefert. diese wäre von der ursprünglichen aber grundverschieden und würde keine "sinnvollen" daten enthalten.
du kannst mit an sicherheit grenzender wahrscheinlichkeit davon ausgehen, dass md5 in der praxis noch nie eine unabsichtlich fehlerhaft kopierte datei durchgewunken hat.

[PatkIllA]

CRC und kryptographische Hashfunktionen wie MD5 und SHA1 haben erstmal unterschiedliche Anforderungen.
Bei CRC geht es darum, dass es möglichst einfach sein soll. Bei MD5/SHA1 soll es neben der Verifizierung auch praktisch unmöglich eine zweite Datei mit dem gleichen Hash zu erzeugen (die dann auch keinen brauchbaren Inhalt hätte)
Bei CRC kann man recht einfach Kollisionen berechnen. Alleine schon durch die Länge ist es ersichtlich, dass bei CRC eher Fehler durchrutschen. Praktisch ist das bei allen Algorithemn durch versehentliche Fehler aber nahezu ausgeschlossen.

[Snoopy69]

zum überprüfen von (runtergeladenen) dateien reicht md5 vollkommen aus. bessere hashalgorithmen haben zwar (je nach digest-länge bzw. komplexität) bessere kollisionseigenschaften aber das ist nur für die kryptographie interessant. es wäre höchstens denkbar, dass du mit vorsatz und sehr viel rechenpower eventuell eine zweite datei erstellen könntest, die den selben hash liefert. diese wäre von der ursprünglichen aber grundverschieden und würde keine "sinnvollen" daten enthalten.
du kannst mit an sicherheit grenzender wahrscheinlichkeit davon ausgehen, dass md5 in der praxis noch nie eine unabsichtlich fehlerhaft kopierte datei durchgewunken hat.
Da würd ja heissen, dass MD5 nicht jedes Bit gehasht hat, oder? Dann wäre man eher mit MD5 und der Dateigröße in Bit sicher, dass da keine Fehler drin sind. (zu paranoid?)

Und ist SHA1 der ultimative Hashalgorithmus oder gibts da noch was höheres?

[PatkIllA]

Da würd ja heissen, dass MD5 nicht jedes Bit gehasht hat, oder?Nein
Dann wäre man eher mit MD5 und der Dateigröße in Bit sicher, dass da keine Fehler drin sind. (zu paranoid?)Auch nein. Bei 128 Bit Hash müssen zwangsweise etliche unterschiedliche Dateien den gleichen Hash haben. Sonst wäre das nebenbei noch der ultimative Kompressionsalgorithmus.

[Snoopy69]

Wie, nein?
Wenn MD5 keine absolute Sicherheit gibt, was macht SHA1 anders?

[Tesseract]

wenn die datei größer sein kann als der digest muss es zwangsläufig mehrere dateien geben die den selben hash erzeugen. das ist bei jeder hashfunktion so.
was andere hashfunktionen anders machen habe ich eh schon geschrieben: die besseren sind kryptografisch weniger angreifbar, d.h. es ist z.B. schwieriger eine zweite datei zu berechnen die den selben hash erzeugt. zum überprüfen von kopierten dateien ist das aber de facto egal.

alle hashfunktionen beziehen jedes bit der datei mit ein und bei jeder hashfunktion führt eine kleine änderung im file zu einem komplett anderen hashwert. das ist eine der grundvoraussetzungen von hashfunktionen - sonst wären es keine.

[PatkIllA]

Wenn MD5 keine absolute Sicherheit gibt, was macht SHA1 anders?Das "Prinzip" ist im Grunde das gleiche bei SHA1. Auch SHA1 bietet keine absolute Sicherheit. Es gibt im Gegensatz zu SHA1 AFAIK keine bekannte Schwachstellen, die das absichtliche erzeugen von Kollisionen ermöglichen bzw. Erleichtern. Bei MD5 gibt es das und das wurde auch schon genutzt.
Eine Hashfunktion kann mathematisch auch keine absolute Sicherheit bieten. Das wird alleine aus der Länge des Hashes klar.

alle hashfunktionen beziehen jedes bit der datei mit ein und bei jeder hashfunktion führt eine kleine änderung im file zu einem komplett anderen hashwert. das ist eine der grundvoraussetzungen von hashfunktionen - sonst wären es keine.
Weder die komplette Änderung noch das komplette einbeziehen der Bits sind notwendig. Selbst ein fixer Rückgabewert geht als Hashfunktion durch.

[fezie]

Und ist SHA1 der ultimative Hashalgorithmus oder gibts da noch was höheres?

Es gibt noch SHA-2

[Tesseract]

Weder die komplette Änderung noch das komplette einbeziehen der Bits sind notwendig. Selbst ein fixer Rückgabewert geht als Hashfunktion durch.
das bricht jeweils eine oder mehrere anforderungen an eine hashfunktion. ohne komplette einbezieheung gibt es keine wirkliche kollisionsresistenz, bei einem festen rückgabewert gibt es weder kollisionsresistenz noch pre-image resistenz. eine komplette änderung des digests kann man natürlich nicht garantieren, aber bei allen gängigen hashfunktionen führt eine kleine änderung in der datei normalerweise zu einer starken änderung im digest.

[PatkIllA]

das bricht jeweils eine oder mehrere anforderungen an eine hashfunktion. ohne komplette einbezieheung gibt es keine kollisionsresistenz, bei einem festen rückgabewert gibt es weder kollisionsresistenz noch pre-image resistenz. eine komplette änderung des digests kann man natürlich nicht garantieren, aber bei allen gängigen hashfunktionen führt eine kleine änderung in der datei normalerweise zu einer starken änderung im digest.
Kryptographische Hashfunktionen sind nur ein Teil der Anwendung von Hashfunktionen.
Ein alltäglicher Anwendungsfall in der Programmierung sind die Keys für Hashmaps. Und da ist es fast normal nicht alles einzubeziehen und selbst den fixen Rückgabewert habe ich schon ein paar mal benutzt (bei zustandlosen Objekten bleibt praktisch gar nichts anderes)

[Tesseract]

Kryptographische Hashfunktionen sind nur ein Teil der Anwendung von Hashfunktionen.
es geht hier aber um krypografische hashfunktionen, nicht um hashmaps. (genau genommen um eine klasse von hashfunktionen, die zumindest einen teil der anforderungen an eine cryptografische hashfunktion erfüllen muss weshalb man gleich kyptografische hashfunktionen dafür verwendet)

[PatkIllA]

es geht hier aber um krypografische hashfunktionen, nicht um hashmaps.
CRC steht doch auch noch im Raum. Und das ist auch eine Hashfunktion. Nur halt nicht für kryptographische Anwendungen. Im Moment ist dem Threadstarter glaube ich auch noch nicht mal der allgemeine Teil von Hashfunktionen klar.

[Snoopy69]

wenn die datei größer sein kann als der digest muss es zwangsläufig mehrere dateien geben die den selben hash erzeugen. das ist bei jeder hashfunktion so.
was andere hashfunktionen anders machen habe ich eh schon geschrieben: die besseren sind kryptografisch weniger angreifbar, d.h. es ist z.B. schwieriger eine zweite datei zu berechnen die den selben hash erzeugt. zum überprüfen von kopierten dateien ist das aber de facto egal.

alle hashfunktionen beziehen jedes bit der datei mit ein und bei jeder hashfunktion führt eine kleine änderung im file zu einem komplett anderen hashwert. das ist eine der grundvoraussetzungen von hashfunktionen - sonst wären es keine.
Ich verstehe leider nichts davon, was du schreibst.

Gibt es irgendwo etwas zu lesen, was jeder verstehen kann. Oder ist das zu umfangreich?


CRC steht doch auch noch im Raum. Und das ist auch eine Hashfunktion. Nur halt nicht für kryptographische Anwendungen. Im Moment ist dem Threadstarter glaube ich auch noch nicht mal der allgemeine Teil von Hashfunktionen klar.
Genau :freak:

[EPIC_FAIL]

Ich verstehe leider nichts davon, was du schreibst.

Gibt es irgendwo etwas zu lesen, was jeder verstehen kann. Oder ist das zu umfangreich?





Ganz einfach. Die Länge des Hashs ist bei MD5 beispielsweise 128 Bit lang. Dadurch lassen sich 2^128 verschiedene Kombinationen an 0en und 1en bilden. Jetzt nehmen wir mal an wir hashen tatsächlich 2^128 verschiedene Dateien und jede Datei bekommt ihren eigenen Hash (ziemlich unwahrscehinlich wegen Geburtstagparadoxon, aber egal). Wenn du auch nur eine Datei mehr als die 2^128 hashst, kommt es zwangsläufig zu einer Kollision. Da du praktisch unendliche viele Möglichkeiten als Input hast, jedoch nur eine begrenze Menge als Output (die 2^128) gibt es zwangsläufig in jedem Hashverfahren Kollisionen.