SSD Disk Encryption (Truecrypt vs Bitlocker vs DiskCryptor)

[Whistl0r]

Letzteres bezweifle ich doch stark. Der TC Quellcode ist sehr aufgeräumt, OO und von hoher Qualität. Ich sehe da wirklich kein Problem (bedenke, dass DC ein Fork von TC und auch keine Neuentwicklung ist). Warten wir es einfach ab. Leider sind Wartephasen von 1-2j bei TC nicht unüblich (dafür erscheint dann gleich eine stabile Version)...

 

[stw500]

Schon das Programmfenster wirkt sehr einfach. Du siehst dann eine Liste aller verfügbaren Partitionen. Bei mir gab es nur ein Laufwerk (das SSD) mit zwei Partitionen (die 100MB Boot-Partition und den Rest). Du musst dann eben eine Partition anklicken und kannst dann rechts "Encrypt" klicken. Es öffnet sich ein einfaches Fenster was nach einem Kennwort fragt und dann geht es schon los. Dann ist die erste Partition verschlüsselt.

Dass das Programm eine einfache GUI hat, finde ich vorteilhaft und sehr viel intuitiver als bei TC.

Hoffentlich hast du zuvor im Menü den Bootloader manuell installiert. Andernfalls gibt es wartet eine Überraschung beim nächsten Reboot auf dich.

Ich kann mich jetzt nicht mehr genau erinnern, wie ich es damals gemacht habe. Aber auch für damals gilt, es war einfach, es war intuitiv und es machte keine Probleme.

Keine Aufforderung bzgl. Rescue-CD.

Klar ist eine erzwungene Rescue-CD für Leute mit wenig Ahnung hilfreich. Aber mal ehrlich...es gibt Linux-Live-CDs mit eingebautem DC. Wer also mal ein Problem hat, der zieht sich so eine runter (google nach Hirens Boot CD aber vorher testen, ob sie geht) und decrypted dann bequem. Normalerweise macht sich ein gewissenhafter Nutzer solcher Sicherheitssoftware ohnehin darüber Gedanken, wie man im Fall der Fälle wieder an die Daten kommt, und es geht ja.

Du fragst dich, weil du für jede Partition ein anderes Kennwort wählen kannst, wie das denn funktionieren soll, dass bei der PBA das Boot-LW freigeschaltet wird... wie zum Teufel wird dann das eigentliche Daten-LW freigeschaltet, damit Windows wirklich booten kann? Naja, du startest dann doch irgendwann neu und Magie passiert - das System ist doch noch fähig zu booten.

Vielleicht verstehe ich Dich jetzt nicht ganz. Die PBA ist für das Systemlaufwerk, im gebooteten System kannst Du dann die Passwörter für den Rest eingeben. Alles automatisch geht vielleicht auch, weiß ich jetzt nicht genau. Aber was bitte ist Magie daran, dass

a) die Software, wenn man die Systempartition verschlüsselt, automatisch den Bootloader bei der Installation entsprechend konfiguriert und

b) die Software, wenn man - vorausgesetzt ich habe Dich richtig verstanden - System- und Datenpartitionen beim Boot gleichzeitig entschlüsselt haben möchte und dafür eine Einstellung setzt, den Bootloader dann entsprechend hierfür konfiguriert.

Ich finde es nicht "zusammen gehackt", sondern einfach nur gut programmiert.

Nach meinen Tests habe ich es deinstalliert. Dazu habe ich erst jede Partition entschlüsselt: Ausgewählt, Decrypt angeklickt, Kennwort eingeben, gewartet, fertig.

Neu gestartet: Der will noch immer ein Kennwort von mir! Schock, denn das zuvor gewählte Kennwort nimmt er nicht mehr... irgendwann drückt man "Enter" (also leere Eingabe) und er startet doch wieder (Glück gehabt!). In der software stellt man fest, dass man den Bootloader ja auch wieder manuell entfernen muss ;-)

Im Vergleich dazu TC/BL: Da passt einfach alles. Du hast erst einmal einen Haufen an Dokumentationen. Du weist wie es ablaufen wird. Jeder Schritt ist offiziell beschrieben. Die Software selber arbeitet sicher: Es gibt im Vorfeld Tests, inkl. Reboots - nur wenn das klappt, lässt die Lösung dich verschlüsseln.

Also an den Punkt des Entschlüsselns bin ich noch nicht gekommen. Aber, wer verschlüsselt oder entschlüsselt ohne zuvor ein Backup gemacht zu haben, ist selber schuld. Selbst wenn also mal was schieflaufen sollte, kann es sich nur um eine Stunde zurückspielen handeln, aber keinen Datenverlust.

Warum sollte DC auch noch das alte Kennwort nach dem Entschlüsseln wollen? Es gibt ja kein Kennwort mehr...ist eigentlich logisch. Und was ist jetzt so schlimm daran, dass man nach dem anschließenden so schwierigen Enter-Drücken unter Windows den Bootloader durch einen einfachen Klick noch deinstallieren muss? Verstehe ich nicht, wenn es doch dann funktioniert.

Bei TC hatte ich eher schon das Problem, dass der Bootloader nicht wegging, obgleich man alles entschlüsselt hatte, also problemfrei ist die all-in-one-automatik von TC nun wirklich auch nicht.

Falls DC jetzt wirklich keinen Passwort-Test vorab unterstützt (ich glaub das geht wirklich nicht), wäre das wirklich etwas, was noch implementiert werden sollte. Aber keine Software ist perfekt. Dafür läuft sie stabil und sehr schnell, das macht den Rest wieder wett, finde ich.

Ich behaupte ja nicht, dass DC nicht funktioniert. Man sieht halt wirklich nur, wie es entstanden ist.. zusammen gehackt

Also das kann ich auch nach Deinen Erklärungen (und meinen Anmerkungen dazu) wirklich nicht nachvollziehen.

 

[Whistl0r]

Dass das Programm eine einfache GUI hat, finde ich vorteilhaft und sehr viel intuitiver als bei TC.

Du redest ja förmlich so, als sei die TC GUI völlig überladen, undurchsichtig und kompliziert! Und zwischen einfach/intuitiv zu "billig" (was ich meine), liegt ein Unterschied.

Ich kritisiere ja nicht die Einfachheit. Nur wenn du dir die Entstehung von DC anschaust.. man nehme den TC-Treiber... jetzt braucht man dafür eine GUI... die GUI muss die Möglichkeit bieten bestimmte Werte an den Treiber zu übergeben, also brauchen wir noch einen Dialog... darauf paar Input-Elemente, Buttons... ganz simpel alles. So etwas kann man mal eben, weil man es gerade braucht, zusammen klicken (-> Ziel erreicht; Weiter geht's), oder man ordnet es schön ansehnlich und einheitlich an (-> Ziel erreicht; wirkt nicht so billig - hat evtl. etwas mehr Zeit in Anspruch genommen). Dann kann es immer noch intuitiv sein, wirkt aber nicht "billig".

Klar ist eine erzwungene Rescue-CD für Leute mit wenig Ahnung hilfreich. Aber mal ehrlich...es gibt Linux-Live-CDs mit eingebautem DC. Wer also mal ein Problem hat, der zieht sich so eine runter (google nach Hirens Boot CD aber vorher testen, ob sie geht) und decrypted dann bequem. Normalerweise macht sich ein gewissenhafter Nutzer solcher Sicherheitssoftware ohnehin darüber Gedanken, wie man im Fall der Fälle wieder an die Daten kommt, und es geht ja.

Dir scheint nicht klar zu sein, was die Rescue-CD von TC ausmacht. Dort befindet sich der Header des Volumens drauf. Der ist bei jedem Volumen individuell - den kann man nicht nachträglich aus dem Internet laden

Wenn es wirklich mal darum geht ein beschädigtes Volumen zu retten, dann entscheidet das Vorhandensein einer Headersicherung ob die Rettung erfolgreich verlaufen wird oder zum scheitern verurteilt ist.

Vielleicht verstehe ich Dich jetzt nicht ganz. Die PBA ist für das Systemlaufwerk, im gebooteten System kannst Du dann die Passwörter für den Rest eingeben. Alles automatisch geht vielleicht auch, weiß ich jetzt nicht genau. Aber was bitte ist Magie daran, dass

a) die Software, wenn man die Systempartition verschlüsselt, automatisch den Bootloader bei der Installation entsprechend konfiguriert und

Das passiert eben nicht automatisch! Den muss man manuell installieren.

Und mit Magie meine ich, dass du im Vorfeld einfach nicht weißt, ob das funktioniert. Du kannst mit DC dein System in einen inkonsistenten Zustand versetzen - mit TC und BL ist das nicht möglich. Die Programme prüfen bspw. auf logische Fehler und verhindern sie... DC prüft nicht und auf Grund fehlender Dokumentation weißt du gar nicht, was ein logischer Fehler sein kann. Typisch für etwas was ich "zusammen gehackt" nenne

b) die Software, wenn man - vorausgesetzt ich habe Dich richtig verstanden - System- und Datenpartitionen beim Boot gleichzeitig entschlüsselt haben möchte und dafür eine Einstellung setzt, den Bootloader dann entsprechend hierfür konfiguriert.

Nichts - aber da es keine Dokumentation gibt, stehst du als Neuling erst einmal da und weist von nichts. Wirst überrascht. Magic just happens

Also an den Punkt des Entschlüsselns bin ich noch nicht gekommen. Aber, wer verschlüsselt oder entschlüsselt ohne zuvor ein Backup gemacht zu haben, ist selber schuld. Selbst wenn also mal was schieflaufen sollte, kann es sich nur um eine Stunde zurückspielen handeln, aber keinen Datenverlust.

Tja, der eine überträgt die Verantwortung der Software auf den Nutzer ("Sichere... ich weiß nicht ob ich alles richtig machen werde"), der andere erwartet eben, dass das was etwas tut weiß was es macht und mit Netz arbeitet.

Warum sollte DC auch noch das alte Kennwort nach dem Entschlüsseln wollen? Es gibt ja kein Kennwort mehr...ist eigentlich logisch. Und was ist jetzt so schlimm daran, dass man nach dem anschließenden so schwierigen Enter-Drücken unter Windows den Bootloader durch einen einfachen Klick noch deinstallieren muss? Verstehe ich nicht, wenn es doch dann funktioniert.

Blah. Im Nachhinein ist alles logisch erklärbar. Im ersten Moment würdest auch du doof dreinschauen. Wenn das dokumentiert wäre oder die Software automatisch erkennt, dass der Bootloader nicht mehr benötigt wird und ihn mit der Entschlüsselung der letzten Partition entfernen würde...

Bei TC hatte ich eher schon das Problem, dass der Bootloader nicht wegging, obgleich man alles entschlüsselt hatte, also problemfrei ist die all-in-one-automatik von TC nun wirklich auch nicht.

Solche Argumente liebe ich immer. "Aber ich hatte auch schon Probleme"... Aber darum geht es mir ja gar nicht: Ich kritisiere nur, dass das alles nicht dokumentiert ist. Du weißt nicht was du tun musst und dich erwartet. Gäbe es eine Dokumentation - ich hätte die ganzen Punkte gar nicht erwähnt!


Und du musst DC gegenüber mir auch gar nicht verteidigen. Ich habe lediglich zum Ausdruck gebracht, dass auf mich die Software den Eindruck von "zusammen gehackt" (=prototyping) macht. Das habe ich dann auf Nachfrage noch begründet...

Ich behaupte ja nicht, dass DC selbst nicht funktioniert...

 

[DoubleJ]

