cartridge_case
Fleet Admiral
- Registriert
- Feb. 2009
- Beiträge
- 35.712
Wollte ja nur zeigen, dass die Aussage dann so erstmal falsch war.Evil E-Lex schrieb:
Wie Daten unwiederherstellbar löschen?
- Ersteller ---Daniel---
- Erstellt am
Wobei man doch beachten muß, daß jeder Hersteller es etwas anders macht, es gibt auch noch Sanitize Instant Erase (SIE), sieheNilson schrieb:
https://www.computerbase.de/forum/t...ws-zuruecksetzen.2191456/page-2#post-29302561
Hast du mal gecheckt wie strikt der NVMe Standard da vorschreibt was die jeweiligen Optionen liefern müssen?
Ich habe es noch nicht nachgeschlagen, aber würde jetzt anhand der Namen erwarten, dass das relativ solide definiert ist. Und man sollte vermutlich nur SSDs mit Cryptographic Erase kaufen. Und das das immer das erwartete mit der dauerhaften Verschlüsselung machen sollte. Und nur Secure Erase ist schwächer. Und "Format" vermutlich am schwächsten und eigentlich nur taugt, das Mapping der SSD auf Werkszustand zu setzen (was bei Benchmarks gemacht wird um eventuell im Hintergrund nur langsam passierende Dinge wie ein verzögertes Trimmen etc. irrelevant zu machen und auch die Performance wieder zurück zu setzen).
Edit:
und ja der NVMe Standard schreibt vor was dahinter zu stecken hat. Format ist quasi der alte Befehl. Sanitize ist neuer und mehr Deluxe und sieht zB auch vor, dass man auditen kann, was herauskommt (auf Wunsch und evtl mit extra Kosten in Lebensdauer) bei einem Sanitize und das es auch Caches und Logs löschen muss, wenn diese User Daten beschreiben. Oder Reserve Speicher (wobei Secure Erase das schlichtweg auch per Definition abdeckt). And es stellt sicher, dass einmal begonnen, der Befehl nur fertig wird, wenn er seinen Job auch komplett gemacht hat. Auch bei Ausfall dazwischen.
Aber wenn das Gerät Cryptographic Erase/Format hat und der am Stück durchgelaufen ist, sollte das gut genug sein, solange man nicht Gesetze und Richtlinien zum Löschen und Nachweisen des Löschen zu befolgen hat. Und beide Formen von Crypto Erase erfordern dass die Nutzerdaten immer verschlüsselt gespeichert werden und dass der Schlüssel weggeworfen wird. Während die anderen Formen meist mehr Freiheiten haben (von einfach das gleiche wie Secure Erase, Überschreiben. Oder im Fall von reinem Format sogar nur das Unmappen von allen Blöcken, so dass die SSD sie einem Host nicht mehr herausgibt, aber nichts über die Daten im physikalischen Speicher vorschreibt)
Ich habe es noch nicht nachgeschlagen, aber würde jetzt anhand der Namen erwarten, dass das relativ solide definiert ist. Und man sollte vermutlich nur SSDs mit Cryptographic Erase kaufen. Und das das immer das erwartete mit der dauerhaften Verschlüsselung machen sollte. Und nur Secure Erase ist schwächer. Und "Format" vermutlich am schwächsten und eigentlich nur taugt, das Mapping der SSD auf Werkszustand zu setzen (was bei Benchmarks gemacht wird um eventuell im Hintergrund nur langsam passierende Dinge wie ein verzögertes Trimmen etc. irrelevant zu machen und auch die Performance wieder zurück zu setzen).
Edit:
und ja der NVMe Standard schreibt vor was dahinter zu stecken hat. Format ist quasi der alte Befehl. Sanitize ist neuer und mehr Deluxe und sieht zB auch vor, dass man auditen kann, was herauskommt (auf Wunsch und evtl mit extra Kosten in Lebensdauer) bei einem Sanitize und das es auch Caches und Logs löschen muss, wenn diese User Daten beschreiben. Oder Reserve Speicher (wobei Secure Erase das schlichtweg auch per Definition abdeckt). And es stellt sicher, dass einmal begonnen, der Befehl nur fertig wird, wenn er seinen Job auch komplett gemacht hat. Auch bei Ausfall dazwischen.
Aber wenn das Gerät Cryptographic Erase/Format hat und der am Stück durchgelaufen ist, sollte das gut genug sein, solange man nicht Gesetze und Richtlinien zum Löschen und Nachweisen des Löschen zu befolgen hat. Und beide Formen von Crypto Erase erfordern dass die Nutzerdaten immer verschlüsselt gespeichert werden und dass der Schlüssel weggeworfen wird. Während die anderen Formen meist mehr Freiheiten haben (von einfach das gleiche wie Secure Erase, Überschreiben. Oder im Fall von reinem Format sogar nur das Unmappen von allen Blöcken, so dass die SSD sie einem Host nicht mehr herausgibt, aber nichts über die Daten im physikalischen Speicher vorschreibt)
Zuletzt bearbeitet:
Hast du ein Businessnotebook aus den letzten Jahren gesehen in dem keine NVMe drin ist? In irgendeinem Billo Teil findest du vllt noch SATA SSDs. Und in richtig schweren Geräten vllt noch 2.5" Slots. Aber das war es dann auch schon. Und der Fortschritt hat bei SATA schon länger aufgehört, während es in der NVMe Welt viele Ansätze gibt, wie man zB billigere SSDs bauen kann, die über ihre Hardware Limits gut hinwegtäuschen können. Das gibt es mit SATA nicht so. Und im M.2 Format ist der Platz auch gleich und SATA hat keine Kapazitätsvorteile gegenüber dem NVMe.nutrix schrieb:
Wie gesagt, bis der TS hier keine Aussage über die Geräte selbst oder die verwendeten Datenträger macht, kann ich hierzu weiter nichts sagen, es wäre reine Spekulation.
Ergänzung ()
Ich hab tatsächlich noch welche mit M.2 SATA, weil günstig, erlebt.Ray519 schrieb:
@nutrix ?
Die Idee ist, wenn du ein neues Laufwerk bekommst, noch nie relevante Daten von dir drauf gewesen, dann braucht die Vollverschlüsselung ungenutzte Bereiche des Datenträgers nicht verschlüsseln (ist auch eine Option nach der Windows fragt). Instant auch für Festplatten. Genau wie SSDs das auch machen, wenn sie intern verschlüsseln. Auch bei einer SSD braucht es Zeit den gesamten Speicherplatz zu verschlüsseln und wäre verschwenderisch zu machen, wenn du noch nie unverschlüsselte Daten auf dem Laufwerk hattest.
Und selbst bei HDDs: um die eigenen Daten restlos zu löschen muss man alles einmal überschreiben. Um das Gerät voll zu verschlüsseln muss man einmal alles überschreiben. Dh. man zieht die Zeit die das Dauert nur vor (wenn man es auf einem randvollen Laufwerk oder erst nachträglich macht).
Und dann sind die Daten aber auch sicher, wenn die Festplatte es nicht überlebt, alle Daten einmal zu überschreiben oder dabei Fehler wirft. Was durchaus sein kann, wenn man die Festplatten wegen Alter entsorgen möchte.
Die Idee ist, wenn du ein neues Laufwerk bekommst, noch nie relevante Daten von dir drauf gewesen, dann braucht die Vollverschlüsselung ungenutzte Bereiche des Datenträgers nicht verschlüsseln (ist auch eine Option nach der Windows fragt). Instant auch für Festplatten. Genau wie SSDs das auch machen, wenn sie intern verschlüsseln. Auch bei einer SSD braucht es Zeit den gesamten Speicherplatz zu verschlüsseln und wäre verschwenderisch zu machen, wenn du noch nie unverschlüsselte Daten auf dem Laufwerk hattest.
Und selbst bei HDDs: um die eigenen Daten restlos zu löschen muss man alles einmal überschreiben. Um das Gerät voll zu verschlüsseln muss man einmal alles überschreiben. Dh. man zieht die Zeit die das Dauert nur vor (wenn man es auf einem randvollen Laufwerk oder erst nachträglich macht).
Und dann sind die Daten aber auch sicher, wenn die Festplatte es nicht überlebt, alle Daten einmal zu überschreiben oder dabei Fehler wirft. Was durchaus sein kann, wenn man die Festplatten wegen Alter entsorgen möchte.
Wenn du geschrieben hättest, "jetzt ist es aber zu spät für mich, weil alles nachträglich zu verschlüsseln habe ich keine Lust dazu", dann hätte ich auch nichts dazu zu sagen. So liest es sich für mich zumindest als hättest du foofoobar's Aussage nicht verstanden und würdest anderen Forumlesern davon abraten Festplatten zu verschlüsseln, weil sie "groß" sind.
Und das lese ich jetzt nicht als Scherz, der jedem so offensichtlich ist, das niemand es ernst nehmen würde...
Und was habe ich sonst noch hier geschrieben, das eine Kritik an einer Aussage von dir war?
Und das lese ich jetzt nicht als Scherz, der jedem so offensichtlich ist, das niemand es ernst nehmen würde...
Und was habe ich sonst noch hier geschrieben, das eine Kritik an einer Aussage von dir war?
Ich habs schon verstanden, keine Sorge, ich mach das ja schon bestimmt länger als die meisten hier. 🙂
Es kann jeder entscheiden, wie er will. Aber es hat nun mal alles seine Vor- und Nachteile. Wie gesagt, Festplatten verschlüsseln dauert, und es geht auch auf die Übertragungsperformance. Bei SSDs und NVMes ist das wenig dramatisch, zudem die Verschlüsselung per Controller nichts an Leistung kostet. Bei Festplatten dank Mechanik eben schon. Daher, ich würde eine verschlüsselte HDD als reines Backupmedium - wo es auf die Übertragungsrate ankommt - bei großen Datenmengen nicht verwenden wollen. Ansonsten würde ich heute alles unter 4 TB eh nicht mehr mit HDDs ausstatten.
Es kann jeder entscheiden, wie er will. Aber es hat nun mal alles seine Vor- und Nachteile. Wie gesagt, Festplatten verschlüsseln dauert, und es geht auch auf die Übertragungsperformance. Bei SSDs und NVMes ist das wenig dramatisch, zudem die Verschlüsselung per Controller nichts an Leistung kostet. Bei Festplatten dank Mechanik eben schon. Daher, ich würde eine verschlüsselte HDD als reines Backupmedium - wo es auf die Übertragungsrate ankommt - bei großen Datenmengen nicht verwenden wollen. Ansonsten würde ich heute alles unter 4 TB eh nicht mehr mit HDDs ausstatten.
Ja_Ge
Commodore
- Registriert
- März 2019
- Beiträge
- 4.819
Verschlüsselung kostet aber zusätzlich CPU Leistung die "0-Beschreibung" nicht braucht.
.
Hoffentlich lagen in den Bereichen nicht irgendwann mal unverschlüsselte Daten, die sind ja nach mancher Logik sonst wieder herstellbar wenn die Nullen nicht mit Nullen überschrieben werdenRay519 schrieb:
.@Ja_Ge du musst nur die Sätze vor deinem Zitat lesen...
Aber jetzt bin ich gespannt, was die Mechanik damit zu tun hat. Eklär mal.
Und da wir leider keine vollständigen Cryptokoprozessoren in CPUs haben, werden für normales Bitlocker die CPU Kerne genutzt. Zwar Spezialinstruktionen, aber braucht trotzdem CPU Zeit. Da HDDs allgemein langsam sind im vergleich mit modernen SSDs, fällt die CPU Zeit quasi nicht ins Gewicht bei Verschlüsselung mit HDDs. Während das ganze bei den Durchsatzraten von High End SSDs schon wirklich ins Gewicht fällt. Selbst wenn es den Durchsatz nicht bremsen würde, braucht es spürbar CPU Zeit GiB/s zu ver-/entschlüsseln. Deshalb brechen zB DirectStorage Benchmarks massiv ein mit Bitlocker. Weil die CPU eben noch entschlüsseln muss, bevor die Daten weiter an die GPU gehen.
Aber dann vergleichst du Äpfel mit Birnen, weil du das mit modernen selbst-verschlüsselnden SSDs vergleichst,. Dann muss man auch auf der anderen Seite SED-HDDs nehmen. Die machen die Verschlüsselung auch intern, gibt es schon lange und du merkst wieder keinen Performance Unterschied gegenüber gar nicht verschlüsseln.
Ja, es hat alles Vor- und Nachteile.nutrix schrieb:
Aber jetzt bin ich gespannt, was die Mechanik damit zu tun hat. Eklär mal.
Und da wir leider keine vollständigen Cryptokoprozessoren in CPUs haben, werden für normales Bitlocker die CPU Kerne genutzt. Zwar Spezialinstruktionen, aber braucht trotzdem CPU Zeit. Da HDDs allgemein langsam sind im vergleich mit modernen SSDs, fällt die CPU Zeit quasi nicht ins Gewicht bei Verschlüsselung mit HDDs. Während das ganze bei den Durchsatzraten von High End SSDs schon wirklich ins Gewicht fällt. Selbst wenn es den Durchsatz nicht bremsen würde, braucht es spürbar CPU Zeit GiB/s zu ver-/entschlüsseln. Deshalb brechen zB DirectStorage Benchmarks massiv ein mit Bitlocker. Weil die CPU eben noch entschlüsseln muss, bevor die Daten weiter an die GPU gehen.
Aber dann vergleichst du Äpfel mit Birnen, weil du das mit modernen selbst-verschlüsselnden SSDs vergleichst,. Dann muss man auch auf der anderen Seite SED-HDDs nehmen. Die machen die Verschlüsselung auch intern, gibt es schon lange und du merkst wieder keinen Performance Unterschied gegenüber gar nicht verschlüsseln.
foofoobar
Captain
- Registriert
- Dez. 2011
- Beiträge
- 3.378
Wenn die denn funktioniert.nutrix schrieb:
Ergänzung ()
Darum habe ich die Formulierung "grundsätzlich immer" verwendet.Ja_Ge schrieb:Hoffentlich lagen in den Bereichen nicht irgendwann mal unverschlüsselte Daten, die sind ja nach mancher Logik sonst wieder herstellbar wenn die Nullen nicht mit Nullen überschrieben werden
Ergänzung ()
Hier mal die Performance auf einer modernen CPU, und das ist nur ein Thread der genutzt wird.Ray519 schrieb:
Code:
$ cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1 3501088 iterations per second for 256-bit key
PBKDF2-sha256 6232249 iterations per second for 256-bit key
PBKDF2-sha512 2864961 iterations per second for 256-bit key
PBKDF2-ripemd160 1294538 iterations per second for 256-bit key
PBKDF2-whirlpool 1010188 iterations per second for 256-bit key
argon2i 14 iterations, 1048576 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id 14 iterations, 1048576 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 1559,8 MiB/s 4361,4 MiB/s
serpent-cbc 128b 166,2 MiB/s 1046,7 MiB/s
twofish-cbc 128b 313,6 MiB/s 671,4 MiB/s
aes-cbc 256b 1194,6 MiB/s 4067,7 MiB/s
serpent-cbc 256b 166,2 MiB/s 1047,0 MiB/s
twofish-cbc 256b 313,3 MiB/s 671,3 MiB/s
aes-xts 256b 4127,0 MiB/s 4107,2 MiB/s
serpent-xts 256b 951,4 MiB/s 941,1 MiB/s
twofish-xts 256b 621,8 MiB/s 629,7 MiB/s
aes-xts 512b 3788,0 MiB/s 3789,8 MiB/s
serpent-xts 512b 952,2 MiB/s 941,9 MiB/s
twofish-xts 512b 621,6 MiB/s 629,3 MiB/s
$Das dürfte ein Implementierungsproblem in von Windows sein, wahrscheinlich läuft Windows in diese Falle:
https://blog.cloudflare.com/speeding-up-linux-disk-encryption/
Die Annahme das Crypto langsam ist und deswegen asynchron laufen sollte trifft auf moderner HW einfach nicht mehr zu. Und das schnellere AES (VAES) sickert auch langsam in die Software: https://www.phoronix.com/news/AES-GCM-Intel-AMD-Linux-6.11
Zuletzt bearbeitet:
@foofoobar langsam habe ich auch nicht gesagt.
Ich habe gesagt schnell genug um den Datendurchsatz selbst nicht auszubremsen. Aber durch die Implementierung nicht als Koprozessor, sondern als normale CPU Instruktionen, beschäftigt es die CPU zu einem Teil. Und wenn die CPU schon ausgelastet ist mit anderen Dingen, nimmt es dort Rechenleistung weg. Oder auch einfach nur die zusätzliche Latenz, weil die Daten einmal in dem RAM kopiert werden (von der NVMe), dann erst von CPU Kernen entschlüsselt werden und dann weiter kopiert werden (von der GPU "runtergeladen" zB im Fall von DirectStorage). Es kann also durchaus zu einem Flaschenhals werden, wenn Latenz eine Rolle spielt.
Wenn man das stattdessen mit einem Koprozessor machen würde, könnten die Daten on-the-fly entschlüsselt werden, so dass das erste was im RAM landet schon entschlüsselt ist und ein zusätzlicher Bearbeitungsschritt entfällt. Das war mein Punkt mit OS / Software auf der CPU macht es, vs. die SSD oder ein anderer Koprozessor macht das integriert in den regulären Datenfluss. Und da HDDs wesentlich mehr Latenz haben und wesentlich weniger Bandbreite haben, fällt das alles dort viel weniger ins Gewicht. Die zusätzliche Latenz und CPU Zeit die es braucht um 200 MiB/s zu entschlüsselt merkt man da in Prozent nicht.
Ich habe gesagt schnell genug um den Datendurchsatz selbst nicht auszubremsen. Aber durch die Implementierung nicht als Koprozessor, sondern als normale CPU Instruktionen, beschäftigt es die CPU zu einem Teil. Und wenn die CPU schon ausgelastet ist mit anderen Dingen, nimmt es dort Rechenleistung weg. Oder auch einfach nur die zusätzliche Latenz, weil die Daten einmal in dem RAM kopiert werden (von der NVMe), dann erst von CPU Kernen entschlüsselt werden und dann weiter kopiert werden (von der GPU "runtergeladen" zB im Fall von DirectStorage). Es kann also durchaus zu einem Flaschenhals werden, wenn Latenz eine Rolle spielt.
Wenn man das stattdessen mit einem Koprozessor machen würde, könnten die Daten on-the-fly entschlüsselt werden, so dass das erste was im RAM landet schon entschlüsselt ist und ein zusätzlicher Bearbeitungsschritt entfällt. Das war mein Punkt mit OS / Software auf der CPU macht es, vs. die SSD oder ein anderer Koprozessor macht das integriert in den regulären Datenfluss. Und da HDDs wesentlich mehr Latenz haben und wesentlich weniger Bandbreite haben, fällt das alles dort viel weniger ins Gewicht. Die zusätzliche Latenz und CPU Zeit die es braucht um 200 MiB/s zu entschlüsselt merkt man da in Prozent nicht.
nutrix schrieb:Warum machst Du eigentlich bei mir hier permanent den Erklärbär?Ich weiß das doch alles, weil ich das auch beruflich mache.
Bisschen offtopic, aber nur weil jemand etwas beruflich und lange macht, heißt das nicht, dass er es gut macht und viel Ahnung hat.nutrix schrieb:
