Ich habe mich jetzt mal etwas näher mit Rainbowtables beschäftigt und nun so langsam verstanden wie die Dinger funktionieren. Ich habe auch manche Quellen gelesen die sich widersprechen. Deshalb poste ich mal hier, wie ich das ganze verstanden habe und wo bei mir noch Unklarheiten existieren. Die Grafiken dazu habe ich selbst erstellt.
Wenn irgendwas an meinem Text oder an den Grafiken falsch ist, dann weißt mich bitte darauf hin!
nur der vollständigkeit halber, da beavisbee den wichtigsten teil unterschlagen hat
:
eine rainbowtable ist keine einfache lookup table ...
sie ist vielmehr eine ansammlung von ketten nach dem schema Klartext -> [hashfunkt] -> hash-> [abbildung] -> anderer Klartext -> [hashfunkt] -> anderer hash -> .... -> letzter hash der kette
wobei jede kette durchaus aus tausenden oder noch mehr einträgen bestehen kann, von denen aber nur der erste klartext, und der letzte hash gespeichert werden
1 Frage: Der erste Klartext wird gespeichert, damit man einen Wert hat um die Kette zu Durchlaufen? (Und es ist ja außerdem möglich, dass es das gesuchte Passwort ist)
für ein lookup in dieser tabelle müssen die ketten nach ihrem letzten hash sortiert werden ...
sucht man nun den klartext zu einem hash, kann man nachsehen ob einer der letzen hashes der ketten mit dem gesuchten übereinstimmt ... in dem fall rekonstruiert man die kette, und hat mit dem letzen klartext den passenden klartext zum hash gefunden ...
Das müsste folgendes Bild doch repräsentieren?
Ketten
Also für KT1 wird ein beliebiger Klartext gewählt. Der wird dann mit der Hashfunktion (HF) gehashed. Das Ergebnis ist dann HKT1. Auf diesem Hash wird die Reduktionsfunktion (RF1) angewandt, das Ergebnis davon ist dann KT11, der wird dann wieder gehashed und davon wird wieder nen Klartext gebildet(RF2), der dann wieder gehashed wird.
2 Frage: So wie ich das verstanden hab, ist jede Zeile eine Kette. Aber nur grau unterlegten Spalten werden gespeichert? Nach welchen Kriterien werden die Startwörter gewählt? Wird geschaut welche noch nicht duch eine Reduktionsfunktion vorgekommen sind?
Ermittlung des Passworts, wenn der Hash sofort gefunden wird
Der Hash (HPWx) von dem Passwort(PWx) liegt vor, das Passwort jedoch nicht. Dies soll nun ermittelt werden.
Für die Passwortermittlung wird ein zweistufiger Prozess benötigt:
1 Stufe
Zuerst wird geprüft, ob der Hash HPWx in der rechten Spalte der Rainbowtable vorkommt. In diesem Beispiel trifft dies in der zweiten Zeile zu. Also HKT22 und HPWx stimmen überein.
2 Stufe
Nun muss der Klartext von HKT22 ermittelt werden, also in diesem Fall KT22. Dieser ist jedoch nicht in der Table gespeichert, aber es ist möglich diesen zu "rekonstruieren". Dazu wird die Kette mit dem Startwert KT2 so lange durchlaufen bis ich den KT22 ermittelt habe, KT22 stimmt dann mit PWx überein.
Reduktionsfunktion
Das ist, so wie ich das verstanden habe, die hauptsächliche Herausforderung. Denn eigentlich muss die gewährleisten, dass auf Basis eines Hashes ein eindeutiger Klartext generiert wird, der in der ganzen Rainbowtable nur einmal vorkommt.
3 Frage: Zu Reduktionsfunktionen habe ich jetzt nicht so super Quellen gefunden. Eine besagt, dass die Redunktionsfunktion immer unterschiedlich sein muss. (http://www.zdnet.de/sicherheits_ana...cht_mehr_sicher_story-39001544-41544658-2.htm)
Da sonst die die Ketten ab einer Kollision (also die Reduktionsfunktion liefert das gleiche Passwort bei 2 unterschiedlichen Hashs) gleich wär. Das klingt für mich auch schlüssig. Ist dann die Reduktionsfunktion pro Spalte gleich? Oder ist die immer komplett unterschiedlich? Für mich wärs schlüssig wenn die pro Spalte gleich wär, so kann ich die Ketten dann auch leichter rekonstruieren. So hab ich es auch in den Grafiken dargestellt.
ist der gesuchte hash nicht das ende einer kette, kann man auf ihn eine abbildung (oft auch "reduktionsfunktion" genannt) anwenden, die daraus "irgend einen"(hier würde die erklärung zu weit abschweifen) klartext macht den man wiederum hashed ... der resultierende hash wird nun wieder in den kettenenden gesucht ... wird er nicht gefunden, wiederholt man das spielchen, wird er gefunden rekonstruiert man die betreffende kette und findet in ihr hoffentlich den originalhash wieder ... falls ja, ist der vorausgehende klartext der gesuchte, falls nein, haben wir einen false positive ... das ganze spielchen setzt man fort bis man die kettenlänge erreicht hat, oder ein treffer erzielt wurde ...
Ermittlung des Passworts, wenn der Hash nicht sofort gefunden wird
1 Stufe
Zuerst wird geprüft, ob der Hash HPWx in der rechten Spalte der Rainbowtable vorkommt. Dies ist nicht der Fall. Also wird auf dem Hash HPWx die Reduktionsfunktion RF2 angewandt, das Ergebniss ist dann KTy1. Der wird dann zum Hash HKTy1 gehashed. Jetzt wird nach HKTy1 in der rechten Spalte gesucht, dieser stimmt mit dem Hash HKT22 in der zweiten Zeile überein.
2 Stufe
Jetzt ist klar, in welcher Kette das gesuchte Passwort vorkommt. Die Kette wird mit dem Startwort KT2 durchlaufen bis KT21 ermittelt wurde. KT21 stimmt mit dem gesuchten Kennwort überein.
Die Grafik zeigt außerdem an, welche Werte nach meinem Verständnis noch übereinstimmen müssten
Reduktionsfunktion
4 Frage: Wenn die Reduktionsfunktionen bei jeder Iteration neu sind, aber in jeder Spalte gleich. Dann müsste doch die Reduktionsfunktion die auf HPWx angewand wird, die gleiche sein, die auf HKT21 angewand wird? So ist es auch in der Grafik zu sehen. Die Grafik bezieht sich auf den Text
"Ermittlung des Passworts, wenn der Hash nicht sofort gefunden wird"
![[HaBo]](/styles/default/logoklein.png){kind=small}
