Hash Algorithmus
-
Hallo zusammen
Ich muss einen Hashalgorithmus schreiben, mit dessen Hilfe ich 128-Bit, 192-Bit sowie 256-Bit Haswerte erzeugen kann.Ich liebäugle dabei mit dem Whirlpool sowie mit dem HAVAL - Algorithmus. Da Whirlpool auschliesslich 512-Bit Hashs erzeugt, könnte ich einfach das entsprechende "Stück" aus dem Kuchen herausschneiden, wobei es mit HAVAL möglich ist, Hashs mit einer variablen Bitlänge zu erzeugen.
Gibt es Gründe für die Wahl des einen oder anderen Algos? Oder gibts noch andere, die ich übersehen habe? MD5 ist leider für diesen Zweick ein wenig ungeeignet, da dieser auschliesslich 128-Bit Hashs erzeugen kann.
Lg Ishildur
-
Ich habe mich in der Zwischenzeit für HAVAL entschieden, doch leider finder ich hierzu keine Literatur? Weiss vielleicht jemand, wo ich passende Literatur finden kann?
Lg Ishildur
-
Wenn du mit Literatur nicht unbedingt Bücher meinst, dann schau mal auf
http://labs.calyptix.com/crypto/haval.php da kannst du dir den C-Quellcode herunterladen, und in dem Ordner ist dann auch eine PDF Dokumentation.
-
Naja, wenn ich mir die Doku so ansehe, bekomme ich zweifel, ob dies der richtige Algo für meinen Verwendungszweck ist. Offenbar verwendet HAVAL 1024-Bit Blöcke. Da der Benutzer allerdings i.d.R nichr mehr als 64 Bit's definieren wird, müsste sehr viel gepadded werden und eine Kollision währe wahrscheinlich, oder?
-
Ishildur schrieb:
Da der Benutzer allerdings i.d.R nichr mehr als 64 Bit's definieren wird, müsste sehr viel gepadded werden und eine Kollision währe wahrscheinlich, oder?
Den Schluß kann ich nicht nachvollziehen. Ich kenne diese spezielle Hash-Funktion nicht. Aber warum sollte Padding schlimmer sein als andere Daten?
-
Ishildur schrieb:
...sehr viel gepadded werden und eine Kollision währe wahrscheinlich, oder?
Kommt ganz drauf an ! Wenn Du natürlich "dämlich" paddest, dann schon. Wenn Du allerdings mit (echten !) Zufallswerten paddest, kann Dir gar nichts Besseres passieren.
Gruß,
Simon2.
-
Simon2 schrieb:
Kommt ganz drauf an ! Wenn Du natürlich "dämlich" paddest, dann schon. Wenn Du allerdings mit (echten !) Zufallswerten paddest, kann Dir gar nichts Besseres passieren.
Beweis/Begründung?
-
Simon2 schrieb:
Ishildur schrieb:
...sehr viel gepadded werden und eine Kollision währe wahrscheinlich, oder?
Kommt ganz drauf an ! Wenn Du natürlich "dämlich" paddest, dann schon. Wenn Du allerdings mit (echten !) Zufallswerten paddest, kann Dir gar nichts Besseres passieren.
Gruß,
Simon2.
Hmm... und wenn ich nachher mittels des Hashs etwas vergleichen will, wie kriege ich dann wieder die gleiche zufällige Sequenz, damit ein Wert über den Schlüssel identifizierbar bleibt?
-
Sid2K6 schrieb:
... und wenn ich nachher mittels des Hashs etwas vergleichen will, wie kriege ich dann wieder die gleiche zufällige Sequenz, damit ein Wert über den Schlüssel identifizierbar bleibt?
Das ist eine Frage Deines Protokolls.... Z.B. einfach mitschicken (ggf. auch verschlüsselt).
Gruß,
Simon2.
-
Jester schrieb:
Simon2 schrieb:
Kommt ganz drauf an ! Wenn Du natürlich "dämlich" paddest, dann schon. Wenn Du allerdings mit (echten !) Zufallswerten paddest, kann Dir gar nichts Besseres passieren.
Beweis/Begründung?
Da "Beweise" (im mathematischen Sinne) im Zusammenhang mit Hashfunktionen gelinde gesagt länglich und komplex sind, versuch' ich's gar nicht erst (könnte ich auch nicht - sonst hätte mein Chef das bestimmt nicht als Promotion angerechnet bekommen).
Begründung: Prinzipiell gilt, dass die "Rückschließbarkeit" von einem Hash auf seinen OText durch dessen "Wertebereich" verringert wird. Ist auch klar: Paddest Du mit "0", erhält derselbe Text auch immer denselben Hash, paddest Du mit Zufallswerten, dann nicht.
Dein Protokoll ist umso geringer von der Qualität des Hashverfahrens abhängig, je besser Du den Wertebereich abdeckst ... und da gibt's halt nichts Besseres als Zufallszahlen.Aber letztlich ist das natürlich nur ein Argument, wenn neben "Unveränderbarkeit" noch "Vertraulichkeit" eine Rolle spielt. Wer das nur als "technische Prüfsumme" braucht, stört sich da vermutlich nicht dran.
Gruß,
Simon2.
-
Simon2 schrieb:
Begründung: Prinzipiell gilt, dass die "Rückschließbarkeit" von einem Hash auf seinen OText durch dessen "Wertebereich" verringert wird. Ist auch klar: Paddest Du mit "0", erhält derselbe Text auch immer denselben Hash, paddest Du mit Zufallswerten, dann nicht.
Hm, klingt für mich nicht unbedingt überzeugend. Ich denke, das hängt sehr stark von der Hash-Funktion ab. Für konkrete Hash-Funktionen mag das natürlich stimmen (ich hab keine Ahnung, wie's bei der hier genannten aussieht).
So allgemein formuliert wie hier klingt mir das ein bißchen so wie die Leute, die nicht einfach rand aufrufen können, sondern 3 mal rand, damit noch was rechnen das als neuen seed nehmen und das Ergebnis vom nächsten rand dann als viel zufälliger darstellen. Deswegen frage ich nach.
Meine Intuition gibt das nicht unbedingt her. Ich würde von einer guten Hash-Funktion erwarten, daß sie gerade Dinge, die über weite Strecken ähnlich sind (viele 0en gepaddet) schön auseinanderreißt.
Wenn aber sowieso so viele 0en davorstehen macht es vielleicht sogar Sinn sich ein eigenes Hash-Verfahren auszudenken, das davon profitieren kann.
-
Jester schrieb:
So allgemein formuliert wie hier klingt mir das ein bißchen so wie die Leute, die nicht einfach rand aufrufen können, sondern 3 mal rand, damit noch was rechnen das als neuen seed nehmen und das Ergebnis vom nächsten rand dann als viel zufälliger darstellen.
*hust* Spieleprogrammierer *hust*
-
Jester schrieb:
...Ich denke, das hängt sehr stark von der Hash-Funktion ab. ...
Definitiv. Aber: Eine noch so gute Hashfunktion nützt nichts, wenn man sie nicht sorgfältig einbindet - aber wie gesagt: Wir haben vermutlich andere Szenarien vor Augen. Geht es dabei nur um eine "eindeutige Indizierung" (z.B. in einer DB) oder einer "technischen Prüfsumme" ("Sicherung gegen versehentliche Veränderung")", spielt es tatsächlich keine Rolle .
Mir schwebte eher die Verwendung in einer Signatur vor, bei der gegen absichtliche Fälschung gesichert werden soll....hier kann man mit "statischem Padding" eine Art "Wörterbuchangriff" durchführen, was mit dynamsichem Padding nicht geht.Sagen wir einfach mal so: In bestimmten Zusammenhängen profitiert man von (echten) Zufallszahlen, in anderen schaden sie nichts. Netto bleibt ein Gewinn.
Jester schrieb:
...So allgemein formuliert wie hier klingt mir das ein bißchen so wie die Leute, die nicht einfach rand aufrufen können, sondern 3 mal rand, damit noch was rechnen das als neuen seed nehmen und das Ergebnis vom nächsten rand dann als viel zufälliger darstellen. Deswegen frage ich nach. ...
Das kann ich verstehen - es gibt viele "Pseudokryptographen" da draussen. Ich sprach aber deswegen auch von absichtlich von echtem Zufall, weil mir durchaus bewusst ist, wie wichtig und gleichzeitig schwierig es ist, diesen herzustellen. BTW: Ich verstehe immer noch nicht, warum in einem so komplexen System wie einem heutige PC nicht standardmäßig ein Hardware-Zufallszahlengenerator eingebaut ist ... ist eher cent-Kram und würde viele Stunden (und Fehler bei) Entwicklungsstunden überflüssig machen.
Gruß,
Simon2.