Rainbow Tables: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
(Die Seite wurde neu angelegt: „*Bei dieser Attacke liegen die Passwörter aus einer Liste schon gehashed vor. *Somit muss nicht mehr bei der Überprüfung gehashed werden. *Das bringt einen…“)
 
 
(6 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
*Bei dieser Attacke liegen die Passwörter aus einer Liste schon gehashed vor.
+
=Rainbow Tables=
*Somit muss nicht mehr bei der Überprüfung gehashed werden.
+
*Eine volle Hash-Tabelle für alle Passwörter wäre Petabytes groß - unbaubar.
*Das bringt einen enormen Zeitvorteil.
+
*Rainbow Tables schrumpfen das auf ein paar Hundert GB, damit es überhaupt auf eine Platte passt.
*Der Speicherbedarf ist allerdings auch wesentlich höher.
+
*Bezahlt wird's mit Rechenzeit beim Suchen.
 +
 
 +
=Idee=
 +
*Mittelweg zwischen Brute Force und voller Hash-Tabelle
 +
*Brute Force: nichts gespeichert, alles live hashen → langsam, kein Platz
 +
*Volle Tabelle: alles gespeichert → schnell, aber riesig (Petabytes)
 +
*Rainbow Table: nur Teil gespeichert, Rest beim Suchen nachrechnen → tauscht Platz gegen Rechenzeit
 +
 
 +
=Zwei Funktionen=
 +
;H = Hash (Passwort -> Hash)
 +
*normale Richtung
 +
;R = Reduktion (Hash -> Passwort-String)
 +
*keine Umkehrung, erzeugt nur wieder etwas passwortförmiges
 +
 
 +
=Kette=
 +
*abwechselnd H und R anwenden
 +
[[Datei:Rainbow.png|900px]]
 +
*nur Anfang und Ende jeder Kette speichern
 +
*1000 Glieder pro Kette -> 1 Eintrag statt 1000 -> Platzgewinn
 +
 
 +
=Suchen=
 +
*ab eigenem Hash selbst Kette bauen (R, H, R, H ...)
 +
*nach jedem Schritt prüfen: Treffer auf gespeichertes Ende?
 +
*Treffer -> zugehörigen Anfang nehmen
 +
*Kette von vorne durchrechnen -> darin liegt das Passwort
 +
 
 +
=Warum "Rainbow"=
 +
*pro Position andere Reduktionsfunktion (R1, R2, R3 ...)
 +
*verhindert Zusammenlaufen/Kollision der Ketten
 +
*Abfolge der Funktionen = "Regenbogen"

Aktuelle Version vom 25. Juni 2026, 05:10 Uhr

Rainbow Tables

  • Eine volle Hash-Tabelle für alle Passwörter wäre Petabytes groß - unbaubar.
  • Rainbow Tables schrumpfen das auf ein paar Hundert GB, damit es überhaupt auf eine Platte passt.
  • Bezahlt wird's mit Rechenzeit beim Suchen.

Idee

  • Mittelweg zwischen Brute Force und voller Hash-Tabelle
  • Brute Force: nichts gespeichert, alles live hashen → langsam, kein Platz
  • Volle Tabelle: alles gespeichert → schnell, aber riesig (Petabytes)
  • Rainbow Table: nur Teil gespeichert, Rest beim Suchen nachrechnen → tauscht Platz gegen Rechenzeit

Zwei Funktionen

H = Hash (Passwort -> Hash)
  • normale Richtung
R = Reduktion (Hash -> Passwort-String)
  • keine Umkehrung, erzeugt nur wieder etwas passwortförmiges

Kette

  • abwechselnd H und R anwenden

Rainbow.png

  • nur Anfang und Ende jeder Kette speichern
  • 1000 Glieder pro Kette -> 1 Eintrag statt 1000 -> Platzgewinn

Suchen

  • ab eigenem Hash selbst Kette bauen (R, H, R, H ...)
  • nach jedem Schritt prüfen: Treffer auf gespeichertes Ende?
  • Treffer -> zugehörigen Anfang nehmen
  • Kette von vorne durchrechnen -> darin liegt das Passwort

Warum "Rainbow"

  • pro Position andere Reduktionsfunktion (R1, R2, R3 ...)
  • verhindert Zusammenlaufen/Kollision der Ketten
  • Abfolge der Funktionen = "Regenbogen"