Immerhin scheint der Bootloader von DC kleiner (besser optimiert) zu sein, mit aktiviertem RAID-Modus des Q67 verweigert TC im Gegensatz zu DC nämlich den Dienst.

 

[stw500]

Nur als Kurzantwort:

- Die TC Gui ist nicht überladen, aber ich finde sie auch nicht immer intuitiv. DC scheint mir da intuitiver zu sein (für mich!).

- Die tatsächliche Entstehung von TC oder DC wage ich nicht zu beurteilen, da ich keiner der Programmierer bin, aber wenn Du da Einsicht hast...

- die Rescue-CD bietet ein Backup des Headers, stimmt. Kannst Du bei DC aber auch machen lassen, kostet einen Klick. Steht auch in der FAQ, zumindest diese sollte man lesen als halbwegs vernünftiger Anwender, das wiederum erwarte ich.

- Dass eine vorherige Funktionsprüfung wünschenswert wäre, sehen wir ja beide so. Ein "Sicherheitsnetz" kann eine Software dennoch immer nur bedingt leisten. Gerade bei Verschlüsselungssoftware ist ein Backup immer Pflicht, jeder, der etwas anderes behauptet, hat entweder keine wichtigen Daten zu verschlüsseln und die nötige Zeit, alles neu aufzusetzen, oder er ist schlicht naiv.

- Eine funktionierende Software ist nie Magie, das kann ich einfach nicht nachvollziehen.

- Letztlich kommst Du ja selber zum Fazit, dass Du all das nur deswegen kritisierst, weil es angeblich nicht dokumentiert ist. Naja, unabhängig von der tatsächlichen Güte der offiziellen Dokumentation gibt es ein Wiki und ein Forum, in denen weitere Informationen verfügbar sind und auch Fragen gestellt werden können. Klar ist bessere Doku immer netter, aber auch bei TC finde ich nicht alles 100%ig verständlich erklärt oder überhaupt dokumentiert, wenn gleich es übersichtlicher auf deren Homepage zugeht, das stimmt schon. Aber aus all dem den Schluss zu ziehen, die Software sei billig und zusammen gehackt, finde ich dann doch nicht richtig.

Soll jeder einfach das nutzen, was ihm mehr liegt, dann werden alle glücklich!

 

[dezly]

Hey Leute. Ich würde gerne aus Performancegründen von TC zu DC wechseln und hab ein paar fragen, hoffe ihr könnt mir helfen.
Momentan habe ich TC auf meiner SSD systemplatte und auf 3 HDDS, die ich mit Truemounter automatisch mounten lasse, wenn ich mich einlogge (per Keyfile, die auf der SSD liegt).
Da man bei TC ja nur die Systemplatte entschlüsseln kann, ich aber keine anderen HDDS habe müsste ich wissen, ob ich beispielweise mit DC die mit TC verschlüsselten HDDS entschlüsseln kann. Ich weiss nur, dass es mit DC selbst wohl geht aber nur bei von DC verschlüsselten Platten. Oder gibt es andere wege die HDDs zu entschlüsseln, bevor ich DC installiere?

Ist es richtig, dass ich mit DC mit der Pre-Boot Authentication direkt alle Laufwerke mounten kann? Kann ich die HDDs dann auch an andere Systeme hängen und dort einzeln mounten?

 

[stw500]

Dui kannst DC und TC parallel nutzen, d.h. z.B. mit DC die FSE und mit TC die anderen Partitionen und/oder Container ver-/entschlüsseln. Bezüglich des mountens aller Laufwerke nach der PBA einfach mal auf die Wiki-Seite,FAQ und Forum schauen, da ich auch keine Antwort parat.

 

[dezly]

Hm.. ja, die Idee kam mir irgendwie nicht, ist aber sehr gut

Genau so hab ichs jetzt umgesetzt, die Keyfile für Truemounter liegt auf der mit DC encrypteten SystemSSD.
Werte sind top, siehe hier (Mit Handy abphotographiert..fragt nicht ):

Vorher (links die M4, die Agility 3 hing nur an SATA II, darum der geringere Sequential Speed):


Nachher:


TC in Version 7.0a und DC auch in der aktuellen 1.0.732.111 (beta). Sequential eventuell etwas langsam, das liegt jedoch an der SATA III erweiterungskarte, die nur mit PCIe 1x läuft. (Danke Asus!)

 

[cRaZy-biScuiT]

Ist deine DRUCK-Taste kaputt?

Ist ja wirklich kaum Performance-Verlust. Sollte ich eine SSD kaufen wird die dann also auch wieder verschlüsselt. Mit TC ist die Performance nicht so gut?

 

[Poddy]

Nein ist sie nicht, einfach mal ein paar Seiten zurück schauen, dann siehst den Unterschied.

BTW: AS-SSD bietet auch die Möglichkeit ein Bild zu speichern > Datei > Screenshot.

 

[dezly]

"Fragt nicht"! Hab das so gemacht, weil ich ein totales Durcheinander meiner ganzen Platten hatte, da ich grad am basteln war, die SSD nach dem Test ohne Verschlüssellung wieder formatiert habe und die bilder ursprünglich nur für mich zum vergleich wollte.

Truecrypt hab ich sogar auch mal auf der M4 gehabt und auf der Agility 3 sogar 2 Monate.
Zu sagen bleibt, dass bei TC die 4K Random READ Werte bei 10-13 liegen, die WRITE auch nicht wirklich besser sind und die 4k-64Thrd Werte auf so ca ein viertel/fünftel absacken. Alle sagen immer der Sequential Speed wäre bei TC besser. Wenn man das so sagen will, dann liegt der Unterschied aber wirklich nur bei wenigen Prozent.

Da die 64Thrd Werte für den Normalgebrauch wohl nicht aussagekräftig sind, die 4k aber schon und vor allem eher Read als Write bei üblicher benutzung (PrivatPC, Windows, Programme und Games auf SSD), da ja viele kleine Daten gelesen werden, ist Diskcryptor eindeutig die bessere Wahl für die SSD. Da ich TC eigentlich mag hoffe ich, dass da noch eine entsprechend schnelle Version nachkommt.
Im Alltagsgebrauch beim Windows Start oder öffnen von sowas wie Word merkt man nicht wirklich einen unterschied zwischen TC und DC. Er ist zwar da, auch feststellbar aber sooo minimal, dass es eigentlich egal ist. Bei Games ists mir schon eher aufgefallen aber es ist jetzt nicht so als wäre DC doppelt so schnell, nur weil die 4k Werte 2mal höher liegen. Zum einen hängen Ladezeiten nicht zu 100% von der Festplatte ab und zum anderen sind vermutlich 4k-Daten auch schon wieder extrem klein, was in der Praxis nicht so extrem vorkommt (Glaub ich )

 

[cRaZy-biScuiT]

Hmmm alles in allem: Wenn ich eine Festplatte mir TC verschlüsselt habe und dann eine SSD damit verschlüssele sollte schon ein deutlicher Performance-Gewinn da sein. Da limitiert dann vermutlich eher mein Q6600 als die SSD & TC

 

[Whistl0r]

Nein, der Prozessor limitiert da noch lange nicht.

 

[Poddy]

Naja, sagen wir mal ein Bisschen. Sequentiell macht der Q6600@stock so bei 400-450MB dicht und ein Prozi übertaktet auf 5GHz würd bei TC vllt auch noch ein paar IOPs raus holen. Aber grundsätzlich ist dann natürlich schon TC der limitierende Faktor.

 

[Whistl0r]

Ich habe hier Fileserver wo Q6600 verbaut sind und 4-6 einzelne Festplatten drinnen stecken. Der Prozessor limitiert wirklich nicht.

Rechne pro Festplatte mit 10-20% CPU Last (auch Abhängig von der IO-Last).

Gleiche Systeme durch Prozessoren mit AES-NI ersetzt sorgen nur dafür, dass die Prozessorlast sinkt, d.h. mehr Ressourcen für anderes frei ist/geringerer Stromverbrauch. Es ist aber wirklich nicht so, als limitiere der Prozessor und als würde mit AES-NI mehr gehen.

 

[Poddy]

Also bei einzeln HDDs nicht, aber trotzdem schafft man mit TC und dem Prozi (mein Q8400 schafft gleich viel) nicht mehr wie 400MB/s. Ich merks ja bei meinem Raid 5 aus 8 Platten. Mit DC und Serpent limiert er bei ca 600MB. Nicht übertaktet gehen bei mir auch die 4K Werte runter bei TC. Ein Phenom X6 macht auch ungefähr 100MB pro Kern, bei den Prozis auf der Zeit kann man grundsätzlich 100MB pro Kern Rechnen bei ca. 3GHz. Ein Intel Core i5-2520M profitiert dann schon auch von AES-NI, je nach Storage Ausstattung.

 

[Whistl0r]

Das liegt aber nicht am Prozessor, sondern an der Verschlüsselung allgemein.

Wie bekannt schreiben Festplatten immer in Blöcken. Dateisysteme der Betriebssysteme liefern Cluster und der Disktreiber, in welchem die Verschlüsselung stattfindet), schiebt die Blöcke hin und her.

Unverschlüsselt kann die Festplatte jetzt in die Blöcke reinsehen und weiß, welche Bits sich verändert haben. Beim Speichern eines geänderten Blocks muss dieser zwar dennoch gelesen werden (kann allerdings aus dem Cache kommen!) und im Endeffekt wird er auch wieder vollständig geschrieben... der Controller kann aber zwischenspeichern und mit dem echten Schreiben warten bis es ihm passt (bspw. der Track gerade beim Kopf vorbei kommt, anstatt den Kopf der gerade woanders ist zu bewegen, auf den Track zu warten...).

Sobald FDE ins Spiel kommt, kann der Controller nicht mehr in den Block schauen bzw. es haben sich einfach immer alle Bits des Blocks geändert. Somit muss er eigentlich immer direkt schreiben, der Cache läuft so sau schnell voll... und beim Lesen bringt der Cache auch nichts, da das der FDE-Treiber immer volle Blöcke anfordert, weil er diese entschlüsseln muss.

Kurz um: Bei FDE hat die Platte immer zu tun, tolle Cachinglösungen der Hersteller haben keine Chance. Das gilt umso stärker für RAIDs, weil hier der Cache zentral im RAID-Controller ist... der Controller selber an die Platten immer ein Force-Write Command schickt...

Heutige Prozessoren wirst du mit FDE nicht wirklich an die Grenzen bekommen... (insofern sind diese AES-NI Benchmarks von TC völlig irreführend, weil sie wohl kaum jemand richtig versteht)

 

[Poddy]

Versteh schon was du meinst, aber das ändert nichts daran, dass die Aussage dass der Prozi limiert richtig ist.

Das liegt aber nicht am Prozessor, sondern an der Verschlüsselung allgemein.

Das ist doch egal, Fakt ist, dass wenn ich meinen Prozi auf 2,8GHz habe, ich mit TC ziemlich genau 400MB schaffe. Das spiegelt sich dann genauso in Benches und beim Kopieren von Dateien wieder. Habe ich ihn auf 3,4GHz schafft er 50-70MB mehr, also limitiert hier doch der Prozi. Das Gleiche hab ich bei Phenoms gesehen, ein Quad schafft 400 und ein Sixcore 600, also ich das doch auch CPU abhängig?

 

[Whistl0r]

Man nehme eine Festplatte, lege darauf eine 10GB große Datei.
Wenn man diese Datei jetzt von der Festplatte liest, dann erreicht das System ~130MB/s (sehr gute Werte für aktuelle SATA-Festplatten).

