Full Disc Encryption bei einer SSD... schlechte Idee? Wegen Thema freier Speicher, Cache, Trim, etc.

[drmaniac]

Servus,

Ich bin da nicht so tief im Thema. Ich weiß rudimentär, dass einige SSDs freien Speicher nutzen um schnelleren SLC Cache zu simulieren. Oder das es automatisiert TRIM-Funktionen gibt, dass sich einige SSDs "refreshen" nach einer Weile "Leerlauf" (wear leveling)? Und sicher noch viele andere Dinge, die ich derzeit nicht kenne oder einschätzen kann.

Deswegen meine Fragen:

- Wenn man eine SSD mit TLC Speicher verschlüsselt, z.B. mit VeraCrypt. Hat das Nachteile?

- Sollte man evtl einfach zwei Partitionen erstellen? z.B. eine mit 10% die man nicht nutzt und die zweite mit 90% die dann eben per FDE verschlüsselt ist?
(Braucht SLC-Cache oder TRIM einfach nur freien Speicher auf einer bestehenden Partition, oder würde es auch ausreichen die kleine Partition unformatiert zu lassen)

Ich bin mir sicher, hier gibt es genug Experten die dazu eine begründete Meinung haben

Vielen Dank!

LG


PS: Bitlocker möchte ich nicht nehmen, das würde das Problem evtl lösen, weil BL ja nur Dateiweise verschlüsselt? Aber ich da will ich eher nicht auf Microsoft vertrauen^^

 

[drmaniac]

Also die SSD ist noch unbenutzt und leer

Hab aber eben was interessantes von Very Crypt zum Wearleveling gelesen:

Spoiler: Text von Veracypt :)

Einige Speichergeräte (z. B. einige Solid-State-Laufwerke, einschließlich USB-Flash-Laufwerke) und einige Dateisysteme verwenden sogenannte Verschleißausgleichsmechanismen, um die Lebensdauer des Speichergeräts oder -mediums zu verlängern. Diese Mechanismen stellen sicher, dass selbst wenn eine Anwendung wiederholt Daten in denselben logischen Sektor schreibt, die Daten gleichmäßig auf das Medium verteilt werden (logische Sektoren werden verschiedenen physischen Sektoren neu zugeordnet). Daher können einem Angreifer mehrere "Versionen" eines einzelnen Sektors zur Verfügung stehen. Dies kann verschiedene Auswirkungen auf die Sicherheit haben. Wenn Sie beispielsweise ein Volume-Kennwort / eine Schlüsseldatei ändern, wird der Volume-Header unter normalen Bedingungen mit einer neu verschlüsselten Version des Headers überschrieben. Wenn sich das Volume jedoch auf einem Gerät befindet, das einen Verschleißausgleichsmechanismus verwendet, kann VeraCrypt nicht sicherstellen, dass der ältere Header wirklich überschrieben wird. Wenn ein Gegner den alten Volume-Header (der überschrieben werden sollte) auf dem Gerät gefunden hat, kann er ihn verwenden, um das Volume mit einem alten kompromittierten Kennwort (und / oder kompromittierten Schlüsseldateien, die zum Mounten des Volumes vor dem Volume-Header erforderlich waren) bereitzustellen wurde neu verschlüsselt). Aus Sicherheitsgründen empfehlen wir, dass VeraCrypt-Volumes nicht auf Geräten (oder in Dateisystemen) erstellt / gespeichert werden, die einen Verschleißausgleichsmechanismus verwenden (und dass VeraCrypt nicht zum Verschlüsseln von Teilen solcher Geräte oder Dateisysteme verwendet wird).

