USB-Stick sicher löschen

[.nano]

Einmaliges Überschreiben mit Zufall reicht für jedes Speichermedium. Wichtig ist zu prüfen daß es tatsächlich geschrieben worden ist. Gerade bei USB Stick gibt es auch den Fall daß Schreibzugriffe nicht mehr greifen und beim Lesen, alte Daten zurück kommen (quasi ein Read Only Stick).

Unter Windows macht das h2testw unter Linux kannst du badblocks verwenden.

Du musst bei der Diskussion immer folgendes unterscheiden:

[...]

https://www.computerbase.de/forum/threads/quick-guide-ssds-richtig-loeschen.1881441/

Also reicht letztlich doch ein einfaches shred (sind eh drei Durchgänge), weil am Ende maximal irgendwelche Schnipsel gefunden werden können, mit denen niemand was anfangen kann?

 

[kieleich]

Also reicht letztlich doch ein einfaches shred (sind eh drei Durchgänge), weil am Ende maximal irgendwelche Schnipsel gefunden werden können, mit denen niemand was anfangen kann?

Ein Durchgang reicht.

Das finden von Schnipsel, ist zwar theoretisch möglich aber praktisch vernachlässigbar.

Wahrscheinlicher ist daß das Überschrieben aus irgendwelchen Gründen nicht klappt und das ist der Schwach Punkt von shred, es findet keiner lei Kontrolle statt.

Statt drei mal blind schreiben ohne Prüfen lieber einmal Überschreiben, einmal Prüfen daß tatsächlich Überschrieben worden ist.

badblocks -w -t random und wenn es wirklich Wasser dicht sein soll noch cryptsetup aes-xts-plain64 dazwischen! badblocks schreibt festes pattern und Verschlüsselung verwürfelt es richtig

 

[calippo]

USB Sticks würde ich auch mit HW2test ein mal komplett vollschreiben lassen und die Prüfung durchführen. Dann kann man sicher sein, dass zumindest der im Zugriffsbereich des Systems befindliche Speicher ein mal komplett beschrieben wurde und man ist zudem sicher, dass der Stick überhaupt noch funktioniert.

Ob der Aufwand bei USB-Sticks lohnt? Ich denke nur dann, wenn es sich um relativ große und schnelle Sticks handelt. Alles mit Neupreis von unter 20€ wird eher unverkäuflich sein, zumindest einzeln.
So ab 256GB Sticks könnte das sinnvoll sein.
Wenn es nur ums Entsorgen geht, dann sollte es reichen, den Stick mit groben Werkzeug zu bearbeiten.

Ich versteh sowieso nicht das man wichtige Daten nicht sowieso verschlüsselt. da muss Ich mir über so etwas nicht einen Gedanken verschwenden.

Genau, gerade bei vielen USB Sticks steigt doch das Risiko, dass man einen verliert. Daher verschlüssle ich auch alle Sticks, auf denen was nicht öffentliches gespeichert werden soll.
Am einfachsten geht es unter Windows mit Bitlocker. Muss man sich Windows Pro besorgen.

 

[.nano]

badblocks -w -t random und wenn es wirklich Wasser dicht sein soll noch cryptsetup aes-xts-plain64 dazwischen! badblocks schreibt festes pattern und Verschlüsselung verwürfelt es richtig

Wie, dazwischen? Meinst du damit, erst badblocks, dann cryptsetup und anschließend erneut badblocks? Oder lassen sich die Befehle kombinieren?

Und würdest du die Befehle auch bei HDDs shred vorziehen, oder da lieber bei shred bleiben?

 

[kieleich]

Wie, dazwischen? Meinst du damit, erst badblocks, dann cryptsetup und anschließend erneut badblocks? Oder lassen sich die Befehle kombinieren?

badblocks aufs crypt device an der anzahl durchgänge ändert sich dadurch nichts nur das test pattern wird verschlüsselt. ist nur not wendig weil badblocks, leider ein festes pattern nimmt und dieses dann ständig wiederholt. wenn die SSD schlau genug wäre für De-Duplizierung der Daten, müsste sie dann nicht überschreiben. bei Zufallsdaten muss sie diese zwangs weise geschrieben und damit andere Daten gelöscht haben q.e.d.

Und würdest du die Befehle auch bei HDDs shred vorziehen, oder da lieber bei shred bleiben?

ich würde auch bei HDD prüfen ob es geklappt hat

Du kannst auch, die Methode aus dem Arch Wiki, nehmen:

https://wiki.archlinux.org/title/Badblocks#Alternatives

Aber anstelle von shred, cmp eben, badblocks. ist auch egal kommt aufs gleiche heraus

Ach so da steht daß badblocks Probleme mit zu großen Laufwerken hat. Okay, aber da kann man einfach -b 32768 oder -b 65536 nehmen dann schreibt es halt, in 64K Blöcken (Default 1024 Bytes ist aus heutiger Sicht eh Quark)

 

[.nano]

badblocks aufs crypt device an der anzahl durchgänge ändert sich dadurch nichts nur das test pattern wird verschlüsselt.

Klingt nachvollziehbar, ich weiß jetzt nur nicht, wie ich das umsetze
Wie lautet denn der Befehl dazu?

 

[kieleich]

Klingt nachvollziehbar, ich weiß jetzt nur nicht, wie ich das umsetze
Wie lautet denn der Befehl dazu?

guckst du den arch wiki link im vorigen beitrag dort der crypt setup plain befehl

dann /dev/mapper/cryptname statt /dev/name verwenden mit Befehl deiner Wahl (bad blocks oder shred cmp oder wie auch immer)

 

[.nano]

Also nachdem ich nun überlegt habe, komme ich auf keinen grünen Zweig, wie du das meinst.
cryptsetup habe ich noch nie genutzt und aus den man pages werde ich nicht schlau, wie ich jetzt cryptsetup mit badblocks kombinieren soll.

So wie ich mir das gerade vorstelle:

cryptsetup open /dev/sdX --type plain --cipher aes-xts-plain64

und dann einfach gefolgt von einem

badblocks -wsv -t random /dev/mapper/sdX

Richtig so?

Und wie schließe ich das ganze am Ende ab?

So wie ich das verstanden habe, öffne ich ja erst einen verschlüsselten Container und führe dann in diesem Container drin badblocks aus. Also reicht dann ein einfaches Formatieren, oder? Weil sobald ich ja anfange überhaupt irgendwas auf den Stick zu schreiben, wird ja der Container beschädigt und unbrauchbar, richtig?

Oder muss ich nach den beiden obigen Befehlen noch irgendwas bereinigen?

 

[kieleich]

Ja schon richtig deinem Cryptsetup fehlt nur der 2. Parameter (Name fürs Crypt Devices /dev/mapper/name) kannst du beliebig wählen

Das verschlüsselte /dev/mapper/x ist einfach nur ein Blockgerät das alle Schreibzugriffe verschlüsselt und alle Lesezugriffe entschlüsselt. Ob dabei was sinnvolles heraus kommt oder nur Daten Salat ist dem Device Mapper egal.

Wenn du da also mit badblocks -w darauf gehst und badblocks das gesamte Geräte überschreibt dann wird auch der Stick direkt überschrieben, eben in verschlüsselter Form und beim gegen testen (Badblocks 2. Durchgang Lesevorgang nach dem Überschreiben) eben wieder entschlüsselt.

Und wenn dabei, keine Fehler auftreten, dann weisst du: dein Stick ist vorne bis hinten voll mit verschlüsselten Zufallsdaten geschrieben worden und hat beim anschließenden Auslesen alles korrekt wieder gegeben muss die Daten also, in voller Länge gespeichert haben, da Zufallsdaten, nun mal nicht komprimierbar sind da kann der Stick nicht mogeln.

Kaputt gehen kann dabei nichts (bis auf den Stick selbst durch Schreibzugriffe oder Überhitzung aber das passiert auch unverschlüsselt)

Ein Container (identifizierbarer Header) ist (im Cryptsetup Plain Modus) nicht vorhanden.

Beim nächsten Reboot ist das auch wieder weg ansonsten nach Abschluss ein 'cryptsetup close cryptname' machen dann ist das /dev/mapper ding wieder weg

Bereinigen, muss man da sonst, nichts

Anschließend, eben partitionieren und ein Dateisystem, formatieren um wieder Dateien auf dem Stick, speichern zu können

 

[.nano]

Ah, also dann

cryptsetup open /dev/sdX /dev/mapper/Stick --type plain --cipher aes-xts-plain64

?

 

[kieleich]

ohne dev/mapper

warum probierst du es nicht einfach aus?

 

[.nano]

Weil ich etwas verwirrt bin und nichts kaputt machen will.
Daher lieber einmal zu viel, als zu wenig gefragt

Zudem nützt es mir ja nichts, wenn ich etwas eingebe, was am Ende nicht ganz richtig ist und die Daten nicht korrekt gelöscht werden. Und ich dann aber in der irrigen Annahme denke, dass sie es sind.

cryptsetup open /dev/sdX Stick --type plain --cipher aes-xts-plain64

Erschafft mir also den Container, den ich dann mit

badblocks -wsv -t random /dev/mapper/Stick

fülle, jetzt richtig?

 

[kieleich]

sollte so hin hauen, ja

das /dev/sdX muss eben richtig sein da musst du mit lsblk, oder so schauen, was ist was

sonst überschreibst du tat sächlich das falsche Gerät am Ende aber mit shred & co hättest du ja, das gleiche Problem

 

[.nano]

Super, vielen Dank!