TrueCrypt - wie sicher?

[BeeHaa]

Und das Posting von hostile kann man nur unterschreiben

Ja klar kann man das. "Liebe Leute, ihr dürft [...] nicht vergessen."
Nur ich wüßte jetzt gerne wie er darauf kommt. Weil vergeßen habe ich das zB. nicht. Hat das sonst jemand hier vergeßen? Da wir von TrueCrypt reden ist die Sache sowieso vom Tisch. Exploits für TC selbst, wenn schwerwiegendere Fehler gefixt/aufgeführt wurden, habe ich noch keine gesehen (außer dem frozen-ram Trick, aber das hat mit der Software nichts zu tun)

@HaveFun
Booten, was ja eigentlich auf 90% der Rechner daheim die festpalttenintensivste Phase ist, dauert hier auf einem Lappi mit P-M 1.6Ghz fast genau diese 15% langsamer. Mit TC 6.1a. Das sind dann statt 35s davor nun 40s (XP). Browsen mit Faststone in einem Fotoordner im vergleich zu früher kann man dagegen fast nicht mehr auseinanderhalten. XTS und die neuen AES/Twofish laufen wirklich ausgezeichnet.

 

[hostile]

@BeeHaa
Hab so das Gefühl bekommen durch das Lesen der Posts... sollte ja auch nur ein Hinweis sein. In einem Internet-Forum weiss man nie, wie tief sich wer mit welcher Materie beschäftigt hat oder sich auskennt.

gruß
hostile

 

[para66]

Sind sich nicht. Aus bald einem Jahr Erfahrung mit meinem Rechner hier: der Performanceverlust ist zu vernachlässigen.

Ist auch meine Erfahrung. Ich kann nicht die geringste Verschlechterung erkennen, weder beim Spielen noch sonstwo.

Ich verwende die Systemverschlüsselung unter Vista 64 und einem Intel E6750 Doppelkern.

 

[^Jefferson^]

Ich hab hier auch noch ein paar Fragen bezüglich der Sicherheit von Truecrypt:

1. Gibt es neben Bruteforce, Dictionary attack und anderen Methoden, bei den Passwörter ausprobiert werden, solange bis ein funktionierendes Passwort gefunden ist noch andere Möglichkeiten einen mit Truecrypt verschlüsselten Bereich zu knacken? (abgesehen von Möglichkeiten wie Folter, Hypnose, Erpressung o.ä.)

2. Die bei Truecrypt angewendeten Verschlüsselungsalgorithmen AES, Twofish, Serpent wurden doch bisher noch nicht geknackt, oder doch? (ich kenne mich da nicht so gut aus)

3. Welche Gründe hat man mit Twofish oder Serpent zu verschlüsseln, wenn AES doch als sicher gilt und zudem noch der schnellste der drei Algorithmen ist? Oder ist AES doch nicht so sicher, wie immer vermutet wird, oder sind die anderen 2 sicherer?

 

[Darkwonder]

Wenn du ein Sicheres Passwort hast ist es sicher.
Viele Infos dazu giebt es im gulli-bord
z.B.
http://board.gulli.com/thread/674868-anleitung-tutorial-und-howto-truecrypt-verschlsselung/

 

[Trialer]

Was hat es mit der hier erwähnten Implementierung auf sich? Was muss man da beachten?

 

[^Jefferson^]

Wenn du ein Sicheres Passwort hast ist es sicher.
Viele Infos dazu giebt es im gulli-bord
z.B.
http://board.gulli.com/thread/674868-anleitung-tutorial-und-howto-truecrypt-verschlsselung/

Ja das hab ich auch schon gelesen...
Aber man ließt halt überall nur Vermutungen...

Ich habe noch keine infos bekommen, von jemandem, der sich wirklich richtig damit auskennt, oder von größeren Versuchen diese Verschlüsselungen zu knacken, die dann scheiterten, o.ä.

 

[Darkwonder]

Der Verschlüsselung zu knacken ist nach dem was ich jetzt weiß noch keinem Gelungen bzw. es hat noch keiner Kund getan.
Bei einem 15 Stelligen Passwort würde es auch schwer werden.

 

[^Jefferson^]

Der Verschlüsselung zu knacken ist nach dem was ich jetzt weiß noch keinem Gelungen bzw. es hat noch keiner Kund getan.
Bei einem 15 Stelligen Passwort würde es auch schwer werden.

Ich frage mich da nur warum manche Leute z.B. mit AES-Twofish-Serpent Verschlüsseln, wenn AES doch angeblich allein schon sicher genug ist das es Jahre dauern würde es zu knacken, bei einem guten Passwort. Denn AES alleine ist doch wesentlich schneller...