Wenn Sie sich gegen diese Empfehlung entscheiden und beabsichtigen, eine direkte Verschlüsselung auf einem Laufwerk zu verwenden, das Verschleißausgleichsmechanismen verwendet, stellen Sie sicher, dass die Partition / das Laufwerk keine vertraulichen Daten enthält, bevor Sie sie vollständig verschlüsseln (VeraCrypt kann keine zuverlässige Sicherheit gewährleisten In-Place-Verschlüsselung vorhandener Daten auf einem solchen Laufwerk (nachdem die Partition / das Laufwerk vollständig verschlüsselt wurde, werden alle neuen Daten, die darauf gespeichert werden, im laufenden Betrieb zuverlässig verschlüsselt). Dies umfasst die folgenden Vorsichtsmaßnahmen: Bevor Sie VeraCrypt ausführen, um die Authentifizierung vor dem Start einzurichten, deaktivieren Sie die Auslagerungsdateien und starten Sie das Betriebssystem neu (Sie können die Auslagerungsdateien aktivieren, nachdem die Systempartition / das Systemlaufwerk vollständig verschlüsselt wurde). Der Ruhezustand muss zwischen dem Zeitpunkt, zu dem Sie VeraCrypt starten, um die Authentifizierung vor dem Start einzurichten, und dem Zeitpunkt, zu dem die Systempartition / das Systemlaufwerk vollständig verschlüsselt wurde, verhindert werden. Beachten Sie jedoch, dass selbst wenn Sie diese Schritte ausführen, nicht garantiert werden kann, dass Sie Datenlecks verhindern und dass vertrauliche Daten auf dem Gerät sicher verschlüsselt werden. Weitere Informationen finden Sie in den Abschnitten Datenlecks, Auslagerungsdatei, Ruhezustand und Speicherauszugsdateien.

Wenn ich das so lese, wäre ein zulassen von WL ja eher schlecht. Beim zweiten Nachdenken: Falls kein Passwort kompromitiert wurde, wäre es ja auch nicht schlimm, wenn jemand den alten Volume Header auslesen könnte. Also aus Sicht Security/WL glaube ich wäre eine FDE also eher egal.

 

[JohnnyBGoode]

Falls die SSD immer nur mit einem aktuellen Windows verwendet wird, würde ich die TPM-freie Verschlüsselung mit BitLocker nur mit Kennwort empfehlen - ist performancemäßig wesentlich besser als VeraCrypt.

Die einzigen Schwachstellen, die bislang bei Bitlocker aufgefallen sind, sind wenn ich mich richtig erinnere Hardware- und Firmware-basierten Geschichten gewesen.

 

[Holt]

Die einzigen Schwachstellen, die bislang bei Bitlocker aufgefallen sind, sind wenn ich mich richtig erinnere Hardware- und Firmware-basierten Geschichten gewesen.

Du meinst wohl, dass Bitlocker auch die Opal2 Hardwareverschlüsselung entsprechender Laufwerke unterstützt? Dann hängt die Sicherheit zwar von der Sicherheit der Implementierung der Verschlüsselung des Laufwerks ab, aber dafür ist dies die einzige Möglichkeit die Daten ohne Performanceverlust zu verschlüsseln. Jede SW Verschlüsselung kostet Performance, die Daten müssen ja vor dem Schreiben erst verschlüsselt werden bevor sie an die SSD gehen und nach dem Lesen wieder entschlüsselt werden bevor sie an die Anwendung weitergereicht werden können. Dazu kommen dann ggf. noch Effekte bzw. der Art und Länge der Zugriffe, wenn eben lange Zugriffe in mehrere kürzere aufgeteilt werden um die Latenz zu verringern. Dann kommen zwar die ersten Daten schneller an, aber SSDs und gerade schnelle NVMe SSDs brauchen eben lange Zugriffe um ohne Schreib- und vor allem Leseraten zu erreichen.

Das ist auch der Grund warum man dann zwar eine SSD hat die z.B. mit 3,5GB/s lesen kann und eine Verschlüsselung bei der die CPU mit 10GB/s oder mehr entschlüsseln kann, am Ende aber vielleicht doch nur 1GB/s rauskommt. Es reicht eben nicht, dass die Geschwindigkeit mit der Ver- und Entschlüsselung erfolgen kann höher ist als die Schreib- bzw. Leserate der SSD um keine Flaschenhals zu sein, eine Bremse ist eine SW Verschlüsselung immer. Dazu können ggf. noch Probleme wie eben TRIM und dass die SSD sowieso aus Sicht des Controllers immer voll ist, weil die Verschlüsselung damit verhindern will, dass man ermitteln kann wo wirklich Daten stehen. Wenn die SSD aber (aus Sicht des Controllers, also ohne TRIM irgendwann bis auf unpartitionierte Bereiche) voll ist, dann hat sie meistens weniger Pseudo-SLC Schreibcache, dessen Größe ist ja heutzutage i.d.R. dynamisch und der Controller erzeugt mehr Write Amplification und kann nach dem Füllen des Pseudo-SLC Schreibcaches und der Free Area dann auch nicht mehr so schnell schreiben, weil vorher eben nicht so viel NAND gelöscht werden konnte.

 

[JohnnyBGoode]

Ja, dass die integrierte HW-Verschlüsselung eines Laufwerks der performanteste Weg ist, sollte jedem klar sein. Eine SW-Umsetzung, die sauber AES-NI unterstützt und deren Treiber gepflegt wird, ist aber aus meiner subjektiven Perspektive bei Desktop-Nutzung Nörgeln auf ausreichend hohem Niveau.

Nach TrueCrypt-, DiskCryptor- und VeraCrypt-Intervallen bin ich bei BitLocker (SW-only) für dauerhaft verbauten und VeraCrypt für Wechselspeicher gelandet.

Verwende FDE auch für das Systemlaufwerk (hier noch DiskCryptor) und nach längerer Zeit inkl. Windows-Updates hat MS doch mal bei einem Windows-Update etwas am Bootbereich verändert, was dazu führte, dass Windows nicht mehr booten konnte, bis man das Laufwerk zuvor dauerhaft etschlüsselt hatte.

 

[Holt]

Hier gibt es Benchmarks zu sehen. tldr: es gibt keinen nennenswerten Performance-Vorteil

Die für die Alltagsperformance entscheidenden 4k Werte fehlen, bei den seq. Werten mit 8 parallelen Zugriffen über je 1MB machen sich die zusätzlichen Latenzen durch das Ver- und Entschlüsseln natürlich praktisch nicht bemerkbar, aber wann hat man im Alltag solche Zugriffe? Eben, nie, außer man kopiert mit Robocopy und den entsprechenden Parametern.

Damit ist die pauschale Aussage es gäabe "keinen nennenswerten Performance-Vorteil" so aus dem Test nicht abzuleiten, sondern gilt nur für den Fall der hier einzig und alleine gebencht wurde, nämlich 8 parallele Zugriffe über ja 1MB. Wäre wenigstens der Test darunter mit nur einem 1MB Zugriff gemacht worden, so hätte man vielleicht schon mehr Unterschiede gesehen und bei 4k QD1 dürfte es mit Sicherheit deutlich Unterschiede geben.

 

[Holt]

Das es auch bei 4k QD1 keine Unterschiede gab, kann nur angehen, wenn der Controller der SSD genauso viel zusätzliche Zeit zum Ver- und Entpacken benötigt wie die CPU des Rechners, womit der Wert dann aber auch mit HW Verschlüsselung schlechter als ohne Verschlüsselung sein muss.

 

[askling]

So viel wie man an Apple kritisieren kann, bei der Verschlüsselung haben sie es außer für absolute Hochsicherheit gut gelöst. Die Verschlüsselung übernimmt der eigene Sicherheitschip, damit ist man unabhängig von den Herstellern aber verliert keine Performance. Zumindest ist das mein Wissensstand. Früher hat der Mac auch über Software verschlüsselt.

Verschlüsselung ist unter Windows wirklich ein rotes Tuch, ich möchte gerne Default alles verschlüsseln, aber mir machen die Seiteneffekte sorgen, gerade niedrigere 4k Performance und Aufwand von Backups per Diskimage. Da gibt es dann wieder viele Fehlermöglichkeiten, die man ja beim Backup eigentlich nicht haben möchte.

Um die Verschlüsslung "unsichtbar" zu machen, würde ich für den Hausgebrauch ja sogar eDrive nutzen, trotz Sicherheits-Problematik (besser als nichts), aber eDrive scheint kompliziert und Fehleranfällig beim Einrichten zu sein, was man so ließt und ich traue mich nicht das einfach mal zu Probieren (man benötigt ja einen Psid Revert um es wieder zu entfernen, da hatte ich schon mal Probleme).

Beim Laptop der mitgenommen wird gibt es eigentlich keine Wahl, da ist Verschlüsselung Pflicht.

Ich bin mir immer noch unschlüssig, ob ich Bitlocker auf meinem Desktop einsetze und wenn wie (eDrive oder Software), aber auch Einbruchsdiebstahl gibt es immer wieder, daher hätte ich das schon gerne. Daher ist es immer interessant von aktuelle Erfahrungen mit Bitlocker zu lesen. Daher mal ein generelles Danke für deine ganzen Berichte Bob

 

[Holt]

Beim Laptop der mitgenommen wird gibt es eigentlich keine Wahl, da ist Verschlüsselung Pflicht.

Ja, aber beim Desktop Zuhause oder der Backupplatte im Schrank sollte man schon überlegen ob die Verschlüsselung Sinn macht, denn Verschlüsselung schützt nicht davon Online ausspioniert zu werden, die Schadsoftware kann ja genauso wie der User auf die Daten zugreifen, sonst nur in dem Fall das der Angreifer physikalischen Zugriff auf den Datenträger bekommt. Wie groß diese Gefahr zuhause ist, muss ja jeder für sich entscheiden.

 

[askling]

Ja, wie gesagt, ich sehe da als Gefahr nur Einbruchdiebstahl, aber immerhin ist mir das schon einmal im Leben passiert . Gerade wenn man länger weg ist. Aber dazu muss dann auch jemand noch eine Affinität haben etwas mit den Daten zu machen,

Ich halte die Gefahr in der Praxis auch für zu gering, als das ich mich bisher dazu durchringen konnte. Wobei meine täglichen Backups tatsächlich schon verschlüsselt sind (Diskimage, direkt beim Anlegen einfach per AES im Tool) Perspektivisch möchte ich aber auch auf dem Desktop nicht drauf verzichten, es ist einfach ein bessere Gefühl und ich bin da auf die Mac-User schon sehr neidisch wie unsichtbar das Arbeitet und einzurichten ist. Wirklich schade das eDrive so gefailed ist, was Verwaltung und z.T. Implementierung angeht.

 

[Holt]

Einbrecher nehmen vor allem Dinge mit die klein und trotzdem wertvoll sind, also eher Notebooks als große Desktopcomputer. Aber wer weiß, früher wurden ganze Autos geklaut, heute nur noch die Kats und wenn die HDD und SSD Preise weiter steigen, bauen sie vielleicht auch die HDDs und SSDs auf den Desktops aus um sie zu klauen.

 

[Uhrzeit]

Ich glaub "softwarebasiert" sollte man eher erzählen, wenn die Crypto kein AES-NI nutz, also das in der CPU verbaute Stück Hardware. Ist auch nicht wirklich anders als wenn das die Firmware dafür den entsprechenden Teil des Controllers nutzt...

Da die CPUs mit der Zeit schneller werden, ist auch AES-NI mit der Zeit schneller geworden. Vera macht schon beim 4.5Ghz 2500k um die 4GB/s. Das ist zwar schön und richtig, daß sich das wer ab und zu genauer anschaut, aber die Erkenntnis selbst war für mich auch kein Augenöffner.

 

[askling]

@*******

Aber eDrive einzuschalten und Bitlocker dazu zu bringen es zu nutzen, ist doch alleine schon kompliziert oder sehe ich das falsch? Soweit ich weiß geht das nicht direkt im Bitlocker Wizzard, sondern man muss diverse Einstellung in Windows richtig setzen. Es wird oft dazu geraten das komplette OS neu zu installieren dafür. Per Default geht Bitlocker doch jetzt auf Software. Und wenn man es deaktivieren will muss man erst einen PSID Reset durchführen, was wohl auch nicht immer Problemlos klappt. Daher ist einfach mal probieren sehr unangenehm ohne "Spielsystem".

Was mir gerade einfällt. Gab es nicht auch mal die Möglichkeit über OPAL ein UEFI Passwort zu setzen und damit die Verschlüsselung für das OS komplett unsichtbar zu halten?

 

[Holt]

Verstehe nicht, worauf Du hinaus willst. Hardwarebasierte Verschlüsselung ist doch identisch zu unverschlüsselt auf dem jeweiligen Drive, da es eh im Controller passiert.

Wenn dem so ist, dann kann eine softwarebasierte Verschlüsselung nie so schnell sein wie eine hardwarebasierte Verschlüsselung im Controller! Punkt aus, denn die softwarebasierte Verschlüsselung hat immer einen zusätzlichen Layer über den die Daten gehen müssen um von der CPU des Rechners ver- bzw- entschlüsselt zu werden und dies bedeutet unausweichlich immer eine Verzögerung die man zumindest bei 4k QD1 auch deutlich erkennen muss. Bei 8 parallelen und je 1MB lange Zugriffen kann diese durchaus in der Messtoleranz untergehen, aber bei 4k QD1 (bzw. Q1T1) muss sie sich bemerkbar machen. Du hattest aber geschrieben:

@Holt Ich hatte auch alles andere gebencht, es gab keine Unterschiede außer, dass bei allen anderen auch keine CPU-Last zu erkennen war,

Die Unterschiede in der CPU Last zeigen ja, dass die softwarebasierte Verschlüsselung auch wirklich eine solche war und nicht wie es bei Bitlocker möglich ist, eine die die hardbasierte Verschlüsselung, also die im SSD Controller, aktiviert. Damit bleiben als Erklärung nur zwei Dinge:
1.) Die Aussage es auch bei 4k QD1 (vor allem Lesend, schreibend ist wegen der Pufferung immer problematisch) keine Unterschiede stimmt so nicht bzw. wurde zu grob geschaut, Belege dafür fehlen ja auch.
2.) Die Aussage das die Performance der SSD bei aktiver hardwarebasierte Verschlüsselung (OPAL2) identisch zu unverschlüsselt sein soll, stimmt nicht, denn natürlich gibt es auch innerhalb der SSD eine Entschlüsslung und auch diese könnte Zeit kosten, ob dem so ist weiß ich nicht, vielleicht kann man dies auch so mit der ECC verknüpfen das es keine Verzögerung bedeutet oder es ist in dem Controller per zusätzlicher HW gelöst. Das müsste man im Zweifelsfall also auch mal benchen.

Ich selbst hatte hier im Luxx lange argumentiert, dass die Softwareverschlüsselung immer langsamer ist und auch entsprechende Benches gemacht, die das belegt haben und viel diskutiert und gegengehalten. Aber als ich mal mein System wieder neu aufgesetzt hatte, ließ sich das so nicht mehr halten.

Was ich bezweifel, eine Ver- und Entschlüsselung die komplett ohne Erhöhung der Latenz möglich sein soll, gibt mit CPUs nicht, egal ob diese die AES-NI Befehlen beschleunigt wird oder nicht, da es immer ein zusätzlicher ist durch den die Daten müssen und die bedeutet immer eine Verzögerung, auch abhängig davon wie groß die Blöcke sind, bei SATA werden ja normalerweise bis 8192 Byte pro Datenpaket (bei AHCI FIS genannt) übertragen, während PCIe mit sehr viel kleineren Datengrößen pro Paket arbeitet und wie schnell die CPU diese Ver- und Entschlüsseln kann.

Man kann hier allenfalls argumentieren ob die Unterschiede ins Gewicht fallen oder nicht, aber wenn auch man meint sie wären unbedeutend, so ist dies nicht das Gleiche wie kein Unterschied.

 

[Holt]

Ohne Beweis glaube ich nichts, was der Logik widerspricht!

 

