Hardwareverschlüsselung seitens der SSH ist nicht sicher. Besonders wenn man auch deshalb verschlüsselt, um bei einem Defekt die Garantie der SSD in Anspruch nehmen zu können, ist dies keine Option.
Allerdings kann man die Hardwareunterstützung der CPU nutzen, Stichwort AES-NI. Damit und einer Multicore-CPU ist die Verschlüsselung im Normalbetrieb eigentlich nicht wahrnehmbar. Nur die Verzögerung beim Booten merkt man eben, da entsperren Zeit kosten muss um die Anzahl der Versuche zu limitieren. Außerdem wartet man alleine schon 2 Sekunden auf das USB-Backend, um einen Key von USB einlesen zu können. D.h. in der Zeit hast du schon durchgebootet. Irgend einen Tod muss man leider sterben.
Gute Argumente. Seit Snowden und der Einmischung der US-Regierung in von ANSI und NIST vorgeschlagenen Standards ist auch möglich, dass Hersteller von Verschlüsselungstechnologie gezwungen werden, kryptografische Hintertüren einzubauen, aber ohne dies publik machen zu dürfen.
Meine generelle Sorge bei der Verschlüsselung ganzer Partitionen oder Platten sind Defekte. Während bei Lesefehlern in unverschlüsselten Bereichen oft eine Rettung der meisten Blöcke möglich ist (sogar eine heuristische »Schätzung« der defekten Bits seitens der Platten-Firmware und dd), kann bei Block-Level-Verschlüsselung im Extremfall ein falsches Bit dazu führen, dass gar nix mehr lesbar ist, ähnlich wie bei proprietärer und zu »cleverer« RAID-Hardware, wo im Fehlerfall uninterpretierbarer Bit-Salat übrig bleibt.
Da bleibe ich lieber noch eine Weile bei Dateiverschlüsselung der paar Files, die mir echt wichtig sind. Das meiste auf der Platte sind in meinem Fall Steam-Spiele und die Standardinstallation aus openSUSE-Paketen — kein Anlass hier zum Verschlüsseln, nur zum gelegentlichen Verifizieren der Checksummen. Zusammen mit bewährten Dateisystemen (ext4, XFS) und robusten Backup-Strategien sollte das doch für fast alle Fälle ausreichen.
Ich war mal ein Jahr als Externer bei der Datev eG in Nürnberg, wo generell alle mobilen Geräte verschlüsselt sein müssen, habe ab und zu mitbekommen, was da alles schief geht und davon gelernt — aber wie Du schon so treffend schriebst: »Irgend einen Tod muss man leider sterben.«
Da bin ich ganz bei dir, Verschlüsselung erhöht die Komplexität, was immer dann wenn es darauf ankommt, Abläufe teils massiv verkompliziert oder gar unmöglich macht. Wer schon einmal eine Festplatte hatte, welche langsam anfing unkorrigierbare Blöcke zu melden (bekommt man dank SMART-Monitoring rechtzeitig mit, kann ich nur empfehlen), der wird zu schätzen wissen, wenn er über Low-Level Tools feststellen kann, in welchen Dateien sich die defekten Blöcke befinden, um diese gezielt ersetzen zu können. Da kann jeder weitere Layer an Komplexität schnell einer zu viel sein.
Andererseits dürften moderne SSDs ein ganz anderes Fehlerverhalten haben und ein gutes Backup ist ohnehin durch nichts zu ersetzen. Im Problemfall wird einem die höhere Komplexität aber sicherlich nicht von Vorteil sein.
Hardwareverschlüsselung seitens der SSH ist nicht sicher. Besonders wenn man auch deshalb verschlüsselt, um bei einem Defekt die Garantie der SSD in Anspruch nehmen zu können, ist dies keine Option.
Allerdings kann man die Hardwareunterstützung der CPU nutzen, Stichwort AES-NI. Damit und einer Multicore-CPU ist die Verschlüsselung im Normalbetrieb eigentlich nicht wahrnehmbar. Nur die Verzögerung beim Booten merkt man eben, da entsperren Zeit kosten muss um die Anzahl der Versuche zu limitieren. Außerdem wartet man alleine schon 2 Sekunden auf das USB-Backend, um einen Key von USB einlesen zu können. D.h. in der Zeit hast du schon durchgebootet. Irgend einen Tod muss man leider sterben.
Gute Argumente. Seit Snowden und der Einmischung der US-Regierung in von ANSI und NIST vorgeschlagenen Standards ist auch möglich, dass Hersteller von Verschlüsselungstechnologie gezwungen werden, kryptografische Hintertüren einzubauen, aber ohne dies publik machen zu dürfen.
Meine generelle Sorge bei der Verschlüsselung ganzer Partitionen oder Platten sind Defekte. Während bei Lesefehlern in unverschlüsselten Bereichen oft eine Rettung der meisten Blöcke möglich ist (sogar eine heuristische »Schätzung« der defekten Bits seitens der Platten-Firmware und dd), kann bei Block-Level-Verschlüsselung im Extremfall ein falsches Bit dazu führen, dass gar nix mehr lesbar ist, ähnlich wie bei proprietärer und zu »cleverer« RAID-Hardware, wo im Fehlerfall uninterpretierbarer Bit-Salat übrig bleibt.
Da bleibe ich lieber noch eine Weile bei Dateiverschlüsselung der paar Files, die mir echt wichtig sind. Das meiste auf der Platte sind in meinem Fall Steam-Spiele und die Standardinstallation aus openSUSE-Paketen — kein Anlass hier zum Verschlüsseln, nur zum gelegentlichen Verifizieren der Checksummen. Zusammen mit bewährten Dateisystemen (ext4, XFS) und robusten Backup-Strategien sollte das doch für fast alle Fälle ausreichen.
Ich war mal ein Jahr als Externer bei der Datev eG in Nürnberg, wo generell alle mobilen Geräte verschlüsselt sein müssen, habe ab und zu mitbekommen, was da alles schief geht und davon gelernt — aber wie Du schon so treffend schriebst: »Irgend einen Tod muss man leider sterben.«
Da bin ich ganz bei dir, Verschlüsselung erhöht die Komplexität, was immer dann wenn es darauf ankommt, Abläufe teils massiv verkompliziert oder gar unmöglich macht. Wer schon einmal eine Festplatte hatte, welche langsam anfing unkorrigierbare Blöcke zu melden (bekommt man dank SMART-Monitoring rechtzeitig mit, kann ich nur empfehlen), der wird zu schätzen wissen, wenn er über Low-Level Tools feststellen kann, in welchen Dateien sich die defekten Blöcke befinden, um diese gezielt ersetzen zu können. Da kann jeder weitere Layer an Komplexität schnell einer zu viel sein.
Andererseits dürften moderne SSDs ein ganz anderes Fehlerverhalten haben und ein gutes Backup ist ohnehin durch nichts zu ersetzen. Im Problemfall wird einem die höhere Komplexität aber sicherlich nicht von Vorteil sein.