Oder empfielt es sich sogar einen anderen Algorithmus zu nehmen als den schnellen AES?

 

[BeeHaa]

@^Jefferson^
1. Nein, gibt es nicht. Und wenn das jemand in der Offentlichkeit wissen würde, würde es auch die TrueCrypt Foundation mitbekommen und solche Bugs schnellstmöglich beheben. Wenn irgendein Geheimdienst einen Bug gefunden hat, dann werden sie das niemandem mitteilen.

2. Sehe oben. Du nimmst doch nicht an, daß im TrueCrypt Algorithmen verwendet werden von welchen man weiß, daß sie knackbar sind? o_O

3. Subjektive persönliche Präferenzen. Davon ab war das mit der Schnelligkeit von AES nicht immer so. Früher war Twofish auf einigen CPUs schneller als AES. Da mit den neueren Versionen der Kode von AES zwar um einiges, der Kode von Twofish aber auch geringfügig beschleunigt wurde, spielt das was der eingebaute Benchmark anzeigt im realen Betrieb keine Geige (zwischen AES und Twofish).

Auf meinem E8400 ist Twofish mit der aktuellen Version ~6% langsamer als AES. Bei dem eingebauten Benchmark (läuft im RAM). Im realen Betrieb auf der Platte merkt man nichts davon. Es sei denn man verschlüsselt ein schnelleres RAID-0. Dann kann man das wenigstens mit HDBench messen. Merkbar tut sich da auch nicht viel.

Die Sicherheit der Verschlüsselung hängt größtenteils vom Passwort/Passphrase ab. Um die Algorithmen welche die TrueCrypt Foundation wählt muß man sich keine Sorgen machen, denn das Programmiererteam besteht aus absoluten Experten.

 

[starbuckzero]

Ich frage mich da nur warum manche Leute z.B. mit AES-Twofish-Serpent Verschlüsseln, wenn AES doch angeblich allein schon sicher genug ist das es Jahre dauern würde es zu knacken, bei einem guten Passwort. Denn AES alleine ist doch wesentlich schneller...

Natürlich ist AES alleine wesentlich schneller, allerdings hat man bei einer Kaskade aus mehreren Algorithmen immer noch den Vorteil, dass falls einer davon geknackt wird, noch 2 zusätzliche vorhanden sind, die umgangen werden wollen. Natürlich eher eine akademische Frage, in der Realität hat es eigentlich wenig Sinn, solang die CPU schnell genug ist tut es aber auch nicht weh.

AES ist in Truecrypt erst schneller als Twofish, seit die Implementierung in Assembler-Code und nicht mehr in C drin ist, seit dem Aufbohren der Multi-Core Unterstützung ist das allerdings sowieso relativ egal, weil im Zweifelsfall bei beiden vorher die Festplatte limitiert und nicht die CPU.

 

[olampl]

Ich bin Softwareentwickler ein Kunde versendet Daten(Unterschriften) via GPRS von Mobilegeraeten,

diese werden zuerst mut AES 256 verschluesselt, anschliesend nochmal mit MD5.

Wie starbuckzero richtig bemerkte ist es ueblich kaskadiert zu verschluesseln. Sicher ist sicher.

 

[BeeHaa]

@kreadon
"Kaskade" aus AES und MD5. Du bist mir echt ein Softwarentwickler

MD5 ist nur die Prüfsumme. Verschlüsseln kann man damit nichts.

 

[olampl]

MD5 ist nur die Prüfsumme. Verschlüsseln kann man damit nichts.

*hust*

Habe mich unklar ausgedrueckt, war mein fehler. sry

http://msdn.microsoft.com/de-de/library/bb979093.aspx

Hash-Algorithmen selbst benötigen keinen Schlüssel. Man kann aber die Implementierung so erweitern, dass der Hash auf einem Schlüssel basiert. Dies erfolgt über die .NET Framework-Klassen System.Security.Cryptography.MD5 und System.Security.Cryptography.SHA1.

 

[Nevermore4ever]

Ich würde von der Verchlüsselung der Systemplatte abraten. Sinnvoll ist Verschlüsselung bspw. für Dokumente, die geheime Informationen enthalten.

Dem möchte ich widersprechen.

Insbesondere in der Auslagerungsdatei können sensible Informationen gespeichert sein, weswegen deren Deaktivierung bei der Installation von TrueCrypt ja auch empfohlen wird. Aktiviert lassen sollte man die nur, wenn sie selbst im verschlüsselten Bereich liegt - deaktivieren sollte man sie nur, wenn man quasi endlos viel RAM besitzt.