[Holt]

Ein Ansatz wäre für mich, dass die Daten vermutlich eh in den RAM und an die CPU geschickt werden müssen, dabei kann diese jene auch gleich verschlüsseln, im Vergleich zum Zugriff auf den NAND-Speicher spielt das dann einfach keine Rolle mehr.

Soll das RAM die Daten entschlüsseln? Nein, kann es nicht und die NAND entschlüsseln auch keine Daten, sondern entweder die CPU des Rechner oder der Controller der SSD und in beiden Fällen werden diese Daten dann im RAM (beim Controller entweder im internen SRAM oder dem DRAM Cache) liegen und dann entschlüsselt. Der Ansatz erklärt nicht, wieso dies ohne jegliche Verzögerung machbar sein sollte.

 

[Uhrzeit]

Geht es hier jetzt um den Unglauben daran, daß AES-NI auf dem Kontroller oder in der CPU, mehrfach schneller Tun kann als das Interface des Datenträgers nach außen, und man damit sein Wirken nicht bemerken kann?
Oder hab ich was falsch verstanden?

 

[Holt]

Auch wenn die CPU mit AES-NI einen viel höheren Durchsatz schafft als die SSD Daten lesen oder schreiben kann, so ist es immer noch ein zusätzlicher Layer im Protokoll in dem die Daten eben ver- bzw- entschlüsselt werden müssen und natürlich können sie erst an den nächsten Layer weitergereicht werden, nachdem dies für den jeweiligen Block vollständig erfolgt ist, was immer eine Verzögerung bedeutet. Wie groß diese ist, hängt auch davon ab wie groß die Blöcke sind, aber wenn man ganz kleine Blöcke nimmt, dann kommen die ersten Daten zwar schneller an, aber gerade beim Schreiben müsste man entweder viele kleine Schreibzugriffe, eben von der Länge dieser Blöcke machen oder doch warten bis genug Daten verschlüsselt wurden, bevor man diese dann mit einem längeren und damit schnelleren Schreibzugriff schreiben kann. Da Zugriffe normalerweise mindestens 4k lang sind, wären Blöcke die kleiner als 4k sind, wenig sinnvoll und damit muss diese Zeit bei 4k QD1 Lesend sichtbar sein, vielleicht nicht sehr deutlich, aber genau gleich kann das Ergebnis nicht sein.

