Dr_Iwan_Kakalakow
Active Member
pp-user;n12228 said:
Ich bin mit VeraCrypt (OpenSource)sehr zufrieden. Aussehen und Handhabung fast wie bei TrueCrypt, aber stärker bei Attacken u.a.
SSD/HDD Crypten ?
- Thread starter pp-user
- Start date
Ich bin mit VeraCrypt (OpenSource)sehr zufrieden. Aussehen und Handhabung fast wie bei TrueCrypt, aber stärker bei Attacken u.a.
JackCarver
Well-known Member
LUKS ist Linux exklusiv...Wieso vertraust du der hauseigenen Marke nicht, aber Win schon? Jegliche Win Version könnte den prächtigsten Trojaner mit an Bord haben, davon kriegst du noch nichtmal was mit. Das passt halt irgendwie auch nicht zusammen. Wenn Bedenken bei Closed Source vorhanden ist, dann doch bitte komplett auf Open Source, also auch das OS und nicht so halb halb.
Rudpla
Active Member
Nochmal ein Nachtrag zu TC auf SSD: Ich nutze das selbst seit längerem, möchte aber auch darauf hinweisen, dass es einige Warnungen im TC-Handbuch dazu wegen TRIM und Wear-Levelling gibt. Man sollte bei einer SSD Windows installieren, dann sofort vollverschlüseln, danach erst alle Feineinstellungen und Programme. Man sollte auch wissen, dass sich aufgrund der zum OS hin transparenten Verschlüsselung, die wesentlich mehr Schreib-/Lesezugriffe mit sich bringt, die Lebensdauer einer SSD verkürzt.
Inkognito
Well-known Member
Naja, da ist so nicht richtig. Die Verschlüssselung braucht im Vergleich nur ein Mal mehr Schreibzyklen und das ist beim einmaligen Verschlüsseln selber. Was du meinst ist die Problematik mit Wear-Leveling, das sorgt im schlimmsten Fall aber nur für mehr Schreibzyklen auf immer denselben Zellen (aber nicht ingesamt), weil die gesamte SSD vollgeschrieben ist mit praktisch einer riesigen verschlüsselten Datei und kein Spielraum mehr fürs WL vorhanden ist.
Das ist aber halb so wild, da man 10 Prozent SSD Platz unpartitioniert und unverschlüsselt lassen kann (sicherheitstechnisch kein Problem!), moderne SSDs fast alle Überkapazitäten haben für genau den Fall, dass jemand die SSD 100 Prozent beschreibt und weil die Zellen bei Normalsterblichen ewig halten, sogar ein Vielfaches von den Herstellerangaben.
Persönlich habe ich mit flottester Hardware einen deutlichen Geschwindigkeitseinbruch mit AES-256bit, Lesen ohne Veracrypt 500MB/s -> mit VC 310MB/s, Schreiben mit VC 520MB/s -> mit VC 340MB/s. Die Zugriffszeiten sind noch schlechter, aber das alles ist nicht spürbar. (Mounir, der VC Entwickler, will auch an der Performance arbeiten, man sieht ja an Diskcryptor zB dass es besser geht)
Eine SSD mit der verschlüsselten Geschwindigkeit ist einer HDD einfach haushoch überlegen, nicht nur ist sie immer noch ein vielfaches schneller, sondern man kann Sachen GLEICHZEITIG machen und hat keine Einbußen in der Geschwindigkeit, 5 VMs am Laufen, browsen und Dateien von C auf D kopieren? Kein Problem!
Solange also die CPU flott ist, sollte man HDDs wie SSDs alle verschlüsseln.
Das ist aber halb so wild, da man 10 Prozent SSD Platz unpartitioniert und unverschlüsselt lassen kann (sicherheitstechnisch kein Problem!), moderne SSDs fast alle Überkapazitäten haben für genau den Fall, dass jemand die SSD 100 Prozent beschreibt und weil die Zellen bei Normalsterblichen ewig halten, sogar ein Vielfaches von den Herstellerangaben.
Persönlich habe ich mit flottester Hardware einen deutlichen Geschwindigkeitseinbruch mit AES-256bit, Lesen ohne Veracrypt 500MB/s -> mit VC 310MB/s, Schreiben mit VC 520MB/s -> mit VC 340MB/s. Die Zugriffszeiten sind noch schlechter, aber das alles ist nicht spürbar. (Mounir, der VC Entwickler, will auch an der Performance arbeiten, man sieht ja an Diskcryptor zB dass es besser geht)
Eine SSD mit der verschlüsselten Geschwindigkeit ist einer HDD einfach haushoch überlegen, nicht nur ist sie immer noch ein vielfaches schneller, sondern man kann Sachen GLEICHZEITIG machen und hat keine Einbußen in der Geschwindigkeit, 5 VMs am Laufen, browsen und Dateien von C auf D kopieren? Kein Problem!
Solange also die CPU flott ist, sollte man HDDs wie SSDs alle verschlüsseln.
Für normales arbeiten sind die 150-300 mb/s mit Verschlüsselung komplett ausreichend, je nachdem welche SSD in Betrieb ist.Ein moderner i5/i7 mit aes hardware support schafft eine Rate von 3.5GByte/s und das bei AES-256. Über 600MB/s lacht der nur.
Ich habe hier auch schon 1000Mbyte direkt in's Filesystem geschrieben und dafür 1.5s gebraucht. Und nein, die Daten standen nicht noch im Memory, sondern waren verschlüsselt auf der Platte. Schon flott, die neuen SSDs
Ich habe hier auch schon 1000Mbyte direkt in's Filesystem geschrieben und dafür 1.5s gebraucht. Und nein, die Daten standen nicht noch im Memory, sondern waren verschlüsselt auf der Platte. Schon flott, die neuen SSDs
Okay das ist geil. Mein Problem ist halt, dass ich nur die theoretischen Werte habe, mein Speicherplatz ist nur auf HDD - SSD ist immer dem OS vorbehalten. Aber schön zu hören, dass die Entwicklung so gut weitergeht.
BTW: Offtopic.... weißt du ob man ohne Probleme ein RAID5 mit 12 oder 16GB Verschlüsseln kann? Weil ab 2,2TB benötigt man ja GPT und kein MBR. TC verlang zumindestens bei der OS-Verschlüsselung MBR, wie sieht es mit der normalen Verschlüsselung aus? Egal?
BTW: Offtopic.... weißt du ob man ohne Probleme ein RAID5 mit 12 oder 16GB Verschlüsseln kann? Weil ab 2,2TB benötigt man ja GPT und kein MBR. TC verlang zumindestens bei der OS-Verschlüsselung MBR, wie sieht es mit der normalen Verschlüsselung aus? Egal?
Kann ich nichts zu sagen, da ich Linux benutze. Das Boot-FS ist nur 200MB groß, kann also auch auf einen USB-Stick.
Nach dem booten (egal mit welcher Partitiontable) macht der device mapper/Kernel das alles.
Bei 64 bit maschinen sind wir da bei 8 Exabyte max diskgröße. Dauert also noch ein paar Jahrzehnte.
aes ist ein block-cipher, da ist die maximale Zahl der Blöcke nur von diesem device mapper abhängig
Nach dem booten (egal mit welcher Partitiontable) macht der device mapper/Kernel das alles.
Bei 64 bit maschinen sind wir da bei 8 Exabyte max diskgröße. Dauert also noch ein paar Jahrzehnte.
aes ist ein block-cipher, da ist die maximale Zahl der Blöcke nur von diesem device mapper abhängig