Da man auch sonst leicht den Überblick verliert, welches Programm jetzt was vielleicht noch irgendwo speichert (in der Registry, versteckten Dateien,...), evtl. ohne dass einem das bekannt ist, empfehle ich ausdrücklich die Komplettverschlüsselung. Diese bietet auch den Vorteil, dass das Passwort vor dem Windowsstart eingegeben werden muss, also bevor etwaige Keylogger-Schadsoftware zuschlagen kann, falls man sich welche einfängt, NACHDEM man verschlüsselt hat.

Einziger Nachteil: Bevor man ein Betriebssystem neu installiert, muss man die Systempartition entschlüsseln, da sonst der Bootloader überschrieben würde - es gibt also in diesem Fall ein Intervall der Unsicherheit.

 

[IceMatrix]

Dies erfolgt über die .NET Framework-Klassen System.Security.Cryptography.MD5 und System.Security.Cryptography.SHA1.

TrueCrypt verwendet im übrigen kein .NET

 

[Keineahnung1234]

Ein Passwort gilt dann als sicher, wenn das knacken so ca 20Jahre oder länger dauern würde. Kein Passwort ist unknackbar, es kommt nur darauf an, ob es sich lohnt, 50 oder 100Jahre zu warten bis es geknackt is , oder man vielleicht einen fehler irgendwo findet und man einfach so an die daten kommt.
Für einen Normalen User wird es mehr als ausreichen. Wer sollte das denn knacken wollen/können? Ein Normaler Durchschnitts Rechner der ca. 35.000.000Keys/Sek Testen kann, braucht bei Bruteforce und einem 8 Stelligem Password mit allen Zahlen, klein, gross und sonderzeichen 12Jahre, bei 9 schon 1289Jahre.

 

[BeeHaa]

Ja ja, sicher. Durchschnittsrechner...

Benutzt bitte keine Passwörter unter 11 Zeichen. Mehr gibts nicht zu schlabbern.
Und "salzt" das Wort oder die Wörter mit wenigstens 2 Zahlen und 2 Sonderzeichen.

Das ist alles was zu beachten wäre. Für Sachen die man sich merken muß.

Für den Rest benutzt KeePass (aktuell 1.14) portable. Auch wenns auf der Platte liegt. Und seinen Generator. Da könnt ihr euch austoben wie es euch beliebt. Zwischen 25 und 35 Zeichen schlucken heutzutage auf jeden Fall alle Programme. Also nur zu

 

[mensch183]

Hash-Algorithmen selbst benötigen keinen Schlüssel. Man kann aber die Implementierung so erweitern, dass der Hash auf einem Schlüssel basiert. Dies erfolgt über die .NET Framework-Klassen System.Security.Cryptography.MD5 und System.Security.Cryptography.SHA1.

Da entsteht trotzdem nichts, was man "Verschlüsselungskaskade aus AES und MD5" bezeichnen könnte.

Die von dir angesprochene Erweiterung einer Hashfunktion mit einem Schlüssel macht aus dem Hash einen MAC (Message Authentication Code). Der Prüfsumme ist nicht mehr öffentlich prüfbar (also nicht mehr einfach neu berechenbar und vergleichbar) wie man es sonst von Hasfunktionen kennt, sondern nur mit dem (symmetrischen) Schlüssel. Der Schlüssel sorgt dafür, daß nur der Schlüsselbesitzer die Prüfsumme erstellt haben kann. Der Ersteller ist damit identifizierbar, was beim Hash nicht der Fall ist. Ein Hash stellt nur die Integrität der Nachricht sicher, ein MAC stellt Integrität und Authentizität der Nachricht sicher. Verschlüsselt im Sinne von "versteckt für Dritte ohne Schlüssel" wird die Nachricht durch den MAC nicht!

Da diese Art MAC auf einer Erweiterung einer Hashfunktion basiert, nennt man die Methode HMAC (Hash Message Authentication Code). Unter dem Stickwort HMAC findest du mehr Infos dazu.

 

[^Jefferson^]

Natürlich ist AES alleine wesentlich schneller, allerdings hat man bei einer Kaskade aus mehreren Algorithmen immer noch den Vorteil, dass falls einer davon geknackt wird, noch 2 zusätzliche vorhanden sind, die umgangen werden wollen. Natürlich eher eine akademische Frage, in der Realität hat es eigentlich wenig Sinn, solang die CPU schnell genug ist tut es aber auch nicht weh.

Wie starbuckzero richtig bemerkte ist es ueblich kaskadiert zu verschluesseln. Sicher ist sicher.

Also wenn jemand wirklich sensible Daten auf seinem PC speichern möchte, dann sollte er nicht nur mit AES verschlüsseln? Sondern z.B. AES-Sepernt... und das ist dann wirklich fast absolut sicher (bei sicherem Passwort)?