Wie die Controller der SSD die HW Ent- und Verschlüsselung machen, weiß ich nicht, die Hersteller verraten dies nicht, aber beim Schreiben puffern sie die Daten sowieso und damit fällt die Zeit dafür sowieso nicht direkt auf und dann ist da noch die ECC, die muss beim Schreiben gebildet und beim Lesen geprüft werden, wenn die Verschlüsselung in dem ECC Algorithmus integriert ist, dann wäre dies wirklich ohne nennenswerte Verzögerung machbar, da der Controllerr ja sowieso über die Daten gehen muss, bevor er sie weiterreichen kann.

 

[Uhrzeit]

Bevor wieder alles im Schwafelniagara völlig verwäscht:

******* hat festgestellt, daß mit seiner Hardware (und VeraCrypt?) das AES-NI seines Systems genauso schnell ist wie wenn er AES über die Kontroller seiner Datenträger macht. Kannst du das verstehen?

Zu überlegen wo genau das Nadelohr ist, da der Kontroller sich nicht (mehr) absetzen kann oder ob es überhaupt ein Nadelohr gibt, könnte zwar in der Tat interessant sein - mit Leuten welche die Fähigkeit besitzen sich differenziert auf andere einzulassen - ändert aber trotzdem überhaupt rein garnichts an seinen Benches.

Und auch wenn ich an paar wenigen Stellen hier im Forum mit ******* bereits nicht gleich einer Meinung war, wäre das letzte was mir einfallen würde, daß er seine Messmethodik verhaut. Da ist er nämlich keineswegs ein trübes Licht.

Checkov, my Friend?

 

[Holt]

******* hat festgestellt, daß mit seiner Hardware (und VeraCrypt?) das AES-NI seines Systems genauso schnell ist wie wenn er AES über die Kontroller seiner Datenträger macht.
Kannst du das verstehen?

Da er auf jegliche Belege verzichtet hat, muss ich ihm das nicht glauben und glaube es ihm auch nicht. Damit ist das Thema für mich auch durch, soll jeder selbst entscheiden was er macht und selbst benchen wie sich die Verschlüsselung jeweils auf die Performance auswirkt, vor allem auf die 4k QD1 Lesend, denn da sieht man es am Besten.

Zu überlegen wo genau das Nadelohr ist

Es geht nicht darum wo das Nedelöhr ist, sondern darum das es eben einen weiteren Layer in der Verarbeitung gibt der zusätzliche Latenz bedeutet, wie ich schon geschrieben hatte.

ändert aber trotzdem überhaupt rein garnichts an seine Benches.

Von denen er aber die 4k Q1T1 Werte gar nicht geezigt hat und bei dem was CDM als sequentiell misst, ist der Effekt mit Sicherheit zu vernachlässigen, aber dies hatte ich auch alles schon geschrieben.

 

[Uhrzeit]

An welcher Stelle schreibst du etwas woraufhin ich dir glauben sollte - da Glaubensfragen grad irgendwie ein Thema sind - daß ein Kontroller bei AES schnell genug ist um bob.digs AES-NI zu schlagen? (auch samt dem zusätzlichen Layer).

p.s.:
Rein zu Testzwecken gabs/gibts ja noch DiskCryptor statt VeraCrypt, was sich gar auf SSDs extra spezialisiert hat (und meist weiterhin noch leistungsfähiger ist als VeraCrypt).

edit:
Ich hab schon sehr wohl "an seinen Benches" und nicht "an seine Benches" geschrieben (?)

 

[Holt]

Jeder muss selbst entscheiden was und wem er glaubt und ich packe dich besser auf meine IL, weil es sinnfrei ist mit dir zu diskutieren, man dreht sich immer nur im Kreis und Dinge gehen durcheinander wie "Kontroller bei AES", denn es ging um CPUs mit AES Befehlserweiterung.

 

[Uhrzeit]

Es ging um AES über den Kontroller ("Hardware") und es ging um AES über die CPU ("Software"). Ja, Dinge gehen durcheinander. Die Frage wer sie durcheinander bringt ist aber eine andere...

 

[akte.x]

Ich hätte auch eine Frage zur Verschlüsselung.
Kann ich eine SSD mit einem verschlüsselten Container in der Größe der SSD ohne Einbußen nutzen oder sollte ich den Container nicht größer als z.B. 90 % der SSD-Größe erstellen?

 

[akte.x]

@akte.x Wenn der Container gleich die volle Größe hat, dann geht kein TRIM etc, also weniger performant. Wenn nicht die volle Größe zum Anfang, dann wird es mit der Zeit weniger, je nach Füllstand. Und meist wird belegter Platz nicht von alleine zurück gegeben. Performanter wäre also immer eine Partitions-/Device-Verschlüsselung und keine Container. Insbesondere wenn mit der Zeit viel geschrieben wird.

Danke.

 

[Doktor]

Ich klinge mich noch mal in den Thread ein.
Ich konnte es nicht rauslesen: macht es einen Unterschied ob ich SLC, MLC oder TLC verwende (bei der Verwendung von Bitlocker)?

 

[Doktor]

Also die Chips der SSDs sagen nur etwas über Schnelligkeit, wie oft man sie überschreiben kann etc.
Fasse ich das richtig zusammen: man kann bedenkenlos Bitlocker bei SSDs verwenden (wann man einen USA Unternehmen Vertrauen mag)?