Hi
Gina,
deine Frage ist berechtigt. Nach nochmaligem durchlesen der Doku scheinen sich Teile davon zu widersprechen, und auch ich bin verwirrt. Es ist eben keine Software von mir persönlich und vielleicht solltest du die Entwickler mal direkt hinterfragen.
Aus dem obigen Abschnitt kann man einige Antworten ziehen. Zb. redete ich immer von einem Zufalls-Salt. Nur wie erzeugt man denn einen kryptographisch sicheren Zufall ? Auch dazu werden Hashfunktionen verwendet. Man benötigt einen nicht reproduzierbaren Input, zb. die individuellen Eingaben eines Menschens über die Tastatur oder die Maus. Die damit erzeugten Datenströme sind aber in ihrer Entropie nicht besonders geeignet. Deshalb benutzt man eine Hashfunktion um, wie zb. bei Bruce Schneier's Yarrow Verfahren, aus diesen Eingangsdaten kryptographisch sichere Ausgangsdaten zu erzeugen. Dazu muß man wissen was die besonderen mathematischen Eigenschaften der Hashfunktionen sind. Diese Funktionen versuchen einen digitalen Fingerabdruck aus beliebig großen Eingangsdaten zu erzeugen. Dabei ist es aber wichtig das wenn sich nur 1 Bit verändert hat in den Eingangsdaten das das dann einen komplett anderen Fingerabdruck erzeugen muß. Man nennt sowas auch Lawineneffekt, denn nur 1 Bit reicht aus um den kompletten Ausgangswert zu verändern. Mathematisch kommt man damit in Regionen die den Komprimierungsverfahren sehr sehr ähnlich sind. D.h. Hashfunktionen sind auch Komprimierungsfunktionen, sie komprimieren Daten mit wenig Entropie pro Informationseinheit in einen Ausgangswert der eine sehr hohe Entropie=Informationsdichte in Bezug auf die Eingangsdaten aufweist. Somit sind Hashfunktionen ebenfalls auch sehr gute Pseudo-Zufalls-Generatoren, und als zusätzlichen Nutzen sind sie nicht "vorhersagbar" = unpredictable. Die Vorhersagbarkeit bezieht sich dabei aber nur auf die Ausgangsdaten, sprich man versucht die Frage zu beantworten in wie weit es möglich ist auf Grund eines gegebenen Hash-Ausgangs-Bit-Stromes den nächst wahrscheinlichsten Bitzustand zu errechnen. Und genau das ist unmöglich mit heutiger Technologie und die mathematische Basis für die technische Unmöglichkeit aus einem Fingerabdruck auf die Eingangsdaten zurückrechnen zu können.
TrueCrypt benutzt also die Hashfunktionen um die nötigen Zufallsdaten für die Salts und verschiedene Schlüssel zu erzeugen.
Aber gleich nach diesem Absatz im obigen Auszug behaupten sie das TrueCrypt eben keine Schlüssel per Hashfunktionen benutzen/erzeugen würde. Das widerspricht sich natürlich.
Am besten du fragst direkt bei den Entwicklern nach, die werden konkreter antworten können.
Der Verweis auf PKCS#5 und KDF's in ihren Erläuterungen lässt mich aber mit 99% Sicherheit vermuten das sie sehr wohl mit Hashfunktionen ein gegebenen HumanKey in einen sicheren SessionKey für die Verschlüsselung umwandeln und benutzen.
About IV:
Ja das ist ein InitVector. Das ist ein Datenbereich der während der Verschlüsselung mit zb. AES im sogenannten Feedback Register des "äußeren" Algorithmus landet, als Initialisierung. Der IV sollte zufällig gewählt werden. Es gibt grob gesagt 2 wichtige Gruppen von symmetrischen Verschlüsselungsalgorithmen, die Strom-Verschlüsselungen und die Block-Verschlüsselungen. AES und DES sind Blockverschlüsselungen. Jede Blockverschlüsselung besteht aus mindestens 2 verschiedenen Algorithmen. Der innere Kern von Algorithmus ist das eigentliche Verschlüsselungsverfahren, eben AES,DES,Blowfisch etc. pp. Diese Algos. arbeiten immer nur auf einen festen Block von Daten, zb. 8,16 oder 32 Bytes. Würde man nur mit diesem "inneren Kern" alleine verschlüsseln so würde eine 256 Bytes große Nachricht also in kleine 8 Bytes große Blöcke zerlegt und jeder dieser Blöcke würde unabhängig von den anderen Blöcken verschlüsselt. Sowas ermöglicht ganz spezielle Angriffe, zb. könnte man so verschlüsselte Banküberweisungen eines Kunden abfangen, und dann Blockweise auseinanderschneiden das man daraus eine komplett neue Banküberweiseung an sich selber mit einem hohen Betrag erzeugen kann. Dazu muß man nur wissen welche Daten blockweise in den verschlüsselten Daten vorkommen. Ich animiere dich dann eine Übrweisung auf mein Konto über 15 Euro zu tätigen und fange aber alle deine Daten ab. Ich weis auch das du eine Überweisung der Miete von 1000 Euro getätigt hast und könnte nun den Block mit der Summe aus meinen Überweisungsdaten mit dem der 1000 Euro Überweisung austauschen. Das alles wäre möglich wenn man aussließlich nur den "inneren Kern", sprich das reine AES Verfahren benutzen würde. Deshalb gibt es einen "äußeren Rahmen" Algorithmus, den sogenannten Cipher-Modus. Dieser verknüpft über Feedback Register die Daten des vorherigen Blockes mit den Daten des nachfolgenden Blockes usw. usw. Somit gibt es einen virtuellen Nullten Datenblock VOR der eigentlichen Nachricht. Und das ist der Initvector der mit Zufallsdaten gefüttert wird. Klar, dieser Block wird mit dem 1. Nachrichtenblock XOR verknüpft und anschließend verschlüsselt. Dabei landet er als neuer Feedback Wert im Feeback Register für die Vorbehandlung des 2. Nachrichtenblocks usw.usw. So, nun kann ich nicht mehr deine Bankdaten zu meinem Gunsten manipulieren. Übrigens solche Angriffe sind real geschehen, also keine Fiktion.
Die Art und Weise WIE man nun die einzelnen Blöcke miteinander verbindet ist im Grunde vollkommen unabhängig vom "innern Kern" der Verschlüsslung, man kann also jeden Blockverschlüsselungs-Algo. einsetzen. Es gibt verschiedene solcher Verfahren wie CBC = Cipher Block Chaining, OFB = Output Feedback Modus, CFB = Cipher Feedback Modus, CTS = Cipher Text Stealing, CTR = Counter Modus etc. pp. Benutzt man nur den "innern Kern" so nennt sich das ECB = Electronic Code Book. Im ECB sollte man ausschließlich NUR Zufallsdaten verschlüsseln oder eben andere Ciphermodis drüberstülpen. TrueCrypt benutzt CBC. Interessant ist der Fakt das er seit relativ sehr kurzer Zeit sich die Kryptologen über die beste Sicherheit dieser Ciphermodis Gedanken machen. Die Ciphermodis wurden immer eher stiefmütterlich behandelt. Erst mit dem AES Auswahlverfahren des NIST, das bekanntlich Rijndael = AES gewann, gibt es auch eine Auswahlverfahren für die Ciphermodis.
Der IV ist also wichtig um den 0. Block zu bilden. Damit man wieder entschlüsseln kann muß dieser IV aber lesbar an die Nachricht drangehangen werden. Durch das Befüllen mit Zufallsdaten und der verketteten Benutzung im Ciphermodus wird die Nachricht randomisiert. Alledings tendiere und empfehle ich nicht einen Zufalls-IV ansich zu verwenden sondern vor der Verschlüsselung einer Nachricht diese am Anfang mit Zufallsdaten zu randomisieren. Diese Zufallsdaten + die Nachricht werden dann sequientiell verschlüsselt. Somit ist das wie ein IV aber mit dem Unterschied das dieser "IV" in der eigentlichen Nachricht mitverschlüsselt wurde. Ein normaler IV wäre direkt unverschlüsselt und somit lesbar. Der Effekt dieses Salts ist identisch zum Zufalls-IV, aber die Sicherheit muß größer sein. Nebenbei hat es auch praktische Vorteile, eine Nachricht zu expandieren vor einer Verschlüsselungen ist meistens einfacher als an die Verschlüsselten Daten im Nachhinein den lesbaren IV "dranzuhängen". Wir hätten dann technisch gesehen einen Footer, ein Header wäre aber besser.
Nungut, ich bin schon wieder viel zu tief in die Materie eingedrungen, sorry
Gruß Hagen