Hallo zusammen, angenommen, ich möchte einen vorhandenen Hash-Wert "kürzen", also von beispielsweise 128 Bit nur 32 Bit nutzen. Intern wird dies ja zum Beispiel bei SHA-224 gemacht. Frage: aufgrund des Lawineneffekts müsste es ja egal sein, welche Bits ich nehme, richtig? Ich meine auch bei diversen Downloads schon gesehen zu haben, dass nur die letzten n Zeichen des Hash-Werts angegeben werden. Viele Grüße
Gerd schrieb: > Da kannste auch wieder CRC32 nehmen, ist ähnlich clever Das beantwortet die Frage aber nicht wirklich oder? Vielleicht erkenne ich es auch nur nicht. Jan H. schrieb: > Ja, sehe ich auch so. Danke dir! :-) Wobei man sich vermutlich, wenn man es genauer wissen will, jeden Algorithmus im Detail ansehen müsste um die "Qualität" des Lawineneffekts zu beurteilen, fällt mir gerade ein.
Dennis S. schrieb: > Hallo zusammen, > angenommen, ich möchte einen vorhandenen Hash-Wert "kürzen", also von > beispielsweise 128 Bit nur 32 Bit nutzen. Intern wird dies ja zum > Beispiel bei SHA-224 gemacht. Die Konsequenzen des kurzen Hashs sind Dir betimmt klar, etwa die deutlich höherer Wahrscheinlichkeit von Kollisionen. Ob das von Bedeutung ist, hängt davon ab was Du vor hast. > Frage: aufgrund des Lawineneffekts müsste es ja egal sein, welche Bits > ich nehme, richtig? Ich meine auch bei diversen Downloads schon gesehen > zu haben, dass nur die letzten n Zeichen des Hash-Werts angegeben > werden. Bei einer idealen Hashfunktion sollte das egal sein, möglicherweise haben einige reale Hash Implementationen aber Schwächen diesbezüglich.
Wenn es eine CSPR Hashfunktion ist, ja. Die Kollisionswahrscheinlichkeit steigt dann aber entsprechend zur Kürzung. Oder Du nimmst gleich sowas wie BLAKE2, da kannst Du die Länge in Grenzen wählen.
kommt ja drauf an was Du vor hast. der Hashwert ist ja niemals eine UNIQUE ID und je kürzer er ist, desto grösser die Wahrscheinlichkeit einer kollision, das gilt auch für die ersten/letzten x bit eines eigentlich langen hashwertes natürlich. Der Lawineneffekt besagt nur, dass jedes hereinkommende bit jedes ausgegebene Bit im fertigen Hash mit 50% wahrscheinlichkeit (im idealfall) ändern kann und deswegen ein zurückrechnen nahezu unmöglich wird. Es bedeutet nicht, dass Du Dich darauf verlassen kannst dass zwei unterschiedliche Eingaben(eingabedateien) auch einen unterschiedlichen Hash und noch weniger unterschiedlichen TEIL eines Hashes generieren. Auf die Spitze getrieben: hast Du 500 Dateien und testest nur den letzten bit des hashes, hast Du im besten Fall 2 verschiedene Ergebnisse, du kannst aber auch nur eins haben. (und die chancen sind garnichtmal schlecht dafür) 'sid
ZF schrieb: > Die Konsequenzen des kurzen Hashs sind Dir betimmt klar. Ja, das ist klar. Ergo70 schrieb: > Wenn es eine CSPR Hashfunktion ist, ja. Die Abkürzung scheint nicht besonders verbreitet zu sein. Kannst du mal kurz erläutern was das heißen soll? Ergo70 schrieb: > Oder Du nimmst gleich sowas wie BLAKE2, da kannst Du die Länge in Grenzen wählen. Danke für den Hinweis, das schaue ich mir mal an. sid schrieb: > Auf die Spitze getrieben: > hast Du 500 Dateien und testest nur den letzten bit des hashes, > hast Du im besten Fall 2 verschiedene Ergebnisse, > du kannst aber auch nur eins haben. (und die chancen sind garnichtmal > schlecht dafür) Natürlich ist es immer eine Frage der Wahrscheinlichkeiten. Und bei einem Bit ist das sicherlich (wie du ja sagst) ein Extremfall. Ergänzend vielleicht, dass ich keine kryptographische Anwendung im Sinn hatte, sonder eher ein prinzipielles Gedankenspiel. Viele Grüße
Beitrag #6278169 wurde von einem Moderator gelöscht.
Beitrag #6278239 wurde von einem Moderator gelöscht.
Dennis S. schrieb: > Ergänzend vielleicht, dass ich keine kryptographische Anwendung im Sinn > hatte, sonder eher ein prinzipielles Gedankenspiel. Naja, aber Du verstehst was ich meine.. bei acht bit sind's eben nur 256 Möglichkeiten, bei 10 1024 etc.pp je mehr bit Du also hast desto grösser ist dein Varianzpool sozusagen. UNd wenn Du nur 16 oder 32bit möchtest (weil nicht mehr platz ist zum speichern zB) dann würde ich zu einem 16 oder 32bit algorithmus raten (wie CRC16, CRC32 zB) statt einen 128 oder 256bit hash zu kürzen. die sind normalerweise schneller und hoffentlich weniger Anfällig für überschneidungen innerhalb deines use-case. Aber, natürlich sollte jeder hashwert eines guten Algorithmus kürzbar sein, (eben weil sich jedes bit idealerweise mit einer Chance von 50% ändert sobald sich ein einzelnes bit am Eingang ändert) also letzen x bit oder jedes dritte/vierte/fünfte wäre sogar egal. Um sicher zu gehen, empfehle ich Dir aber einen test mit ein paar tausend testdateien (vllt hast Du ja schon Dateien die so gehasht werden sollen) so können implementations-fehler frühzeitig entdeckt werden, und son paar tausend hashes sind ja schnell berechnet am computer. einfach mal diverse algo's ausprobieren und stoppen auf der Zielhardware ;) 'sid
Falls Du Angst haben solltest, dass Deine bitauswahl schlecht ist, einfach alle Bits n-bitweise verXOren.
Tja bei den kryptographisch fundierten Antworten wundert mich manches nicht. Antwort an de to: ist der hash kryptographisch ok, kann jedes Bit genommen werden. XOR, Crc sind globulis. Kann man machen, hilft aber nix.
Nadelstreifen-Fabrkant schrieb: > ist der hash kryptographisch ok, kann jedes Bit > genommen werden. Tja, das weiß man ja erst später. Jeder Veröffentlicher einer neuen Hash-Funktion hält die für kryptografisch OK. Die Schwächen werden dann erst so nach und nach von anderen aufgedeckt.
Naja, es gibt sicher Hash-Funktionen die "etablierter" sind als andere. Ich werde mal ein paar Benchmarks machen. Danke für eure Inspirationen.
CRC und sowas wie SHA verfolgen unterschiedliche Ziele. CRC findet Fehler (und ist darin besser als SHA), SHA ist nicht invertierbar (und ist darin besser als CRC). Bei den kryptographischen Algorithmen ist es "sicherlich" (im Sinne von, wenn es nicht so wäre, gälte der Algorithmus sicherlich als kaputt) egal, welche Bits du nimmst. Bedenke nur, dass die Kollisionswahrscheinlichkeit bei 2 Werten sqrt(N) ist, wobei N die Anzahl möglicher Hashwerte ist. Wenn du damit für deine Anwendung noch auf eine Kollisionswahrscheinlichkeit kleiner 10^-10 kommst -- passt alles.
Beitrag #6279645 wurde von einem Moderator gelöscht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.