GLF

Ja. Denn es ist aufs äußerste extrem unwahrscheinlich (dennoch glaube ich mathematisch nicht vollständig umöglich), dass eine Kollision nicht nur z.B. den gleichen SHA512/Whirlpool/RipeMD Hash erzeugt, sondern gleichzeitig auch noch mit dem PBKDF2 den gleichen Schlüssel.

Das wäre eine doppelte Kollision sozusagen.

Ovid hat geschrieben:Man kann die andere Form (Hash) nicht mehr in das Original-Passwort zurückführen.
Weiterhin braucht man für die Entschlüsselung der Festplatte das Original-Passwort. Die andere überführte Form (Hash) ist dafür nutzlos. Deswegen kann man die zu Vergleichszwecken problemlos gespeichert lassen.

Wozu sollte etwas gespeichert werden?

Und Hash, Pass, Key ... ich seh da nicht mehr durch

Annika hat geschrieben: Wozu sollte etwas gespeichert werden?

Wenn man nichts speichern würde und direkt entschlüsseln würde (das könnte man tatsächlich machen), dann besteht aber die Gefahr, dass die CPU versucht totalen Datenmüll auszuführen und das kann zu Datenverlust führen.

Ohne etwas zu speichern kann man am Ende eben nicht sagen ob überhaupt das richtige Passwort eingegeben wurde.
Das heißt: Entweder müsste man sich sachkundig umgucken ob die Daten valide sind, oder man startet auf gut Glück (was in die Hose gehen kann).

Danke Ovid für die Erklärung. Ich hoffe die ist genehmigt für die Kleinen

Ovid hat geschrieben:Wenn man nichts speichern würde und direkt entschlüsseln würde (das könnte man tatsächlich machen), dann besteht aber die Gefahr, dass die CPU versucht totalen Datenmüll auszuführen und das kann zu Datenverlust führen.

Streich das, das ist quatsch.

Ohne etwas zu speichern kann man am Ende eben nicht sagen ob überhaupt das richtige Passwort eingegeben wurde.

Das ist richtig. Der Hash dient als Vergleich, ob das eingegebene PW richtig ist. Daher wird der Hash gespeichert, aus ihm lässt sich das PW jedoch nicht zurückrechen. Google: Einwegfunktion mit Falltür (falls mans vertiefen will).

Baumkrone hat geschrieben: Streich das, das ist quatsch.

Nö. Der EIP (Instruktionszeiger) von der CPU wird auf entschlüsselten Startsektor gesetzt. Da kann totaler Müll an Instruktionen stehen, wenn der falsche Schlüssel zum entschlüsseln benutzt wird.
Es kann natürlich sein, dass es dazwischen noch einen Sanity-Check auf den Windows Bootloader gibt, aber so gut kenne ich den Sourcecode auch nicht.
Hast du da entsprechendes?

Baumkrone hat geschrieben: Das ist richtig. Der Hash dient als Vergleich, ob das eingegebene PW richtig ist. Daher wird der Hash gespeichert, aus ihm lässt sich das PW jedoch nicht zurückrechen.

Meine Rede:

Ovid hat geschrieben: Das Passwort wird nicht einfach so gespeichert, sondern "gehashed", also überführt in eine andere Form, die aber für das Passwort mit enorm hoher Wahrscheinlichkeit eindeutig ist.
Das Besondere ist: Rückwärts geht das nicht. Man kann die andere Form (Hash) nicht mehr in das Original-Passwort zurückführen.

Ovid hat geschrieben:

Baumkrone hat geschrieben: Streich das, das ist quatsch.

Nö. Der EIP (Instruktionszeiger) von der CPU wird auf entschlüsselten Startsektor gesetzt. Da kann totaler Müll an Instruktionen stehen, wenn der falsche Schlüssel zum entschlüsseln benutzt wird.
Es kann natürlich sein, dass es dazwischen noch einen Sanity-Check auf den Windows Bootloader gibt, aber so gut kenne ich den Sourcecode auch nicht.
Hast du da entsprechendes?

