Unbelievable Shit: Schlüssel für TrueCrypt-Container passt nicht mehr

Das unvorstellbare ist passiert, ich komme nicht mehr an die Daten auf meiner Festplatte, bzw. einen wichtigen Teil davon.

Da ich mehrere Container verschlüsselt habe, kann es sein das ich mit den Schlüsseln was verwechselt habe, aber ich bin sicher inzwischen alles ausprobiert zu haben.

Ich vermute es liegt an folgendem: Vor kurzem bin ich auf Linux (Ubuntu Hardy Heron) umgestiegen, und da gibt es ja Unterschiede mit den Zeichensätzen.
Der Schlüssel liegt in einer .txt Datei und dürfte eigentlich nicht verändert worden sein, vielleicht hab ich aber schon aus versehen mal abgespeichert. Das Dateisystem ist Fat32.

Was könnte sich da alles verändert haben? z zu y? Naja, die Sonderzeichen machen oft probleme, aber in diesem Schlüssel stecken keine drin, sondern nur groß- und kleinbuchstaben sowie zahlen. Wenn es dieser Schlüssel ist ist er etwa 50 Stellen lang.

Der Zeichensatz ist leider mein einziger Ansatz, aber was genau da passiert sein kann... ich tappe so dermaßen im dunkeln...

Das lustige, in dem Container stecken auch passwörter für andere anwendungen und viele wichtige persönliche daten, aber auch aufzeichnungen mit guten ideen und erinnerungen (Tagebuch für über ein Jahr)

Der ganze Container ist nur 50 MB groß... vielleicht macht das das Entschlüsseln per Bruteforce irgendwie leichter...
achja, die schlüssel für andere container passen ausgezeichnet, obwohl in der darstellung sonderzeichen nicht korrekt angegeben werden, aber per copy and paste haut es einfach hin.

Also wenns noch irgendeinen Weg gibt an die Daten ranzukommen...
 
Wieviele Versuche bei einem 50-Stelligen Passwort mit Groß- und Kleinbuchstaben und Zahlen nötig sind / sein können kannst du dir ausrechnen oder? ;) (Anzahl der möglichen Zeichen ^ 50)

Wenn es vorher unter Windows ging probiers doch einfach nochmal unter Windows.


btw: Wie merkt man sich ein 50-stelliges Passwort?
 
Hatte ich vergessen zu erwähnen, rückwirkend bei Windows hat es dann auch nicht mehr funktioniert, daher vermute ich das Linux irgendwie den Zeichensatz geändert hat.
 
Also wenn es am Zeichensatz liegt müssten jetzt durch falsches öffnen/speichern seltsame Zeichen in dem Schlüssel drin stehen. Dann kann man bei wenigen Sonderzeichen eventuell alle Kombinationen von ö, ä, ü, Ö, Ä, Ü, ß ausprobieren.

Wie sieht denn der Schlüssel aus? Findet man dort ungewöhnliche Zeichen oder Fragezeichen (?) ?

Es könnte übrigens auch an unsichtbaren Steuerzeichen liegen. Hatte da bei der Arbeit mal erhebliche Probleme damit und erst als ich mir den Inhalt der Datei als Hex-Code anzeigen hab lassen hab ich dann gemerkt, dass am Anfang der Datei durch den Notepad von Windows ein unsichtbares Steuerzeichen war, das dann falsch interpretiert wurde.

Du kannst (wenn der Schlüssel normal aussieht) also auch mal versuchen ihn einfach neu abzutippen dann sind die neuen Steuerzeichen nicht mehr drin.

Es wäre mal noch interessant zu wissen, mit welchem Zeichensatz die Datei momentan gespeichert ist. So Editoren wie JEdit zeigen dir das an (und laden die Datei bei einem anderen Zeichensatz übrigens aus Sicherheitsgründen nicht).


Gruß
 
Hallo,
kopierst du den Key aus dem File oder gibst unter Truecrypt an, dass die Datei dein Keyfile ist (ist das mit Truecrypt überhaupt möglich)?

Wenn zweiteres:
Truecrypt wird nicht die Buchstaben da auslesen und als Zeichen nutzen sondern eben die Datei als binär-Datei, also direkt die Bytes der Datei, (nicht des inhaltes).

