SSD Disk Encryption (Truecrypt vs Bitlocker vs DiskCryptor)

Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Schon ein weng strange. Allerdings: Die ursprüngliche unoffiziel-Version stammt ja aus Januar 2012, also doch fast ein Jahr alt. Möglicherweise sind seit dem keine Probleme aufgetaucht, so dass sich der Entwickler gedacht hat, er könne das Teil jetzt final machen.

EDIT: Schaut man sich das inoffizielle Changelog von Daggering Cats an, dann zielt das Update nur auf die Vermeidung des Memory Leak errors, der nur sehr vereinzelt aufgetreten ist. Ob es sich hierfür lohnt das Risiko des Updates einzugehen? Oder hat Visual Studio 2010 noch einen anderen Sinn, den ich bislang nicht erkannt habe?
 
Zuletzt bearbeitet:
Falsche Schlußfolgerung :)
Der Fehler, den Avon da rausgepatcht hat war real. Dieser kam raus, als ntldr schon erklärt hat, er hätte erstmal keine Zeit mehr für DiskCryptor. Und das ein halbes Jahr danach, nachdem es schon eine Totenstille seitens ntldr gab. Jetzt haben wir 1.5 Jahre und plötzlich eine final :)

Mir ging es also nicht um avon, sondern um die plötzliche Final. Es scheint aber ntldr account zu sein. Hab da bisschen genauer rumgezappt...
DiskCryptor 1.0.744.115 released

Daß bad asses so eine Seite hacken und da eigene Dateien verteilen liegt aber im Rahmen des Möglichen... Deswegen bin ich da grad noch vorsichtig :)

p.s.:
Momentan hat das EINER Probleme mit standbys.
 
Die Probleme mit dem Standby / Ruhezustand hatte ich zumindest mit den älteren Versionen (Laptop + Desktop), weshalb bei mir TrueCrypt im Einsatz ist. Gefühlt ist das auch nicht langsam, die Benchmarks sind natürlich alles andere als Schön. Da ich mir diese jedoch nicht ausdrucke und an die Wand hänge irgendwie auch kein Problem... (Das Windows 7-Logo beim Starten fliegt nicht mal komplett rein, bevor auf den Willkommen-Bildschirm geschaltet wird - mit einer Samsung 830 + TrueCrypt.)
 
Hallo, welche Controller sind für TC nun die empfehlenswertesten, weil schnellsten? Habe mir den ganzen Thread durchgelesen, in welchem sich die Aussage herausbildete, Sandforce-Controller und TC seien zu vermeiden, dann aber von Mr. Mito auf Seite 19 ganz oben ein recht flotter Sandforce-Benchmark hineingestellt wird.
 
Die Sandforce sind zu meiden Aussagen stammen schlicht weg aus der Theorie, was ja soweit auch korrekt ist, da die SF Kompression dann nicht mehr funktioniert.

Die Praxis siehst du dann in meinem Benchmark. Im Endeffekt zählt eben das, was am Ende raus kommt und da schlagen sich die Laufwerke mit TC besser als manch andere. ;)

Die 840 pro würde ich mal gerne mit TC sehen. Der Controller scheint ja ordentlich Leistung zu bieten.
 
Deswegen kann man solche Aussagen bei SSDs eher mit DiskCryptor als mit TrueCrypt treffen. Im Allgemeinen.

Wenn der Benutzer TrueCrypt benutzen möchte muß man sich an die realen Gegebenheiten halten. Nützt nichts.

p.s.:
Das ist mittlerweile ne Weile her, daß es etwas von den TC Proggern zu hören gab...
 
Zuletzt bearbeitet:
Es ist aber nun einmal so das manche SSDs mit TC mehr einbrechen, als andere. Das SSD selbst spielt daher auch eine Rolle, wenn auch leider die Nebenrolle. Dennoch spricht nichts dagegen dies im Vorfeld mit einzuplanen.

Eine 64GB M4 bricht z.B. auf ~6,5MB/s bei 4k read ein.
 
hat einer einen Link für ein deutschsprachiges Tutorial mit Schritt für Schritt Anleitung um eine SSD mit Truecrypt / Bitlocker oder auch DiskCryptor zu verschlüsseln ? bin bis jetzt nicht fündig geworden , oder aber google spinnt bei mir
 
Wäre auch dankbar für einen Hinweis von jemandem der sich gut auskennt, um nicht selbst diverse Tutorials (soweit
es sie denn gibt) durchlesen, vergleichen und bewerten zu müssen. Bin auch vor allem an TC und DC interessiert!
 