Jetzt verschlüsselst du diese Festplatte und liest die Datei erneut. Diesmal erreicht das gleiche System aber nur ~90MB/s.

Verstehe ich dich richtig das du behauptest, wenn man jetzt lediglich den Prozessor durch einen besseren ersetzen würde (mehr MHz/Cores), du auf >90MB/s kommen würdest?

Wenn ja, wo siehst du denn das Limit?

 

[Poddy]

Nein, da limitiert natürlich die Verschlüsselung
Wobei hier ja DC so gut programmiert ist dass es wohl eher Richtung 130 gehen würde.
Die Limitierung die ich meine geht in Richtung maximal Leistung. Im Moment ärgert es mich dass meine CPU beim Kopieren zwischen den Raid-Arrays limitiert. Mit einem i7-2600 oder 6core hätte ich das Prob nicht mehr

 

[Whistl0r]

Magst du mal etwas kopieren (>10GB große Datei) und davon einen Screenshot erstellen, auf dem folgendes zu sehen ist:

a) Ausgeklappter Kopierdialog von Windows
b) Windows Taskmanager "Leistungstab"
c) Im "Process Explorer" von Sysinternals klickst du mit der rechten Maustaste auf "System" und zeigst das Tab "Threads" sortiert nach CPU-Last absteigend

d) Ressourcenmonitor (über Windows Taskmanager startbar), Tab "Datenträger" (dort die Diagramme rechts)

Sollte sich alles sichtbar für einen Screenshot anordnen lassen...

Würde mich sehr interessieren wie das bei dir aussieht.

 

[Poddy]

Glaubst du mir nicht
Also wenn du die Forumssuche oder Google bemühst wirst genau auf das stoßen was ich schildere.
Aber nun gut, mach ich das mal.

 

[Poddy]

Ist der Process Explorer wichtig, sonst installier ich den noch.
Wie du sieht 200MB pro Laufwerk > weil ja beide Laufwerke verschlüsselt sind.

http://img842.imageshack.us/img842/1655/neuesbildd.jpg

 

[musschrott]

Unverschlüsselt kann die Festplatte jetzt in die Blöcke reinsehen und weiß, welche Bits sich verändert haben. Beim Speichern eines geänderten Blocks muss dieser zwar dennoch gelesen werden (kann allerdings aus dem Cache kommen!) und im Endeffekt wird er auch wieder vollständig geschrieben... [...]
Sobald FDE ins Spiel kommt, kann der Controller nicht mehr in den Block schauen bzw. es haben sich einfach immer alle Bits des Blocks geändert. Somit muss er eigentlich immer direkt schreiben, der Cache läuft so sau schnell voll... und beim Lesen bringt der Cache auch nichts, da das der FDE-Treiber immer volle Blöcke anfordert, weil er diese entschlüsseln muss.

Festplatten arbeiten mit Sektoren von 512Bytes bzw. 4k Größe, ich kann mir kaum vorstellen, dass die sich um Veränderungen bei einzelnen Bytes, geschweige denn Bits kümmern. Würde man das versuchen, dürfte das einen ordentlichen Overhead für die Verwaltung der einzelnen Bytes geben. Für die Festplatte dürfte nur relevant sein, ob sich ein Sektor verändert hat und diesen dann komplett Schreiben/Cachen etc. Da die Blockgröße von AES 128 Bits (= 16 Bytes) ist, hätte jede relevante Veränderung so oder so zu einem veränderten Sektor und entsprechender Festplatten-Aktivität geführt.

 

[cRaZy-biScuiT]

Gleiche Systeme durch Prozessoren mit AES-NI ersetzt sorgen nur dafür, dass die Prozessorlast sinkt, d.h. mehr Ressourcen für anderes frei ist/geringerer Stromverbrauch. Es ist aber wirklich nicht so, als limitiere der Prozessor und als würde mit AES-NI mehr gehen.

Richtig, aber das eben würde ich gerne wollen. Wir leben eigentlich nicht mehr in der PIO-Steinzeit wo ein Festplattenzugriff die CPU auslasten sollte. Auch verschlüsselt muss das nicht sein.

-> Die Screens sind interessant.

 

[dezly]

Oh, schade. Musste wieder von DC auf TC wechseln. Die Performance von DC war schon gut aber leider hatte ich diverse Probleme. Dirt 3 startete nocht, das Bild blieb einfach schwarz, Starcraft musste ich auf einer anderen Platte, die mit TC verschlüsselt war, installieren und rüberkopieren, diverse andere Programme machten auch Probleme.
Hatte das schonmal wer?
Ohne Verschlüsselung und mit TC funktioniert es problemlos.

 

[stw500]

1. Mehr Mhz pro Kern bringen definitiv mehr Leistung bei einer Verschlüsselung, genau wie Poddy das schon mehrfach versucht hat klarzustellen. Das hat nichts mit einer grundsätzlichen Limitierung aufgrund der unterschiedlichen Implementierung des Algorithmus von TC oder DC zu tun.

2. Bei mir läuft alles mit DC, noch keine Probleme insoweit gehabt.

 

[dezly]

Ich hab alles ausprobiert. Bei Starcraft ging nur rüberschieben und das Repairtool laufen lassen, danach lief es. Installation auf der SSD ging nicht, da es dann nicht patchbar war.

Bei Dirt 3 ging weder installation noch kopieren auf der/die SSD. Auf einer HDD ging beides. Mit TC gehts nun auch auf der SSD.
Dass das problem nicht jeder haben kann, dachte ich mir auch, aber bei mir gehts nunmal wenn ich nicht DC verwende. Woran das sonst noch liegt, weiss ich nicht, wüsst ich aber gerne. Bimn da ziemlich ratlos leider.

 

[stw500]

Zu 1.
Wenn das Medium z.B. HDD nicht schneller schreibt, spielt das aber keine Rolle.

Also von Dir hätte ich so eine Antwort nicht erwartet, Bob...

Ist uns doch allen klar, dass wenn das Medium limitiert, die CPU so schnell sein kann, wie sie will. Im sequentiellen Bereich wird auch mit einer langsameren CPU kaum eine HDD wegen einer Verschlüsselung mit einem (!) Algorithmus (z.B. AES) limitieren. Bei einer SSD mit über 300 oder 400 MB/s kann das schon mal passieren. Im random Bereich kommt das noch viel eher zu Tage. Bei HDDs ist das egal, die sind eh immer langsam. Bei einer SSD kann man sich aber mit einer langsamen CPU auch gute 4k-Werte abschminken, das wurde auch in User-Tests oftmals belegt.

Ähnlich ist es im realen Betrieb, wenn durch mehrere Zugriffsanforderungen gleichzeitig (verschiedene Programme erteilen Befehle gleichzeitig) etwas gelesen/geschrieben werden soll.

Eine CPU mit hohem Takt pro Kern (da nicht alles perfekt parallelisiert werden kann) ist dementsprechend unumgänglich, um das Medium-Limit überhaupt erreichen zu können.

 

[stw500]

Ui, jetzt reden wir aneinander vorbei. Ja, TC limitiert bei 4k mehr als DC. Das hat aber nichts mit einer hardwarebasierten Limitierung zu tun. Da gilt dann mein oben gesagtes zu CPU und HDD/SSD. Mit einer Atom-CPU wirst Du z.B. kaum feststellen können, dass TC limitiert, weil eine SSD mangels CPU-Leistung noch nicht mal unverschlüsselt hohe random-Werte schaffen wird.

Sieht man z.B. hier ganz gut:

http://www.hardwareluxx.de/community/11929910-post833.html

Mit 1Ghz deutlich langsamer als bei höherem Takt. War wohl in einem Asus EeePC, CPU weiß ich nicht.