SSD Disk Encryption (Truecrypt vs Bitlocker vs DiskCryptor)
- Ersteller Ausweiser
- Erstellt am
TI57
Enthusiast
- Mitglied seit
- 05.03.2012
- Beiträge
- 80
Willkommen aus der Arbeitswelt...
Auch wenn 2/3 dessen so lala sind, so melden die Leute gelegentlich noch recht besorgniserregende Probleme hier
DiskCryptor forum - Index
Ich weiß auch nicht genau warum 1.0.735 zwar im Thread gepostet wurde, aber über die Downloads nur 1.0.732 zu finden ist. Hmm... Irgendwie ist der Ty<p urplötzlich von der Bildoberfläche verschwunden
Kann man denn nun davon ausgehen, daß DC noch am Leben ist? KP. Das russische Forum sieht ja nicht so sehr belebt aus. Der letzte Eintrag von ntldr, den ich gefunden habe, ist vom 4. Feb. 2012.
Hier gibt es eine "inoffizielle" Weiterentwicklung: DiskCryptor 1.0 Beta. Sieht auch nicht so belebt aus.
Welche kommerzielle Soft wäre denn noch gut geeignet?
Zuletzt bearbeitet:
BessereHälfte
Banned
- Mitglied seit
- 03.08.2006
- Beiträge
- 1.662
Dieser "inoffizieller" Patch behebt das Prob mit e820 und das wars auch. Die Einschränkungen sind bekannt, sonst rennt die Soft so wie sie soll und das ausgesprochen zuverlässig. Verträgt sich auch bestens mit TrueCrypt. DisCryptor auf die SSDs, TrueCrypt auf die HDDs und die Welt ist in Ordnung.
Die jeweils aktuellen TrueCrypt sources wie auch ihre Patches dienten als Lernmaterial und gehören teilweise leicht angepasste zu der Programmbasis. Da müßte es schopn mit dem Teufel zugehen oder gewollt sein (!), wenn DiskCrypto unsicherer wäre als TrueCrypt 7.1.
Die jeweils aktuellen TrueCrypt sources wie auch ihre Patches dienten als Lernmaterial und gehören teilweise leicht angepasste zu der Programmbasis. Da müßte es schopn mit dem Teufel zugehen oder gewollt sein (!), wenn DiskCrypto unsicherer wäre als TrueCrypt 7.1.
Und wie hat es sich geschlagen, was spricht eigentlich gegen Bitlocker und für DC? TC scheint ja bekannterweise bei SSD nichts zu taugen ...
Die neueste Beta läuft bei mir und anderen seit Monaten einwandfrei und ohne Probleme, dürftest Du also bedenkenlos nehmen können. Vorheriges Backup bzw. Imagesicherung ist natürlich - wie bei allen Verschlüsselungsprogrammen - Pflicht!
---------- Post added at 18:44 ---------- Previous post was at 18:39 ----------
Also dass TC bei SSDs nichts taugt, kann man so nicht sagen. TC bietet ebenso wie DC eine Implementierung des Trim-Befehls und ist ggf. sogar bei sequentiellen Zugriffen ein wenig fixer (meine Erfahrung). Dafür ist es halt bei den 4k-Zugriffen deutlich langsamer. Ob TC oder DC bei anderen Zugriffen (random 8k und aufwärts bis sequentiell) schneller ist, hat hier noch keiner getestet. Neuere SSDs haben auch keine 4k-Blockgrößen mehr, sondern 8k, so dass das durchaus interessant sein könnte.
Auch hat noch keiner Realtests mit einer Stoppuhr oder ähnliches bzgl. TC/DC gemacht.
Subjektiv würde ich aber DC doch als schneller und damit geeigneter für SSDs einschätzen. Bitlocker finde ich allein deshalb ungünstig, weil es zum Betriebssystem hinzugehört. Inwiefern eine unproblematische Entschlüsselung bzw. Rettung von Daten ohne Win-OS möglich ist, weiß ich deshalb nicht. Bei DC oder TC kann man von Linux mit Live-CDs aus zumindest eine Entschlüsselung durchführen, außerdem ist beides Open-Source, was mit vertrauenserweckender als eine geschlossene Sicherheitslösung erscheint. Nimmt man die Benchmarks des ersten Posts liegt Bitlocker auch hinten.
Zuletzt bearbeitet:
Hi, danke für die Antwort. Habe jetzt die Beta genommen, installiert und windows verschlüsselt. Hat alles super geklappt.
Und Backups mache ich eh. Da ich alles verschlüsselt habe, besitze ich meine Daten eh mehrfach. Die wichtigen glaube 4 mal ;-)
Und Backups mache ich eh. Da ich alles verschlüsselt habe, besitze ich meine Daten eh mehrfach. Die wichtigen glaube 4 mal ;-)
Das mögen manche für paranoid halten, ich habe aber meine im USA-Urlaub gerade geschossenen Fotos auch während der Reise täglich dreimal gebackuped, zwei externe HDDs und eine externe große Memory Card. Bin da also voll bei Dir! 
Man liest zuviel in reviews von SD-Karten in die Richtung "Karte auf einmal tot, alle Bilder futsch". Bei HDDs ist das ja nicht anders.
Man liest zuviel in reviews von SD-Karten in die Richtung "Karte auf einmal tot, alle Bilder futsch". Bei HDDs ist das ja nicht anders.Jup, vor allem kenne ich einige Leute denen schon bittere Sachen passiert sind. Ich sage da nur: halbe Diplomarbeit weg, weil nur auf einer Festplatte und nur bis zu 1/3 Ausgedruckt. Oder Komplett Chrash des Laptops, alles weg und das letzte Backup war dann leider 6 Monate alt etc. Und bei den Festplattenpreisen muss das nun wirklich nicht sein, dass man am falschen Ende spart ;-)
Mir selber ist es in jungen Jahren durch fremdverschulden meines Vaters passiert, dass dieser nach einem Bsod damals noch den Familien PC, nach Anweisung des Windowssuports einfach formatiert hat. Selber zudem Zeitpunkt noch unwissend gab es natürlich keine zweite Partition und schwubs war alles weg.Gott sei Danke hatte ich damals alles wichtige ausgedruckt. Hat mich dann aber ca. 4 Wochen meines Lebens gekostet, die Dokumente mit einem Texterkennngsprogramm wieder einzuscannen. Seid dem bin ich da sehr Vorsichtig. Und gerade den Leuten, die einen für Verrückt halten, passiert nämlich nacher der Supergau und dann kann ich nur sagen: Wer hats gesagt ;-)
Mir selber ist es in jungen Jahren durch fremdverschulden meines Vaters passiert, dass dieser nach einem Bsod damals noch den Familien PC, nach Anweisung des Windowssuports einfach formatiert hat. Selber zudem Zeitpunkt noch unwissend gab es natürlich keine zweite Partition und schwubs war alles weg.Gott sei Danke hatte ich damals alles wichtige ausgedruckt. Hat mich dann aber ca. 4 Wochen meines Lebens gekostet, die Dokumente mit einem Texterkennngsprogramm wieder einzuscannen. Seid dem bin ich da sehr Vorsichtig. Und gerade den Leuten, die einen für Verrückt halten, passiert nämlich nacher der Supergau und dann kann ich nur sagen: Wer hats gesagt ;-)
_Cyber_
Semiprofi
- Mitglied seit
- 22.03.2005
- Beiträge
- 1.320
hi,
ich hoffe die frage ist noch nicht all zu oft gestellt worden ...
ich hab hier im laptop eine ZIF SSD verbaut. ist PATA mit EastWho controller - lt Hersteller kein TRIM, dafür eine interne GC.
nun habe ich mit bitlocker verschlüsselt. jetzt kopiere ich gerade von einer langsamen USB HDD daten auf die SSD, mit sagenhaften 10MB/sec ...
ich vermute dass die interne GC der SSD mit bitlocker nicht funktionieren kann und deshalb das schreiben so langsam ist, oder? kann ich was amchen ausser wieder decrypten?
danke!
LG Cyber
ich hoffe die frage ist noch nicht all zu oft gestellt worden ...
ich hab hier im laptop eine ZIF SSD verbaut. ist PATA mit EastWho controller - lt Hersteller kein TRIM, dafür eine interne GC.
nun habe ich mit bitlocker verschlüsselt. jetzt kopiere ich gerade von einer langsamen USB HDD daten auf die SSD, mit sagenhaften 10MB/sec ...
ich vermute dass die interne GC der SSD mit bitlocker nicht funktionieren kann und deshalb das schreiben so langsam ist, oder? kann ich was amchen ausser wieder decrypten?
danke!
LG Cyber
_Cyber_
Semiprofi
- Mitglied seit
- 22.03.2005
- Beiträge
- 1.320
links das C-Lauferk das verschlüsselt ist, recht das unverschlüsselte E-Laufwer, das allerdings nicht mehr viel freien platz hat (sicherungspartition). Die SSD macht normal ~60MB/sec schreiben und ~90MB/sec lesen, zumindst lt. hersteller, und so weit fehlts zu den Angaben nicht.
CPU ist ein Core 2 Duo mit 2x 1,2GHz, die CPU ist bei ca. 25% (gesamt) wenn ich was kopiere, ich denke nicht dass das der Flaschenhals ist.
werd wohl - aufgrund desse dass Bitlocker nur komplette Laufwerke und keine einzelnen Ordner verschlüsseln kann - TrueCrypt o.A. installieren mit dem ich nur mein Benutzerprofil verschlüsseln kann.
Verschlüsseln ist mir hier für meine Daten wichtig da ich das Gerät mithabe und falls es mal gestohlen werden sollte ich zumindest private Sachen nicht in fremder Hand wissen will...
>>>Cyber
CPU ist ein Core 2 Duo mit 2x 1,2GHz, die CPU ist bei ca. 25% (gesamt) wenn ich was kopiere, ich denke nicht dass das der Flaschenhals ist.
werd wohl - aufgrund desse dass Bitlocker nur komplette Laufwerke und keine einzelnen Ordner verschlüsseln kann - TrueCrypt o.A. installieren mit dem ich nur mein Benutzerprofil verschlüsseln kann.
Verschlüsseln ist mir hier für meine Daten wichtig da ich das Gerät mithabe und falls es mal gestohlen werden sollte ich zumindest private Sachen nicht in fremder Hand wissen will...
>>>Cyber
Hi,
vielleicht kann mir hier jemand weiterhelfen - ich werde demnächst meine 2 WD Scorpio HDD`s durch 2 SSD`s im RAID-1 ersetzten.
Da ich TruCrypt einsetzen möchte (bin schon seit Jahren damit unterwegs und top zufrieden) will ich eigentlich keine SSD mit SandForce Controller... aktuell
schwanke ich zwischen der Samsung SSD830 (256GB) und der Plextor M3P (Marvell Controller,256GB).
Hat jemand von Euch Referenzwerte, welche der beiden SSD`s besser unter TC abschneidet? Write-Werte sind mir nicht so wichtig, ich bräuchte vor allem gute Werte bei sequ. Read (z.B. grosse Archive lesen bzw. nach extern entpacken).....?
Als Vergleich: die WD`s (2.5", 7200upm) schaffen gerade mal 15-20 mb/s bei entpacken (auf ein anderes HDD Array, das locker 200-300mb/s kann). Daher will ich hier gerne nachjustieren.
Fakten Samsung:
+ keine Komprimierung wie bei Sandforce
+ kein RAM Cache, bei BSOD o.ä. kleineres Risiko von Datenverlust
+ ganz guter GC, da TRIM im RAID-1 evtl. nicht so toll funzt
- schlechte Leistung unter TC ?
Fakten Plextor:
+ in Reviews immer recht schnell, nahe dran an der Samsung
+ auch ohne Komprimierung der Daten
+ niedrigere Leistungsaufnahme
+ Alternativ wohl auch AES Versclüsselung über den SSD Controller (?)
- unklare Leistung unter TC
Danke für alle Tipps!
MfG
JJ
vielleicht kann mir hier jemand weiterhelfen - ich werde demnächst meine 2 WD Scorpio HDD`s durch 2 SSD`s im RAID-1 ersetzten.
Da ich TruCrypt einsetzen möchte (bin schon seit Jahren damit unterwegs und top zufrieden) will ich eigentlich keine SSD mit SandForce Controller... aktuell
schwanke ich zwischen der Samsung SSD830 (256GB) und der Plextor M3P (Marvell Controller,256GB).
Hat jemand von Euch Referenzwerte, welche der beiden SSD`s besser unter TC abschneidet? Write-Werte sind mir nicht so wichtig, ich bräuchte vor allem gute Werte bei sequ. Read (z.B. grosse Archive lesen bzw. nach extern entpacken).....?
Als Vergleich: die WD`s (2.5", 7200upm) schaffen gerade mal 15-20 mb/s bei entpacken (auf ein anderes HDD Array, das locker 200-300mb/s kann). Daher will ich hier gerne nachjustieren.
Fakten Samsung:
+ keine Komprimierung wie bei Sandforce
+ kein RAM Cache, bei BSOD o.ä. kleineres Risiko von Datenverlust
+ ganz guter GC, da TRIM im RAID-1 evtl. nicht so toll funzt
- schlechte Leistung unter TC ?
Fakten Plextor:
+ in Reviews immer recht schnell, nahe dran an der Samsung
+ auch ohne Komprimierung der Daten
+ niedrigere Leistungsaufnahme
+ Alternativ wohl auch AES Versclüsselung über den SSD Controller (?)
- unklare Leistung unter TC
Danke für alle Tipps!
MfG
JJ
Mh, komisch - ich dachte der GC sei gut bei der Samsung.... ?
Zumal die neusten Intel RST Treiber doch auch TRIM im RAID durchreichen sollten?
TC ist nicht optimal, aber in diesem Fall ein muss, für mich persönlich ist aus diversen Gründen DC keine Alternative. Daher ach die
Frage nach der Controller-Verschlüsselung der Plextor SSD.
MFG
JJ
Zumal die neusten Intel RST Treiber doch auch TRIM im RAID durchreichen sollten?
TC ist nicht optimal, aber in diesem Fall ein muss, für mich persönlich ist aus diversen Gründen DC keine Alternative. Daher ach die
Frage nach der Controller-Verschlüsselung der Plextor SSD.
MFG
JJ
Nur mal so am Rande... TRIM und FDE ist ein Widerspruch.
Ein bisschen Theorie am Morgen:
Disk-Treiber schreiben immer in Blöcken. Mit Blöcken sind hier aber nicht physische Sektoren der Festplatten gemeint, sondern "logische Sektore" des Dateisystems, genannt "Cluster". Diese sollten aus Performance-Gründen zwar ein Vielfaches der physischen Sektoren sein (Stichwort Alignment), womit sie also Deckungsgleich mit den Sektoren der Festplatte wären, aber das muss eben nicht sein (wenn bspw. die logischen Partitionen falsch ausgerichtet wurden).
Alle gängingen FDE Lösungen sind als Low-Level Disk-Treiber implementiert. D.h. das Dateisystem (und der damit verbundene normale Disk-Treiber) sitzt "auf ihnen" (daher funktioniert FDE transparent, unabhängig vom verwendeten Dateisystem). Da es nun also sein kann, dass das Alignment der logischen Sektoren nicht mit den physischen Sektoren übereinstimmt, stellt der FDE-Treiber sicher, dass definitiv immer vollständige physische Sektoren geschrieben werden (übrigens eine Gefahr bei 512e Platten - weswegen BitLocker bspw. immer in 4K Blöcken arbeiten).
In der Praxis:
Angenommen ich erzeuge jetzt eine "geheim.txt", welche 1kb groß ist. Würde ich sie normal auf einem mit dem NTFS Dateisystem formatierten logischen Laufwerk speichern, würde ein Cluster herhalten müssen. Wenn es die erste Datei ist, würden also 4KB (Standard Cluster Größe) von der Datei belegt. Ja halt, nicht von der Datei selber, aber insgesamt würden 1kb Datei + 3kb Padding geschrieben werden (wie gesagt, Dateisysteme schreiben auch in Blöcken). Bei 512-Byte phys. Sektorengröße werden nun also real 8(!) Sektoren geschrieben werden, auch wenn für die realen Daten eigentlich 2 Sektoren reichen würden.
In diesem Beispiel muss der FDE-Treiber auch nicht groß eingreifen, da die Ausrichtung passt.
Wenn diese Datei nun gelöscht wird, und in dem Cluster ansonsten keine andere Datei liegt, markiert Windows den Cluster wieder als "frei". Das gibt er auch weiter an die Festplatte.
Hier würde jetzt der TRIM-Befehl greifen. Die SSD würde beim nächsten Müllsammeln (GC) die 8 Sektoren wieder in den Pool der verfügbaren Sektoren geben - natürlich sorgt die Firmware dabei dafür, dass diese Sektoren jetzt erst einmal "Pause" haben, damit sich die Zellen nach Möglichkeit gleich abnutzen.
Anders bei FDE:
Kein FDE-Treiber blockiert zwar den TRIM-Befehl, aber statt der Festplatte zu sagen "Sektoren 1-8 sind jetzt wieder frei" fängt er die Meldung ab und lässt "verschlüsselte Nullen" schreiben. Im Ergebnis werden die Sektoren also gar nicht freigeben, sondern vom FDE-Treiber weiterhin verwendet. Die SSD kann die Sektoren also nicht einsammeln und wieder dem Pool zuführen. Auch werden die Zellen stärker abgenutzt, weil sie eben ständig verwendet werden, "Wear leveling" greift also bei verschlüsselten SSD gar nicht.
Und wer jetzt glaubt: Das ist ja dumm! Das will ich nicht! Und eventuell auch schon gelesen hat, dass man mit bestimmten Modifikationen dafür sorgen kann, dass die verwendete FDE-Lösung keine "verschlüsselten Nullen" schreibt, sondern die physikalischen Sektoren wirklich freigibt, der sollte sich noch einmal überlegen, weshalb er eigentlich FDE verwendet... denn in dem Moment, wo der letzte Disk-Treiber die Sektoren der Festplatte zurückgibt, "verschwinden" sie (zumindest bei SSD). Soll heißen, es ist für den Nutzer und Treiber unmöglich exakt diese Zellen noch einmal anzufordern... dort liegen jetzt aber eben Daten. Zwar sollten sie aktuell noch verschlüsselt sein, aber dran kommen ist für mich schwer.
Sollte jetzt also der Fall eintreten, weswegen ich FDE einsetze, dann muss derjenige, vor dem ich die Daten schützen wollte, jetzt einfach nur "Lesen" bis diese Zellen mal wieder an der Reihe waren... (sollte also mein Key zwischenzeitlich kompromittiert worden sein, sind die Daten offen. Da hilft es mir auch nicht, wenn ich danach die Passphrase geändert habe - ich hätte anschließend auch die Daten komplett neu... ach halt, auch das bringt mir nichts: Ich komme ja nicht mehr an die Daten. Ich kann nur hoffen, dass diese Zellen dann bei dem Vorgang zufällig wieder an der Reihe sind...).
Zusammenfassung:
FDE und SSD verträgt sich nicht. FDE hebelt jegliche Performance-Features einer SSD aus.
Wer wirklich schützenswerte Daten hat, kann durch die Funktionsweise einer SSD zusätzlich gefährdet sein.
Ein bisschen Theorie am Morgen:
Disk-Treiber schreiben immer in Blöcken. Mit Blöcken sind hier aber nicht physische Sektoren der Festplatten gemeint, sondern "logische Sektore" des Dateisystems, genannt "Cluster". Diese sollten aus Performance-Gründen zwar ein Vielfaches der physischen Sektoren sein (Stichwort Alignment), womit sie also Deckungsgleich mit den Sektoren der Festplatte wären, aber das muss eben nicht sein (wenn bspw. die logischen Partitionen falsch ausgerichtet wurden).
Alle gängingen FDE Lösungen sind als Low-Level Disk-Treiber implementiert. D.h. das Dateisystem (und der damit verbundene normale Disk-Treiber) sitzt "auf ihnen" (daher funktioniert FDE transparent, unabhängig vom verwendeten Dateisystem). Da es nun also sein kann, dass das Alignment der logischen Sektoren nicht mit den physischen Sektoren übereinstimmt, stellt der FDE-Treiber sicher, dass definitiv immer vollständige physische Sektoren geschrieben werden (übrigens eine Gefahr bei 512e Platten - weswegen BitLocker bspw. immer in 4K Blöcken arbeiten).
In der Praxis:
Angenommen ich erzeuge jetzt eine "geheim.txt", welche 1kb groß ist. Würde ich sie normal auf einem mit dem NTFS Dateisystem formatierten logischen Laufwerk speichern, würde ein Cluster herhalten müssen. Wenn es die erste Datei ist, würden also 4KB (Standard Cluster Größe) von der Datei belegt. Ja halt, nicht von der Datei selber, aber insgesamt würden 1kb Datei + 3kb Padding geschrieben werden (wie gesagt, Dateisysteme schreiben auch in Blöcken). Bei 512-Byte phys. Sektorengröße werden nun also real 8(!) Sektoren geschrieben werden, auch wenn für die realen Daten eigentlich 2 Sektoren reichen würden.
In diesem Beispiel muss der FDE-Treiber auch nicht groß eingreifen, da die Ausrichtung passt.
Wenn diese Datei nun gelöscht wird, und in dem Cluster ansonsten keine andere Datei liegt, markiert Windows den Cluster wieder als "frei". Das gibt er auch weiter an die Festplatte.
Hier würde jetzt der TRIM-Befehl greifen. Die SSD würde beim nächsten Müllsammeln (GC) die 8 Sektoren wieder in den Pool der verfügbaren Sektoren geben - natürlich sorgt die Firmware dabei dafür, dass diese Sektoren jetzt erst einmal "Pause" haben, damit sich die Zellen nach Möglichkeit gleich abnutzen.
Anders bei FDE:
Kein FDE-Treiber blockiert zwar den TRIM-Befehl, aber statt der Festplatte zu sagen "Sektoren 1-8 sind jetzt wieder frei" fängt er die Meldung ab und lässt "verschlüsselte Nullen" schreiben. Im Ergebnis werden die Sektoren also gar nicht freigeben, sondern vom FDE-Treiber weiterhin verwendet. Die SSD kann die Sektoren also nicht einsammeln und wieder dem Pool zuführen. Auch werden die Zellen stärker abgenutzt, weil sie eben ständig verwendet werden, "Wear leveling" greift also bei verschlüsselten SSD gar nicht.
Und wer jetzt glaubt: Das ist ja dumm! Das will ich nicht! Und eventuell auch schon gelesen hat, dass man mit bestimmten Modifikationen dafür sorgen kann, dass die verwendete FDE-Lösung keine "verschlüsselten Nullen" schreibt, sondern die physikalischen Sektoren wirklich freigibt, der sollte sich noch einmal überlegen, weshalb er eigentlich FDE verwendet... denn in dem Moment, wo der letzte Disk-Treiber die Sektoren der Festplatte zurückgibt, "verschwinden" sie (zumindest bei SSD). Soll heißen, es ist für den Nutzer und Treiber unmöglich exakt diese Zellen noch einmal anzufordern... dort liegen jetzt aber eben Daten. Zwar sollten sie aktuell noch verschlüsselt sein, aber dran kommen ist für mich schwer.
Sollte jetzt also der Fall eintreten, weswegen ich FDE einsetze, dann muss derjenige, vor dem ich die Daten schützen wollte, jetzt einfach nur "Lesen" bis diese Zellen mal wieder an der Reihe waren... (sollte also mein Key zwischenzeitlich kompromittiert worden sein, sind die Daten offen. Da hilft es mir auch nicht, wenn ich danach die Passphrase geändert habe - ich hätte anschließend auch die Daten komplett neu... ach halt, auch das bringt mir nichts: Ich komme ja nicht mehr an die Daten. Ich kann nur hoffen, dass diese Zellen dann bei dem Vorgang zufällig wieder an der Reihe sind...).
Zusammenfassung:
FDE und SSD verträgt sich nicht. FDE hebelt jegliche Performance-Features einer SSD aus.
Wer wirklich schützenswerte Daten hat, kann durch die Funktionsweise einer SSD zusätzlich gefährdet sein.
Unfug.
Ja, sie müssen nichts schreiben - sie sollten aber (und die meisten FDE-Lösungen tun es auch).
Ich hätte schreiben sollen, dass unverschlüsselte Daten in den Bereichen zurückbleiben. Das stimmt allerdings nicht exakt. Das ist kompliziert. Letztendlich - egal ob verschlüsselt oder nicht - der an die SSD zurückgegebene Bereich gibt Informationen preis, welche die gesamte FDE gefährden. Siehe auch die Warnung:
TrueCrypt - Free Open-Source Disk Encryption - Documentation - Trim Operation
Und auch Milan Broz's blog: TRIM & dm-crypt ... problems? dürfte interessant sein.
Bitte verstehe mich nicht falsch, aber ich wäre sehr überrascht wenn du die Arbeitsweise von TRIM überhaupt jemals - unabhängig von FDE - getestet hast. Schreibe doch bitte mal, wie du meinst kontrolliert zu haben, ob TRIM "funktioniert".
Dann weiß ich nicht, welche FDE-Lösungen du kennst... was glaubst du denn, woher der Performance-Unterschied zwischen einer verschlüsselten Festplatte und einer unverschlüsselten Festplatte kommt? Heutig Systeme mit SATA III und AES-NI ect. sind garantiert nicht mehr die Flaschenhälse.
Ganz einfach: Die Laufwerke müssen mehr lesen und mehr schreiben.
Wer sich jetzt fragt, weshalb das der Fall sein sollte, schließlich lesen Festplatten, unabhängig von FDE, immer in Blöcken. Wenn also alles perfekt ausgerichtet ist, woher dann der Overhead? Ganz einfach: Die Controller erkennen was echte Daten und was Padding ist. Die aufgefüllten Daten werden natürlich nicht im Cache gehalten - somit passt mehr in den Cache. In der Praxis muss also weniger neu gelesen/geschrieben werden. Ist das LW verschlüsselt, dann glaubt der Controlle, der gesamte Block seien Daten. Padding erkennt er nicht mehr, weil eben die gesamtem Blöcke verschlüsselt sind. Somit kann ein Cache weniger helfen und es muss öfters von der Quelle gelesen werden.
Ganz einfach: Die Laufwerke müssen mehr lesen und mehr schreiben.
Wer sich jetzt fragt, weshalb das der Fall sein sollte, schließlich lesen Festplatten, unabhängig von FDE, immer in Blöcken. Wenn also alles perfekt ausgerichtet ist, woher dann der Overhead? Ganz einfach: Die Controller erkennen was echte Daten und was Padding ist. Die aufgefüllten Daten werden natürlich nicht im Cache gehalten - somit passt mehr in den Cache. In der Praxis muss also weniger neu gelesen/geschrieben werden. Ist das LW verschlüsselt, dann glaubt der Controlle, der gesamte Block seien Daten. Padding erkennt er nicht mehr, weil eben die gesamtem Blöcke verschlüsselt sind. Somit kann ein Cache weniger helfen und es muss öfters von der Quelle gelesen werden.
musschrott
Enthusiast
- Mitglied seit
- 31.01.2007
- Beiträge
- 632
1) Nur um das noch mal festzuhalten: Trim widerspricht nicht FDE und Trim kann sehr wohl damit zusammen arbeiten. Deine Quellen belegen das sogar.
2) Wenn man einen zusätzlichen Software-Layer dazwischen packt, dann ist es ganz selbstverständlich, dass sich da Geschwindigkeitseinbussen ergeben. Nicht umsonst gibt es deutliche Geschwindigkeitsunterschiede zwischen verschiedenen FDE Lösungen (siehe erste Seite).
3) Eine voll geschriebene SSD hat u.U. Geschwindigkeitsprobleme, aber das liegt dann an der SSD als solches.
4) Das mit dem Overhead/Padding/Caching macht für mich keinerlei Sinn. SSDs arbeiten als minimale Größe mit 4kb (Seite/page) und dem Controller wird es egal sein ob da Nullen am Ende sind oder nicht. Auf dieser Ebene sich um 0-bytes zu kümmern wäre Overhead, das wird einfach als ein Datensatz behandelt. Der Controller wird schon genug damit zu tun haben, dass man bei SSDs nicht einzelne Seiten speichern kann, sondern 128(?) Seiten einen Block ergeben und die SSD nur blockweise schreiben kann. Ob der Controller überhaupt 0-byte Seiten erkennt oder einfach alles als Daten behandelt und wegschreibt ist dabei noch eine ganz andere Frage.
5) Ein Betriebssystem schreibt im Normalfall keine 0-bytes auf die Platte wenn Dateien gelöscht werden. Es merkt sich einfach intern als Teil des Dateisystems welche Seiten frei sind. Ein dateisystemunabhängiger Treiber erhält dadurch aber nie eine Schreibanweisung und kann auch nichts überschreiben. Es gibt im Normalfall aber auch keinerlei Notwendigkeit die Daten zu überschreiben, denn sie sind verschlüsselt.
6) Ohne Trim hat die SSD keinerlei Kenntnis davon, welche Bereiche leer sind selbst wenn kein FDE eingesetzt wird. Früher oder später ist aus Sicht der SSD alles voll geschrieben und es gibt nurnoch überschreiben Operationen. Ohne Trim sind SSDs aber nicht automatisch langsamer.
Defence
Experte
Habe auch vor mir für meinen HTPC ne neue SSD zuzulegen und sie fürs System zu nutzen. Möchte auch gerne das komplette System mit TrueCrypt verschlüsseln. Habe meine bisherige Intel 320SSD in mein Laptop verfrachtet und daher läuft zur Zeit nur ne normale HDD in meinem HTPC, dass muss wieder geändert werden. Nun überlege ich die ganze Zeit hin und her und kann mich nicht entscheiden welche SSD ich mir für meinen HTPC holen soll. Bin mit Intel eigentlich sehr zufrieden, und die 520er kostet NEU auch nur um die ~120€ mit 5 Jahre Garantie, nur leider hat die 520er ja SandForce Controller. Die 320er die ich jetzt in meinem laptop habe, kostet zur Zeit NEU mit Nachnahmeversand um die ~170€ das ist schon ein unterschied zu den 120€ für die 520er.
Wichtig: Verschlüsselung nur mit TrueCrypt, mindestens 120GB, lange Garantie.
Nicht so wichtig: Mega Speed, da ich die SSD nur als SystemSSD im HTPC verwenden möchte und damit der HTPC schneller hochfährt.
Ich kann 140€ ausgeben, was würdet ihr empfehlen da empfehlen?
Wichtig: Verschlüsselung nur mit TrueCrypt, mindestens 120GB, lange Garantie.
Nicht so wichtig: Mega Speed, da ich die SSD nur als SystemSSD im HTPC verwenden möchte und damit der HTPC schneller hochfährt.
Ich kann 140€ ausgeben, was würdet ihr empfehlen da empfehlen?
Zuletzt bearbeitet:
Wieso schließt du Sandforce komplett aus?
Winkom MLX8 Pro 120GB mit Truecrypt FSE (WA btw bei ~1,63):
Die 830 256GB bricht zumindest bei 4k QD1 mehr ein. Im Netz habe ich leider keine SATA III Benchis damit finden können, nur SATA II. KLICK!
EDIT: S-ATA III Benchis 830 256GB mit TC -> http://www.hardwareluxx.de/communit...er-vs-diskcryptor-689181-16.html#post18946899 Man beachte die Zugriffszeit beim Lesen!
Eine Crucial M4 64GB habe ich auch noch hier, die brach bei 4k sogar auf 6,8MB/s ein. Seq read war dafür einwandfrei, siehe:
Auch wenn nun 100% unkomprimierbare Daten vorliegen, so arbeiten die Sandforce Laufwerke mit TC wohl ganz gut. Einen Vergleich mit M4 128GB habe ich gerade noch per google gefunden, wobei die niedrigen read Werte etwas seltsam sind. Ist vielleicht der alten FW geschuldet.
Würde Sandforce also nicht pauschal ausschließen. Wäre schon wenn du nach deiner Entscheidung Benchmarks posten würdest, gerade wenn du auf z.B. Plextor setzen solltest. Würde mich sehr interessieren, wie die mit TC klar kommen. Mich persönlich würde in dem Zusammenhang im Übrigen eine Neutron GTX reizen, auch wenn die neu am Markt ist.
Zuletzt bearbeitet:
nach langer Zeit mal wieder gebencht.
Jetzt nicht mehr mit Win 7, sondern mit Win 8 und Bitlocker verschlüsselt.
HP Elitebook 8560w, i7-2820QM, 16GB DDR, Intel QM67, SATAIII
Extrememory XLR8 Express 240GB (163GB frei)
Win 8 Enterprise 64bit
Storahci
Bitlocker verschlüsselt
Ich bin erstaunt, dass trotzdem die Werte in der gleichen Region sind - aber ok, selbst wenn die ein gutes Stück niedriger gewesen wären, beim Laptop ist Verschlüsselung nun mal schon eine sinnvolle Idee.
Jetzt nicht mehr mit Win 7, sondern mit Win 8 und Bitlocker verschlüsselt.
HP Elitebook 8560w, i7-2820QM, 16GB DDR, Intel QM67, SATAIII
Extrememory XLR8 Express 240GB (163GB frei)
Win 8 Enterprise 64bit
Storahci
Bitlocker verschlüsselt
Ich bin erstaunt, dass trotzdem die Werte in der gleichen Region sind - aber ok, selbst wenn die ein gutes Stück niedriger gewesen wären, beim Laptop ist Verschlüsselung nun mal schon eine sinnvolle Idee.
aquaduct
Neuling
Hp 625 dc ssd
Hallo,
anbei meine Ergebnisse eines HP625 Notebooks:
-AthlonII P360 Prozessor
-SATA 3 Unterstützung
-8GB DDR3 RAM
-AMD AHCI Treiber 12.8
mit einem frischen Win7 x64 SP1
und einer Vollverschlüsselung AES mit DiskCryptor (neueste Beta) erreiche ich:
Ich bin sehr zufrieden,
jetzt muss es nur noch möglichst lange halten!
Grüße
Hallo,
anbei meine Ergebnisse eines HP625 Notebooks:
-AthlonII P360 Prozessor
-SATA 3 Unterstützung
-8GB DDR3 RAM
-AMD AHCI Treiber 12.8
mit einem frischen Win7 x64 SP1
und einer Vollverschlüsselung AES mit DiskCryptor (neueste Beta) erreiche ich:
Ich bin sehr zufrieden,
jetzt muss es nur noch möglichst lange halten!
Grüße
- Mitglied seit
- 15.02.2004
- Beiträge
- 4.345
G
Gelöschtes Mitglied 55164
Guest
Die 366mb/s lesend sind eigentlich typisch für den Marvellcontroller, war die SSD damals vllt woanders eingebaut?
Nö, war ja beides mit dem iaStor, mh.
Nö, war ja beides mit dem iaStor, mh.
Zuletzt bearbeitet von einem Moderator:
moin,
ein thema nach meinem geschmack und genau das, was ich gesucht habe
ich interessiere mich hauptsächlich für die bootloaderfunktion von diskcryptor. im moment besitze ich noch keine ssd und verwende truecrypt mit der hidden-os funktion.
meine befürchtungen bei einer ssd waren/sind, dass der geschwindigkeitsvorteil durch eine verschlüsselung zur nichte gemacht wird.
alle seiten in diesem thread habe ich nicht gelesen, jedoch erschien mir das, was ich von euch gelesen habe und die dazu erstellen benchmarks nicht so kritisch.
beim seq. lesen ist der einschnitt mit ~25% nicht wenig, allerdings scheint das random-lesen kaum durch die verschlüsselung beeinträchtigt zu werden.
meine frage an euch, wie viel speicher eurer ssd habt ihr verschlüsselt bzw. wie viel unpartioniert gelassen ? und kann ich mit dem bootloader von diskcryptor die hidden-os funktion von TC "nachbauen" ? (ist ja im grunde nichts anderes als verschiedene passwörter für verschiedene betriebssysteme)
vielen dank !
ein thema nach meinem geschmack und genau das, was ich gesucht habe
ich interessiere mich hauptsächlich für die bootloaderfunktion von diskcryptor. im moment besitze ich noch keine ssd und verwende truecrypt mit der hidden-os funktion.
meine befürchtungen bei einer ssd waren/sind, dass der geschwindigkeitsvorteil durch eine verschlüsselung zur nichte gemacht wird.
alle seiten in diesem thread habe ich nicht gelesen, jedoch erschien mir das, was ich von euch gelesen habe und die dazu erstellen benchmarks nicht so kritisch.
beim seq. lesen ist der einschnitt mit ~25% nicht wenig, allerdings scheint das random-lesen kaum durch die verschlüsselung beeinträchtigt zu werden.
meine frage an euch, wie viel speicher eurer ssd habt ihr verschlüsselt bzw. wie viel unpartioniert gelassen ? und kann ich mit dem bootloader von diskcryptor die hidden-os funktion von TC "nachbauen" ? (ist ja im grunde nichts anderes als verschiedene passwörter für verschiedene betriebssysteme)
vielen dank !
KurzGedacht
Enthusiast
- Mitglied seit
- 26.10.2003
- Beiträge
- 1.858
Hat schon jemand die samsung 840 oder 840 pro mit Truecrypt getestet? Würde mich sehr interessieren.