Also ich habe mich zu TC stundenlang einlesen müssen, bevor ich mich halbwegs mutig an die Verschlüsselung einfacher Datenpartitionen herangewagt habe ;) Schließlich sollte man bei dem Thema nicht nur irgendwie zum Ziel kommen, sondern
auch verstehen, was man da eigentlich tut, um folgenschwere Fehler zu vermeiden. Seinen Wunsch nach einem Tutorial,
in dem diese Erkenntnisse bereits eingearbeitet sind, finde ich daher nicht nur verständlich, sondern teile es im Falle der vollständigen Systemverschlüsselung auch.

Hat denn keiner 'n paar adäquate Links am Start? ;)
 
Bevor man damit anfängt, ist ein Backup empfehlenswert. Es sei denn, die zu verschlüsselnden Daten sind unwichtig.
 
Bevor man damit anfängt, ist ein Backup empfehlenswert.

Nun ja ... ich würde mal sagen, das ist der einzige Punkt, der sich von selbst versteht :fresse:

Nur sollte man angesichts dessen, wie lange die Verschlüsselung von einigen hundert GB dauert, nicht nur gleich auf Anhieb alles richtig machen, sondern for allem auch über wichtige Punkte wie das Anfertigen einer Sicherung des Volume Headers informiert sein. Weil das dauerhafte Vorhalten eines unverschlüsselten Backups die gesamte Verschlüsselung an sich ad absurdum führen würde, sind solche Informationen (die einen in der offiziellen Doku nicht gerade anspringen) für den Fall einer Korruption des verschlüsselten Volumes nach dem Löschen des temporären Backups "überlebenswichtig" ... und so weiter, und so fort.
 
Zuletzt bearbeitet:
Also, dass die 840 pro so gut unter Truecrypt performt, halte ich für ein Gerücht. Hier mal Benches von der 256 GB der Samsung 840 Pro.

Unverschlüsselt:

1 - UNENCRYPTED - as-ssd-bench Samsung SSD 840  09.01.2013 13-07-28.png

Truecrypt 7.1a:

3 - Truecrypt - as-ssd-bench Samsung SSD 840  09.01.2013 14-24-08.png

Diskcryptor 1.0.757.115:

2 - Diskcypter - as-ssd-bench Samsung SSD 840  09.01.2013 16-01-07.png

Ich selber besitze auch noch die 512er 840 Pro, aber kann die leider nicht vernüftig benchen, da die an einem SATA2-Controller hängt.
 
Am Ende zählt praktisch doch nur:

[...] weshalb bei mir TrueCrypt im Einsatz ist. Gefühlt ist das auch nicht langsam ...
... denn die sequenziellen Raten sind nach wie vor mehr als befriedigend (falls man wie z.B. beim Drive Imaging doch mal was größeres bewegen sollte oder die SSD auch als Medienspeicher verwendet) und die 4K-Raten nicht in dem Maße relevant, wie suggeriert wird. Anteilig treten 4K-Zugriffe im OS-Normalbetrieb zwar relativ häufig auf, jedoch lange nicht in der Masse wie sie ein Benchmark auf das arme Laufwerk einprasseln lässt, und schon erst recht nicht mit 64 Threads. Wo es sich unverschlüsselt vielleicht zu 80% der Zeit langweilt, guckt es verschlüsselt halt nur noch während 50% der Zeit Löcher in die Luft – mal rein hypothetische Werte, bloß zur Veranschaulichung. Sorgen würde ich mir da nur machen, wenn ich einen Server drauf laufen lassen wollte.

..., die Benchmarks sind natürlich alles andere als Schön. Da ich mir diese jedoch nicht ausdrucke und an die Wand hänge irgendwie auch kein Problem...
... wobei IMO die drastisch erhöhten Zugriffszeiten noch den schlechtesten Beigeschmack hinterlassen. Hat jemand ne Ahnung, warum das ausgerechnet beim Lesen der Fall ist? Als Nebeneffekt einer Verschlüsselung würde ich doch eher bei schreibenden Zugriffen Einbußen erwarten, wo diese jedoch eher gering ausfallen.
 
Zuletzt bearbeitet:
Also, dass die 840 pro so gut unter Truecrypt performt, halte ich für ein Gerücht. Hier mal Benches von der 256 GB der Samsung 840 Pro.

Unverschlüsselt:

Anhang anzeigen 220479

Truecrypt 7.1a:

Anhang anzeigen 220480

Diskcryptor 1.0.757.115:

Anhang anzeigen 220482

Ich selber besitze auch noch die 512er 840 Pro, aber kann die leider nicht vernüftig benchen, da die an einem SATA2-Controller hängt.
Andere SSDs sind mit TC deutlich langsamer, insofern finde ich die Werte super!

