Aber warum sollte man eine "Umkehrfunktion" nicht auch dazu benutzten, Raimbow Tables zu erzeugen. Man könnte ja auch dabei das Pferd von hinten aufzäumen.

Ja, wenn man eine Umkehrfunktion erstmal hat, dann braucht man u.U. immer noch sowas wie (kleinere) Rainbow-Tabellen (etwa in dem Beispiel zumindest eine, die alle Hashs der durch drei teilbaren Zahlen liefert), d.h. die Dinge gehen ineinander ueber. Nur der klassische Rainbow-Angriff ist eben ein Angriff *ohne* jede Kenntnis irgendeiner Art Umkehrfunktion.

Allerdings kann ich mir auch vorstellen, dass es zu manchen "Prüfwerten" gar keine Urbilder gibt.

Ja, das ist im allgemeinen so. In meinem Beispiel etwa waere wie angesprochen keine Zahl mit Rest 2 modulo 3 ein tatsaechlich vorkommender Hashwert.

Aber nochmal zurück zur Passwortsicherheit. Könnte man die nach diesen Überlegungen nicht erhöhen, wenn man z.B. vorschreibt, dass das Passwort genau 12 Zeichen lang sein muss? Damit würden alle zurückgerechneten Urbilder, die weniger oder mehr als 12 Zeichen hätten, als ungültig erkannt werden, auch wenn sie denselben Prüfwert ergeben würden.

Das Problem wird im Grunde bereits durch den Gebrauch von Salts geloest. Szenario:

Mein Passwort ist "abc", in der Datenbank gespeichert ist md5("abcsalt"). (Also "salt" ist der Salt). Jemand von aussen kennt nun diesen MD5-Wert und findet nun ein anderes Wort "neueswort", so dass md5("neueswort") == md5("abcsalt"). Das nuetzt ihm nichts, da nun bei Eingabe dieses Wortes der md5 von "neueswortsalt" gegen den gespeicherten Hash verglichen wuerde. Selbst wenn er den Salt kennt, wuerde ihm das a priori nicht viel helfen. Einen Wert zu finden, der zusammen mit einem gegebenen Salt auf einen gegebenen Hash abgebildet wird, ist noch eine erheblich schwierigere Attacke.

Viele Gruesse,
der Bademeister