Wenn du unter Windows eine Datei mit z.B. ISO-8859-1, ANSI, ASCII oder was auch immer abgespeichert hast, kenn den default Zeichensatz von Notepad nicht, diese dann unter Linux öffnest, dann kann es sein, dass der Inhalt dir ganz normal dargestellt wird, wenn der Linux Editor das richtig interpretiert.

Beim Speichern kann es aber passieren, dass der Editor unter Linux es im UTF-8 Format abspeichern möchte, zuvor den Inhalt im Editor konvertiert und dann die Datei überschreibt, diesmal aber im UTF-8 Format.

Der Inhalt bleibt exakt der selbe, beide Dateien würden dir gleich im Editor angezeigt werden.

Aber:
Da die Datei nun im UTF-8 (oder UTF-32) Format ist, belegen manche Zeichen mehr als ein Byte, haben eine andere Representation u.ä.
Wenn Truecrypt es nun aber als Keyfile einliest, liest es die Bytes aus, und da hat sich die Datei verändert (wird aber nur mit nem HexEditor sichtbar).


Wie gesagt, nur eine Vermutung. Ich weiß gar nicht, ob Truecrypt überhaupt Keyfiles zulässt.

Lösungen:
Mal schauen welche Größe die Datei hast. Bei 50 Zeichen sollten es genau 50 Byte sein. Mehr wäre schlecht.
Sonst mal den Inhalt (unter Windows) kopieren, in eine neue Datei einfügen und versuchen mit dieser Datei das Volumen zu öffnen, sofern truecrypt keyfiles verwendet.


Ansonsten ist evt. der Header des Volumens beschädigt? Hast du einen Backup davon?
 
Wie gesagt, nur eine Vermutung. Ich weiß gar nicht, ob Truecrypt überhaupt Keyfiles zulässt.
Man kann Dateien angeben (können binäre sein) die als keyfiles dienen. Beliebig viele.

Zusätzlich kann man auch noch ein PW verwenden.

Elderan könnte in dieser Hinsicht recht haben; Da TC auch binäre files als Keyfiles akzeptiert, muss es sie zwangsläufig binär einlesen; d.h. wenn die Daten in einem anderen Format gespeichert worden sind, gehts nicht mehr...
 
Kann es evtl. auch sein das du denn Header irgendwie zerstört hast?
Weis jetzt nicht genau wie das bei Containern ist aber mir ist das mal bei einer ganzen TC-Partition passiert.
Lösung: Nach stundenlangem Googlen fand ich eine modifizierte truecrypt.sys mit der sich das Volume auch ohne Header-Backup auslesen lies.
Wenn du denkst das dein Problem in die Richtung geht kann ich nochmal versuchen das Teil wiederzufinden ;)
 
Lösung: Nach stundenlangem Googlen fand ich eine modifizierte truecrypt.sys mit der sich das Volume auch ohne Header-Backup auslesen lies.
Ja, dann hast du die verschlüsselten daten ausgelesen.


Das bringt aber nichts, oder?

Es werden ja random Daten erstellt, mit denem werden deine eigentlichen Daten verschlüsselt. Nur dieser Random-Daten-Key wird dann mit deinem PW/Keyfile verschlüsselt und stellt dann diesen "Header" dar. Deswegen kann man auch relativ schnell sein Passwort ändern, da nur der Header mit dem alten entschlüsselt und dem neuen verschlüsselt werden muss.

Der (entschlüsselte) Header ist der Weg zu deinen Daten. Ein PW ohne Header bringt gar nichts.

So habe ich das verstanden. :)
 
Danke für die guten Tipps. :)

also es sind wie gesagt keine Sonderzeichen drin, nur groß- und kleinbuchstaben sowie zahlen
Also wäre 26+26+10 = 62^50 zu bruteforcen ^^
auch keine keyfile, ich kopier es immer rein.

was ich jetzt probiert hab:
abtippen - funzt nicht
in eine andere txt. im windows kopieren - funzt nicht
nochmal alle passwörter probiert die irgendwie in frage kommen (das sind so einige) - funzt nicht


es gäbe noch die Variante das ich ein ganz anderes passwort gewählt habe, das mit ein bisschen glück kürzer ist als 50 stellen.

Bis zu wieviel Stellen kann man heute so im sinnvollen maße bruteforcen?
Und kann mir da jemand ein programm empfehlen? (vllt. wg. hackerparagraphen und so schwierig :/)
 
bruteforce im eigentlichen Sinne kannst du vergessen. Noch mal deutlich: Vergiss es. :D

Das Einzige was dir helfen kann ist, wenn du dein ursprungs Password noch ungefähr weist, und dann einen Wordlist Generator verwendest um alle in Frage kommenden Passwörter zu generieren und diese dann durchgehst. Dann hast du bedeutend weniger Versuche.

Wenn du dich also noch an Teile des Passwortes erinnern kannst sieh dir die Threads hier mal an:
Attacke auf TrueCrypt Partition
Truecrypt Passwort - Bei der Eingabe unbekannten Tippfehler eingegeben
 
Dann interessiert mich doch zumindest wie lange es theoretisch dauert, bis die Rechnerentwicklung weit genug ist um ensprechendes Passwort per Bruteforce zu knacken.

10-20 Jahre?

Was wenn man einen Supercomputer mietet?
 
ist diese frage echt dein ernst? rechne das doch einfach mal selber grob durch (kannst dabei sogar großzügig runden)

gehen wir mal von computern mit 3ghz aus. im idealfall (pro key-test nur ein takt und du kannst wirklich alle takte auslasten) wären das 3.000.000 oder 3*10^6 keys pro sekunde. an einem tag (86400 sek) wären das ca. 2,6*10^11 keys. pro jahr kommst du dann auf 9,5*10^13

selbst wenn sich die rechenleistung um den faktor 1.000.000 vergrößern würde, dann würdest du im jahr nur 9,5*10^19 keys schaffen und wärst somit noch welten von dem entfernt, was du überprüfen müsstest. und der faktor 1.000.000 ist hier auch sehr sehr unwahrscheinlich ;)
 
Hallo,
gehen wir mal von computern mit 3ghz aus. im idealfall (pro key-test nur ein takt und du kannst wirklich alle takte auslasten) wären das 3.000.000 oder 3*10^6 keys pro sekunde.
geil! Schaff mit nem AMD 1,8 Ghz knapp 5.500.000 (5,5 Millionen) MD5 Hash pro Sekunde, wobei der ja noch weit darunter getaktet ist (~1,2 Ghz?).

Also, Giga ist natürlich 10^9, also bei 3 Ghz also 3 Mrd. Takte pro Sekunde. Wenn man dann noch pipelining einsetzt, erhöht sich dieses weiter. Wobei du natürlich deutlich mehr als 1 Takt brauchst, um den Header zu entschlüsseln.


Aber selbst sehr großzügige Maßstäbe helfen nicht.

Der momentan schnellste Rechner der Welt, IBM Roadrunner, mit rund 1 Peta-FLOPS, schafft also pro Sekunde 10^15 Gleitkommeroperationen.
Wenn man nun mit einer Gleitkommeroperation einen Key testen könnte, was die Generierung eines Keys beinhaltet, Entschlüssung des Header, Überprüfen auf Richtigkeit, wären dies 62^50/10^15 = 4*10^74 Sekunden, oder rund 10^67 (10 Undezillion) Jahre.
Selbst bei 1 Milliarden Roadrunnern im Keller, bräuchte man weiterhin 10^58 Jahre.


Deswegen ist es auch total unsinn, ein 50 Zeichen langes PW zu nutzen, selbst wenn man paranoid ist. 12 Zeichen reichen selbst für sehr paranoide Menschen i.d.R. aus.
 
Original von Elderan
Also, Giga ist natürlich 10^9, also bei 3 Ghz also 3 Mrd. Takte pro Sekunde. Wenn man dann noch pipelining einsetzt, erhöht sich dieses weiter. Wobei du natürlich deutlich mehr als 1 Takt brauchst, um den Header zu entschlüsseln.

Mist, jedes Mal das Gleiche mit diesen Einheiten. Man sollte halt nicht unter Zeitdruck schreiben :D Aber wie du dann ja gleich noch weitergerechnet hast macht selbst der Faktor 1000, um den ich mich vertan habe, überhaupt nichts mehr aus zu realistischer weise mit bf Erfolg zu haben
 
Zurück
Oben