Danke für den Test. :)
 
Zuletzt bearbeitet:
Ja, sieht gut aus, jetzt muss die nur noch etwas billiger werden, SSDs werden eh jedes Monat um 7 Euro günstiger.
 
Hi,

habe ähnlich gute Ergebnisse mit Diskcryptor erzielt. Samsung 840 Pro - allerdings an SATA II.
Nach einem Tag haben sich der sequentielle Write Speed und 4K-64Thrd um ca. 100 MB/s verringert.
Woran kann das liegen? Kann es an der neusten Firmware liegen? Habe leider keinen direkten vorher/nachher Vergleich gemacht.

@Xhool: Hast du die aktuelle Firmware drauf? Sind die Werte nach ein paar Reboots unverändert?

Unverschlüsselt:
unencrypted.jpg


Truecrypt:
truecrypt.jpg


Diskcryptor:
diskcryptor.jpg


Diskcryptor 1 Tag später:
diskcryptor2.jpg
 
Zuletzt bearbeitet:
Hallo zusammen,

nochmals zur Klarstellung. Die Benches (der 256 GB Pro), die ich oben angeführt sind, sind nicht mit meinem System gemacht worden (war ein aktuelles Ivy-Bridge-System mit Intel Core i5-3470, also SATA3-Controller und Hardware-AES).

Jetzt poste ich noch zusätzlich neue Benches mit einer vier Tage alten Installation von meiner Samsung 840 Pro 512 GB :

Testbedingungen: mein System (siehe Systeminfo, Platte hängt am internen SATA2-Controller, kein AES-NI), aktuellste Diskcryptor-Version, aktuellste Firmware, Platte komplett partioniert, keine 100MB Windows Partition, zur Zeit zu etwa 1/3 gefüllt.

as-ssd-bench Samsung SSD 840  16.01.2013 11-29-21.png

Hier sieht man, dass der lahme Prozessor und der SATA2-Controller schon deutlich an der Performance ziehen. Dennoch läuft meine SSD immer noch sehr schnell, kein Vergleich zur Intel 320 unter Truecrypt...

@kitepascal: Leider besitze ich keine früheren Benches, da ich das nicht für nötig gehalten habe. Ich werde es jetzt mal im Auge behalten, ob die Werte nochmals nach unten gehen...

EDIT 2: @kitepascal: Vielleicht ist ja auch Windows 8 schuld :):):)
 
Zuletzt bearbeitet:
Hallo,

ich hätte da noch eine andere Frage zu Diskcryptor bzw. Truecrypt. Dieses mal aber besteht das konkrete Problem bei einer Festplatte (bei einer SSD tritt es auch auf, nur verschleiert die kurze Zugriffszeit der SSD die Auswirkungen):
Für mein Notebook (4-5 Jahre altes Dell Vostro 1500 mit 4GB RAM und einem T7100 C2D mit 1,8GHz) hatte ich noch die 30€ Win8-Aktion in Anspruch genommen um die teils langen Bootzeiten zu verkürzen. Und siehe da, selbst mit der damals mitgelieferten 160GB-Platte startet es wirklich sehr schnell. Nur leider besteht mit Truecrypt und Diskcryptor bei allen meinen Rechnern das Problem, dass ein Aufwachen vom Ruhezustand relativ lange dauert. Sieht man auch schön an der immer sehr kurz pulsierenden HDD-Led vom Vostro.
Das wäre an für sich kein Problem, nur leider startet Windows 8 genau wegen dem Ruhezustand-Hybridstart (oder wie auch immer MS das nennt) so schnell. Das ist mit verschlüsselter Platte natürlich nicht mehr drinnen.

Habt ihr Ideen ob man da vielleicht was machen kann?
 
Hat keiner schon Erfahrungen damit gesammelt?
 
Es lässt sich nicht beschleunigen, leider. Ist einer der Gründe, wieso ich den Ruhezustand nicht nutze. Er muss halt erst mal mehrere GB (zurück) in den RAM entschlüsseln, bevor er los legen kann.
 
Ich habe das ganze die Tage mit HxD und TC durchgespielt. Die Sektoren werden definitiv überschrieben, aber weder mit 00, noch FF, sondern mit Kauderwelsch. :fresse:

Ob dafür nun die Sandforce encryption zuständig ist oder oder sonst was, keine Ahnung. Habe leider keine unverschlüsselte Sandforce um gegen zu prüfen.
 