Ich nehme an, es wird angenommen, es handelt sich um eine Vollverschlüsselung. Ist der passende Schlüssel nicht bekannt, wird keine bootbare Partition gebildet und die meisten BIOSe/Bootloader quittieren das mit der Meldung das nix gebootet werden kann. Tausche mal deine Win-Partition mit einer Datenpartition, da siehste was passiert. Ein Sanity-Chek im klassischen Sinn ist das nicht, der würde die Konsistenz der Win-Partition checken, das findet nicht statt.
Würde es so sein wie du sagst, würde das System klassisch abstürzen und die Wahrscheinlichkeit das dabei Daten in den Datenhimmel schweben ist gering, denn es wird nix geschrieben oder gelöscht bei einem Absturz. Das System tut nur nix mehr (sinvolles).

http://www.truecrypt.org/docs/volume-fo ... cification

Jetzt habe ich mir das noch einmal angeschaut und sah, dass ich das falsch in Erinnerung hatte.
Der Hash des Passworts wird doch nicht gespeichert. So geht TrueCrypt vor und macht Sanity-Checks auf den Header und Masterkeys:

- Er nimmt das eingetippte Passwort und leitet mit PBKDF2 einen "Header-Key" ab.
- Mit dem Header-Key wird nun einfach erst mal die Bytes von 64-512 entschlüsselt (siehe link oben)
- Um zu gucken ob der Header stimmt, wird zuerst geguckt ob ganz oben "TRUE" steht
- Dann wird geguckt ob die (vorher ja auch verschlüsselte) CRC32-Prüfsumme an Offset 252 auf den Header passt
- Und dann erst wird mit einer Prüfsumme der Masterkey für das Volume gechecked


Alternativ könnte man natürlich, wie ich ursprünglich dachte, den Hash des Passworts selbst als eine Art Prüfsumme nehmen (also mit >1000 Iterationen wie beim PBKDF2).
Der Nachteil wäre aber dann, dass man dadurch nicht die Gesundheit des Headers mitchecken würde.

Den Vorgang kann man sich hier noch einmal genauer anschauen:
https://code.google.com/p/truecrack/sou ... svn62&r=62

in der Funktion cpu_Xts().

(Theoretisch könnte man auch etwas schneller cracken, wenn man bloß nach der Signatur 'TRUE' prüft und davon ausgeht, dass eine Kollision darauf unwahrscheinlich ist. Müsste man mal ausrechnen.)

Wie dem auch sei:

Angenommen man würde aber keine Sanity-Checks machen, weder auf den Header, auf den Bootloader und noch auf das Passwort selbst.

Was würde dann passieren? (Das war ja die ursprüngliche Frage)

Baumkrone hat geschrieben: wird keine bootbare Partition gebildet und die meisten BIOSe/Bootloader quittieren das mit der Meldung das nix gebootet werden kann.

Nein. Der Bootloader von Windows selbst ist doch mitverschlüsselt. Wenn der falsch entschlüsselt wird und nur Müll ist, dann kann der auch nicht mit irgendeiner einer Meldung quittieren, sondern stürzt ab, wie du später sagst:

Baumkrone hat geschrieben: Würde es so sein wie du sagst, würde das System klassisch abstürzen und die Wahrscheinlichkeit das dabei Daten in den Datenhimmel schweben ist gering

Es kommt doch darauf an, was für Instruktionen ausgeführt werden.
Wenn im falsch entschlüsselten Bootloader, dann beispielsweise zufällig so etwas steht:

http://stackoverflow.com/a/9057776

Dann wird unfreiwillig auf die Platte geschrieben. Dass Datenmüll versucht wird auszuführen, ist zumindest ein Risiko.
Man kommt also um solche Checks nicht drumherum.

Bin kein Verfechter der Vollverschlüsselung wie hier propagiert.

Das darf ja jeder machen, wie er möchte.

Ich fühle mich damit sicherer vor einem Outing. Würde ich nichts verschlüsseln, wäre das so als würde ich mein Tagebuch mit meinem pädophilen Lebensalltag schriftlich führen und irgendwo im Zimmer liegen lassen.

@Ovid: Nein, nicht unbedingt das Tagebuch irgendwo im Zimmer liegen lassen, sondern vielleicht in einer abschließbaren Kassette, die ansonsten aber einfach im Schrank liegt (analog eines verschlüsselten Containers auf der ansonsten unverschlüsselten Festplatte). Dass manch einer dann lieber gleich das Zimmer verschließt, damit keiner solch eine Kassette finden kann, ist durchaus nachvollziehbar.

Man könnte auch auf die Idee kommen, das ganze Zimmer abzuschließen (z.B. mit dem hauseigenen Schließsystem wie es bei Mac und Ubuntu mitgeliefert wird) und die Dinge, die einem lieb und teuer sind, in einer zusätzlich abgeschlossenen Kassette (die mit einem anderen Schließ-System, wie z.B. Truecrypt, funktioniert) in den Schrank zu legen.

Um nochmal auf das TrueCrypt-Format zu sprechen zu kommen:
Ich habe das immer so verstanden, dass ein Truecrypt-Container oder -Partition mit einem 256-Bit-Schlüssel (AES, Twofish oder Serpent) verschlüsselt ist, den das Verschlüsselungsverfahren am Anfang selbst einmal per Zufall generiert. Dieser Schlüssel ist im Truecrypt-Header gespeichert, welcher wiederum nur mit dem eigenen Passwort zu öffnen ist, welches mit einer der Hashmethoden "verschnurzelt" ist. (Dies ist leider der Teil, den ich selbst nicht gut erklären kann, obwohl ich weiss was eine Hashfunktion ist.)
Die beiden Vorteile, die daraus entstehen sind die, dass man sich den 256-Bit-Schlüssel nicht merken muss. Und dass man später noch das Passwort wechseln kann. Denn hierzu muss nur der Header neu erstellt werden (in den das neue PW eingeht). Der Inhalt des Headers, nämlich der 256-Bit-Schlüssel, muss aber erhalten bleiben, da dieser unabänderlich ist (ausser man kopiert seine Daten in einen neuen Container oder Partition).

Die Analogien mit dem Abschließen des Tagebuchs passen nicht so ganz.
Weil da kann man ja immer noch mit brachialer Gewalt hinkommen.

Eine bessere Analogie ist: Man hat das Tagebuch in einer Geheimsprache geschrieben, die man nur selbst kennt.

Lolimat hat geschrieben: Um nochmal auf das TrueCrypt-Format zu sprechen zu kommen:
Ich habe das immer so verstanden, dass ein Truecrypt-Container oder -Partition mit einem 256-Bit-Schlüssel (AES, Twofish oder Serpent) verschlüsselt ist, den das Verschlüsselungsverfahren am Anfang selbst einmal per Zufall generiert.

Ja.

Lolimat hat geschrieben: Dieser Schlüssel ist im Truecrypt-Header gespeichert, welcher wiederum nur mit dem eigenen Passwort zu öffnen ist, welches mit einer der Hashmethoden "verschnurzelt" ist. (Dies ist leider der Teil, den ich selbst nicht gut erklären kann, obwohl ich weiss was eine Hashfunktion ist.)

Der Volume-Schlüssel liegt verschlüsselt im Header, genau.
Aus dem Passwort (zusammen mit einem langen Salt) wird ein kleiner Schlüssel erzeugt und zwar mit PBKDF2. Der Wiki-Artikel erklärt es eig. ganz gut, wenn man jetzt nicht auf mathematische Funktionsweise wert legt. Oder hast du dir auch AES/Twofish/Serpent in der mathematischen Funktionsweise genau angeschaut?

Lolimat hat geschrieben: Die beiden Vorteile, die daraus entstehen sind die, dass man sich den 256-Bit-Schlüssel nicht merken muss. Und dass man später noch das Passwort wechseln kann. Denn hierzu muss nur der Header neu erstellt werden (in den das neue PW eingeht). Der Inhalt des Headers, nämlich der 256-Bit-Schlüssel, muss aber erhalten bleiben, da dieser unabänderlich ist (ausser man kopiert seine Daten in einen neuen Container oder Partition).

Jo.

So lange sich aktuelle Win 8 - Systempartitions nicht via Truecrypt schützen lassen, sind wir wieder genauso gefährdet wie damals, zur vor-TC-Zeiten.



Liebe Grüße
asGL

Ovid hat geschrieben:Oder hast du dir auch AES/Twofish/Serpent in der mathematischen Funktionsweise genau angeschaut?

*Räusper* Nein, das dürfte auch leider hinter meinem Horizont liegen. Aber ich arbeite mich stets in kleinen Schritten voran. Werde mal im Wiki-Artikel lesen.