Zuletzt bearbeitet:
Bei mir funktioniert es mal, mal nicht (auf zwei Rechnern mit TC 7.1a getestet).

Im i.O.-Fall werden andere Daten im freien Bereich erkannt. Das sollte korrekt sein, da der Controller in diesen Bereichen lauter 0x00 hinterlegt, der Verschlüsselungstreiber aber nicht wissen kann, dass hier unverschlüsselte, leere Datenbereiche herum liegen und regulär die Sektoren "entschlüsselt". Dabei wird dann natürlich auch etwas anderes als 0x00 angezeigt ;).
 
Ob dafür nun die Sandforce encryption zuständig ist oder oder sonst was, keine Ahnung. Habe leider keine unverschlüsselte Sandforce um gegen zu prüfen.
Nein, die Sandforce liefern auch 00 zurück, wenn vorher getrimmte LBAs ausgelesen werden.
 
Nein, die Sandforce liefern auch 00 zurück, wenn vorher getrimmte LBAs ausgelesen werden.
Alles andere wäre auch sehr, sehr schlecht. Die Entschlüsselung erfolgt hier in Hardware vom SSD-Controller bevor die Daten auf den S-ATA-Link gelegt werden.

Mit TC leider das selbe Ergebnis wie mit DC, wahrscheinlich kann trimcheck bei einer FSE das Trimmen nicht verifizieren, es werden veränderte Daten festgestellt. Das würde zumindest dafür sprechen, dass hier etwas passiert und die Daten nicht einfach "liegen bleiben". Gehe daher davon aus, dass sowohl mit TC als auch DC TRIM funktioniert.
Das Programm macht von der Funktionsweise nichts anderes als dieses manuelle Vorgehen: Intel(R) Rapid Storage-Technologie (aktuell: v12.0.0.1083/v3.6.0.1094 WHQL) - Seite 20 - WIN7 - Treiber - Win-Lite Forum

Damit habe ich mit einer Postville Gen2 an einer AMD SB700 mit AMD-SATA-Treiber(!) sowie einer Samsung 830 @ Intel H67 erfolgreich auf TRIM getestet (sofort nach löschen der Datei waren andere Zufallszahlen an den entsprechenden Sektoren hinterlegt).


Die ausführlichere Erklärung, warum hier kein 0x00 zurück kommen kann.
Folgende Reihenfolge beim Lesen/Schreiben auf eine Festplatte ist bei Windows der Fall (kein Anspruch auf Vollständigkeit):
Dateisystemtreiber: fordert für eine Datei die entsprechenden Sektoren an => Verschlüsselungssoftware (Treiber): ver- bzw. entschlüsselt die Sektoren => Festplattencontroller (Treiber): schreibt bzw. liest die Sektoren => Festplattencontrolle (Hardware): Leitet die zu schreibenden / lesenden Sektoren mit Protokoll-Overhead an die SSD => SSD-Controller verarbeitet die Daten (Black-Box)

Wenn hier beim Löschen einer Datei vom Dateisystemtreiber beginnend ein TRIM-Kommando bis zum SSD-Controller weitergereicht wird, hat es NUR der SSD-Controller in der Hand was (und wann) auf die per TRIM als frei markierten Sektoren geschrieben wird. Legt er hier 0x00 ab, dann wird das beim Lesen ohne Verschlüsselung auch als 0x00 vom Dateisystemtreiber interpretiert. Mit Software-Verschlüsselung wird der Block mit dem Schlüssel entschlüsselt. Würde hier immer noch 0x00 heraus kommen, kann man die Verschlüsselungssoftware auch deinstallieren :d.
 
Eine Sache dazu nur noch: Die Tatsache das der Controller nur 00 zurückliefert sollte nicht aus Beweise dafür gesehen werden, dass die Daten wirklich gelöscht werden! Das würde die Write Amplification auch gewaltig in die Höhe treiben, denn dann müsst ja im schlimmsten Fall ein ganzer Block mit noch 255 oder 511 Pages voller gültiger Daten gelöscht werden, wenn eine Page darin vom TRIM betroffen war. Dazu müssten die Daten der anderen Pages natürlich vorher umkopiert werden. Deshalb macht das (hoffentlich!!!) keine FW Programmierer sondern hebt nur die Verknüpfung der LBAs mit der NAND Page auf und markiert die Daten also ungültig. Werden LBAs gelesen denen keine Flashadresse zugewiesen ist, so geben die Controller ja auch einfach 00 zurück und i.d.R. geht das recht schnell und ist genau das, was passiert wenn man z.B. mit HD Tune die Lesegeschwindigkeit einer (weitgehend) leeren SSD bencht.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh