ubuntuusers.de

Ich habe zu diesem Thema sehr unterschiedliche Meinungen gehört.

Im Wiki steht, dass die wipe Entwickler empfehlen jede Partition einzeln zu wipen und nicht die komplette Festplatte auf einmal.

Ich habe bisher fürs Löschen gesamter Festplatten und USB-Sticks immer wipe benutzt und jede Partition nur einmal einzeln überschreiben lassen:

sudo wipe -i -q -Q 1 -R /dev/zero -S r -k /dev/sda1 

Danach zeigt GParted die Partition noch an, löschte aber alles komplett.

Auf ehemals NTFS-formatierten externen HDD's gab es außerdem immer eine unformatierte & leere Partition mit einer Größe von 1MB. Ich gehe davon aus, dass das bei diesem Dateisystem normal ist, weil es sich auch nicht mit GParted ändern läßt (egal wie ich die Partitionsgrößen verschiebe, 1MB scheint immer vor oder nach der Primären Partition existieren zu müssen. Ich könnte mir vorstellen, dass das sogar was mit dem Journal, welches NTFS wie auch ext4 anlegt, zu tun haben könnte. Eine absolute Laien-Vermutung).

Bei wipe verstand ich bisher die Bedienung besser als bei dd und der Befehl hdparm -i /dev/sdX klappte auch nicht für das Herausfinden der Puffergröße meiner HDD um den Prozess mit dd zu beschleunigen, wie im Wiki beschrieben. Und auch bei dd bin ich mir nicht sicher was besser, sicherer oder schneller ist: kompletten Datenträger oder Partitionen einzeln überschreiben? Möglicherweise spielt es nur (laut der Entwickler) eine Rolle bei wipe, aber nicht bei dd?

Der folgende Befehl löscht die komplette Festplatte /dev/sdX durch Überschreiben mit Nullen:

dd if=/dev/zero of=/dev/sdX

Der folgende Befehl löscht die komplette Festplatte /dev/sdX durch Überschreiben mit Zufallszahlen (zeitintensiv):

dd if=/dev/urandom of=/dev/sdX 

Für die erste Festplatte /dev/sdX mit 8 MiB Puffergröße sieht dass dann so aus:

dd if=/dev/zero of=/dev/sdX bs=8M & pid=$!

Zeit ist kein bedeutender Faktor für mich, Sicherheit und zuverlässiges Löschen schon. Ein Terabyte brauchte bei mir mit wipe -q -Q 1 /dev/zero circa ein bis zwei Tage. Mit -q -Q 2 oder sogar -q -Q 4 kann ich die Anzahl der Löschvorgänge und potentiell die Löschsicherheit erhöhen (auch wenn laut dem alten heise.de Artikel einmal überschreiben bei HDDs genügt).

Daten sicher lC3B6schen

Letzeres lässt sich auch ungefähr auf Solid-State-Speicher übertragen: hier jedoch nur, wenn man die komplette Festplatte (nicht nur die Partition!) bzw. das ganze Laufwerk mehrfach überschreibt. Auch dann sollten wipe und shred jeden Block auf der Festplatte mindestens einmal überschrieben haben. Wie oft es nötig ist, bei Solid-State-Speichern diese Laufwerke zu überschreiben, damit forensische Mittel Daten nicht mehr herstellen können, ist auf Grund deren geringer Verbreitung derzeit nicht bekannt.

Heißt, USB-Sticks können gerne mal 6 oder 10 mal komplett (bei SSD-Datenträgern wohl nie Partitionen einzeln löschen) überschrieben werden bis die einstigen Daten darauf wirklich komplett gelöscht sind? Also bei einem USB-Stick nicht -q -Q 1 /dev/zero benutzen sondern eher -q -Q 6 /dev/urandom, oder? Laut diesem Blog-Kommentar, denn ich las:

SSDs sollten dagegen mit Zufallszahlen (und nicht mit Nullen) überschrieben werden und das auch mehrfach. Insgesamt ist die Faktenlage bei diesen Datenträgern aber noch etwas mager um zukunftssicher sagen zu können, wie viele Durchgänge beim Überschreiben wirklich „sicher“ löschen.

In beiden Fällen gilt, dass man Datenträger immer besser vollständig überschreibt, also nicht nur einzelne Partitionen oder gar Dateien/Ordner.

Ist die schnelle Löschung (-q) mit wipe zwangsläufig weniger gründlich als die reguläre/Zeit intensivere Löschung - und gleicher Unterschied gilt auch bei dd für die Verwendung von /dev/zero und /dev/urandom? Zufallszahlen dauern länger und sind noch genauer oder sicherer als "nur" Nullen?

Das Problem bei einer SSD ist das selbst wenn man sie „komplett“ überschreibt ist das nicht genug. Hintergrund ist dass die SSD im Durchschnitt etwa 10 Prozent ihrer Gesamtkapazität in der Hinterhand hält, an diese 10 % kommt man nicht heran, da sie vom Controller verwaltet werden.

[...]

Eine SSD mehrfach zu überschreiben wird wegen dem wear leveling recht wenig bringen.

Ich würde, gerade bei SSD (aber auch bei HDD), daher auf 'ATA Secure Erase' zurückgreifen. Hierbei wird auch der Bereich für Sector Reallocation überschrieben.

Das ist das erste Mal, dass ich von diesem SSD/Secure-Erase höre. [SecureErase https://partedmagic.com/secure-erase/ PartedMagic]. Habe auch keine SSD-Festplatte, aber eben Flash-Speichermedien (USB-Sticks,SD-Karten) die wenn ich es richtig verstanden habe ja wie SSD-Festplatten zu den SolidState-Datenträgern gehören deswegen mit selben Methoden zu überschreiben sind (bspw. mehrfache Überschreibung des kompletten Datenträgers). Sollte ich sicherheitstechnisch mich wohl mehr mit SecureEras beschäftigen? Man löscht ja nicht nur HDD's sondern auch Sticks und SD-Karten.

Bisher nutzte ich bei USB-Sticks auch wipe -Q 1 /dev/zero /dev/sdc1 - aber hätte ich eigentlich wipe -Q 6 /dev/urandom /dev/sdc verwenden sollen?

Ich hatte ja bereits in einem vergangene Thread Fragen zur Datenlöschung, aber - und vielleicht liegt es an mir, dass ich keinen richtigen Überblick habe - ich las überall unterschiedliche Vorgehensweisen und Theorien. Kann einen als Anfänger/Noob halt manchmal schon recht verwirren, dass User oftmals völlig unterschiedliche Meinungen, sogar über technische Zusammenhänge, haben. Das bemerkte ich erst neulich in meinem Thread, wo ich nach den Erfahrungen & Meinungen der UbuntuUsers zu Verschlüsselung fragte.

Allein durch mein intensives Aufschreiben meiner Fragen, habe ich den Eindruck schon einen besseren Überblick über das Thema zu bekommen. Es sind viele "kleine" Fragen, aber alle zu einem und dem selben thematischen Zusammenhang, trotzdem gilt wie immer: Ich habe absolutes Verständnis dafür, wenn ich eure Geduld oder Hilfsbereitschaft zu sehr strapaziere oder meine Fragen (und mein Denken) als zu durcheinander angesehen oder wahrgenommen werden.

Ich verfüge vielleicht nicht über eine ausgezeichnete Aufnahmefähigkeit und auch nicht über ein lückenhaftes Gedächtnis oder die Fähigkeit komplexe Zusammenhänge schnell zu begreifen, aber ich versuche mein bestes und schreibe sogar die wichtigsten Wiki-Artikel per Hand ab und notiere mir verständliche Erklärungen. Habe mir erst neulich den Zusammenhang und Unterschied zwischen Fenstermanager und Desktop-Umgebung zum besseren Verständnis aufzeichnen müssen ☺

Danke. LG, lubuntu-lulu

Im Wiki steht, dass die wipe Entwickler empfehlen jede Partition einzeln zu wipen und nicht die komplette Festplatte auf einmal.

Ich sehe da keinen Vorteil. Im Gegenteil, Daten die sich möglicherweise außerhalb von Partitionen befinden werden nicht überschrieben. Zusätzlich ist es auch noch umständlicher.

sudo wipe -i -q -Q 1 -R /dev/zero -S r -k /dev/sda1

Wenn der Startwert für den Pseudozufallsgenerator aus /dev/zero kommt, sind die Daten die wipe generiert nicht zufällig, sondern immer die gleichen.

Auf ehemals NTFS-formatierten externen HDD's gab es außerdem immer eine unformatierte & leere Partition mit einer Größe von 1MB.

Das hat nichts mit dem Dateisystem zu tun. Windows lässt den Speicher beim Partitionieren frei.

der Befehl hdparm -i /dev/sdX klappte auch nicht für das Herausfinden der Puffergröße meiner HDD um den Prozess mit dd zu beschleunigen

Das ist nicht spezifisch für eine Festplatte. Das steuert einfach die Größe der Puffer die dd für den read und write Systemaufruf benutzt. Du kannst immer 8M benutzen, oder auch größer (z.B. 64M), falls es schneller ist.

Ein Terabyte brauchte bei mir mit wipe -q -Q 1 /dev/zero circa ein bis zwei Tage.

😲 Verschlüssele die Festplatte mit dm-crypt mit einem zufälligen Schlüssel und überschreibe das verschlüsselte Gerät mit Nullen. Damit überschreibst du die Festplatte mit "Zufallsdaten" und es ist auf den meisten Computern genauso schnell, wie das einfache Überschreiben mit Nullen.

SSDs sollten dagegen mit Zufallszahlen (und nicht mit Nullen) überschrieben werden und das auch mehrfach.

Einige SSDs verwenden Kompression und eine Folge von Nullen ist sehr gut komprimierbar. Dadurch werden nur wenige Daten tatsächlich geschrieben. Das könnte ich mir jedenfalls als Grund vorstellen, wobei ich auch falsch liegen kann.

Eine SSD mehrfach zu überschreiben wird wegen dem wear leveling recht wenig bringen.

Das Problem ist Over-Provisioning (der Extraspeicher im "Hintergrund", der für's Wear leveling benutzt wird). Mehrfaches Überschreiben dürfte eher die Chance erhöhen, dass der gesamte Speicher überschrieben wird. Die Frage ist, wie schwer es ist diese Daten zu lesen und ob jemand bereit ist den Aufwand auf sich zu nehmen.

Ich würde, gerade bei SSD (aber auch bei HDD), daher auf 'ATA Secure Erase' zurückgreifen.

Im Linux Kernel Wiki steht, dass die Zellen nur als leer markiert werden: https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase Was genau passiert, hängt wahrscheinlich vom Modell ab. Auch hier stellt sich wieder die Frage, wie groß der Aufwand ist die Daten zu lesen.

Da die Sachlage bei SSD's weiterhin noch nicht ganz klar oder erforscht zu sein scheint, schätze ich mal, dass wenn man SSD's und Flash-Datenträger wirklich "löschen" möchte, muss man sie in den Ofen werfen oder in der Ostsee versenken 😀

Im Gegenteil, Daten die sich möglicherweise außerhalb von Partitionen befinden werden nicht überschrieben. Zusätzlich ist es auch noch umständlicher.

Ich war auch etwas verdutzt, als ich sah dass (soweit ich es richtig verstanden habe) bei wipe explizit angeben muss, wenn alle Blöcke beschrieben werden sollen

-e = Benutze die genaue Größe und runde nicht auf, um eventuellen Müll im letzten Block zu löschen

Verschlüssele die Festplatte mit dm-crypt mit einem zufälligen Schlüssel und überschreibe das verschlüsselte Gerät mit Nullen. Damit überschreibst du die Festplatte mit "Zufallsdaten" und es ist auf den meisten Computern genauso schnell, wie das einfache Überschreiben mit Nullen.

EDIT: Achso, nachdem ich die Platte verschlüsselt habe soll ich das verschlüsselte Gerät überschreiben, aber was bringt in dem Fall die "schnelle" Verschlüsselung (nicht wie bei Container-Erstellung, dass der gesamte Speicher bereits als belegt angezeigt wird..)

Meinst du etwa, dass ich bereits vor dem Überschreiben mit Nullen die Festplatte einmal schnell mit dm-crypt verschlüsseln soll? Oder meintest du schlicht und einfach diese Reihenfolge:

1. Komplettes Gerät mit Nullen überschreiben (ich gehe weiterhin davon aus, dass dies bei meinen Rechnern 1-2 Tage dauern wird)

2. Verschlüsseln der Festplatte mit LUKS (=dm-crypt?)

Oder meintest du, dass man beides macht: Platte komplett verschlüsseln (aber so, dass bereits der gesamte Speicher als Platzverbrauch angezeigt wird, s.u.) und dann nochmal mit dd? Macht vermutlich gar keinen Sinn, weil das Verschlüsseln in dem Fall das gleiche wie dd machen würde: Mit Nullen/Zufallszahlen zu überschreiben. Du sagtest ich überschreibe es "damit mit Zufallszahlen" - durch die Verschlüsselung? Weil wir überschreiben es doch mit 'Nullen' und nicht dev/urandom!?

LUKS Bei sehr großen Containerdateien können sehr große bs-Werte wie 200M bei count=1 je nach System die Erzeugung der Datei in der gewünschten Größe stark beschleunigen. In diesem Beispiel wäre die Datei 200 * 1 = 200 MiB groß. Alternativ beschleunigt auch die Verwendung von if=/dev/zero durch Nullen anstelle von Zufallszahlen wie bei urandom. Um einen Container von 1000 GiB anzulegen, welcher nicht erst mehrere Stunden überschrieben wird (dadurch unter Umständen unsicherer), sondern sofort verfügbar ist, eignet sich der Befehl fallocate -l 1000G DATEI. Soll dagegen die Datei zwar sofort 1000 GiB Platz bieten und als Platzverbrauch (mit ls) anzeigen, aber erst tatsächlich wachsen und Platz belegen (mit df überprüfbar), wenn der Container auch tatsächlich gefüllt wird, so eignet sich der Befehl truncate -s 1000G DATEI

Tut mir wirklich sehr leid, aber ich glaube ich komme da gerade etwas durcheinander, was wann wie laut deinem Post gemacht werden soll. Mein bisheriges Verfahren war wie gesagt die einzig vorhandene Partition (bis auf diese partitionslose/unformatierten 1MB in gparted) mit Nullen im Schnellmodus einmal zu überschreiben und anschließend 'exakt' wie im Wiki beschrieben den kompletten Datenträger mit LUKS verschlüsselt.

Wie bereits erwähnt möchte ich eben die effektivsten Methoden verwenden, freue mich aber natürlich auf über einge gewisse Effizienz. Doch durch die ganzen Snowden Enthüllungen ist wohl die Paranoia größer als geworden als eine fehlende Geduld

Herzlichen Dank für deine Expertise zu diesem Thema und selbstverständlich auch für jegliche aufgebrachte Geduld mit mir 😉

-e = Benutze die genaue Größe und runde nicht auf, um eventuellen Müll im letzten Block zu löschen

dd ist einfach und hat keine merkwürdigen Überraschungen.

Meinst du etwa, dass ich bereits vor dem Überschreiben mit Nullen die Festplatte einmal schnell mit dm-crypt verschlüsseln soll?

Ja, du sollst aber nicht die Festplatte direkt mit Nullen überschreiben, sondern das verschlüsselte Gerät. Dadurch werden die verschlüsselten Nullen auf die Platte geschrieben, was praktisch zufällige Daten sind.

Der Vorteil ist einfach, dass es schneller ist. Auf meinem Laptop werden Zufallsdaten aus /dev/urandom mit 250 MB/s generiert, AES Verschlüsselung schafft im Gegenteil 3000 MB/s.

Du musst überprüfen, wie schnell es auf deinem Rechner ist. Falls /dev/urandom eh deutlich schneller als die Festplatte ist, kannst du die Zufallsdaten auch direkt von da lesen.

Komplettes Gerät mit Nullen überschreiben (ich gehe weiterhin davon aus, dass dies bei meinen Rechnern 1-2 Tage dauern wird)

Das bedeutet das die Festplatte (1 TB) nur mit ~7 MB/s geschrieben wird. Das ist viel zu langsam, das sollte nur ein paar Stunden dauern. Benutze:

dd if=/dev/zero of=/dev/sdX bs=64M status=progress

Das Argument status=progress zeigt den Fortschritt und Geschwindigkeit an. Um die genaue Block-Größe musst du dir bei dd keine Gedanken machen, es werden alle Daten überschrieben (im Gegensatz zu wipe).

Mein bisheriges Verfahren war wie gesagt die einzig vorhandene Partition (bis auf diese partitionslose/unformatierten 1MB in gparted) mit Nullen im Schnellmodus einmal zu überschreiben und anschließend 'exakt' wie im Wiki beschrieben den kompletten Datenträger mit LUKS verschlüsselt.

Mit wipe kann man die Festplatte nicht mit Nullen überschreiben. Der Befehl den du im ersten Post angegeben hast und der auch im Wiki steht, füllt die Festplatte mit deterministischen Pseudozufallsdaten. Die Aussage aus dem Wiki, dass es die Festplatte mit Nullen überschreibt ist falsch.

Wenn du die HDD für Verschlüsselung benutzen willst, solltest du die sie optimalerweise mit Zufallsdaten überschreiben. Man kann sehen welche Blöcke benutzt werden (nämlich alle die nicht nur aus Nullen bestehen). Das ist zwar nicht wirklich kritisch, aber Zufallsdaten und Nullen machen zeitlich ja eh keinen Unterschied.

Da die Sachlage bei SSD's weiterhin noch nicht ganz klar oder erforscht zu sein scheint, schätze ich mal, dass wenn man SSD's und Flash-Datenträger wirklich "löschen" möchte, muss man sie in den Ofen werfen oder in der Ostsee versenken 😀

SSDs würde ich einfach von Anfang an verschlüsseln. Wenn auf der SSD niemals unverschlüsselte Daten waren, musst du sie auch nicht überschreiben.

Snowden Enthüllungen

Die CIA wird kaum deine alten Festplatten untersuchen. Realistisch ist eher das irgendjemand deinen Rechner oder so klaut, da reicht aber schon einfachste Verschlüsselung.

Ich bin wirklich ziemlich unterblichtet/auf den Kopf gefallen. Können wir das nochmal ganz einfach und übersichtlich (am besten sogar mit den Befehlen) aufschreiben?

Fülle ich im Grunde die verschlüsselte Partition (oder Gerät?) mit Nullen? Oder wollen wir mit einem Überschreiben des gesamten Gerätes/der Festplatte eben auch die verschlüsselte Partition löschen?

Ich verstehe, wenn ich deine Geduld bereits zu sehr strapaziert habe.

Fall 1: Du hast eine unverschlüsselte Festplatte. Diese willst du (warum auch immer, überflüssig) mit Zufallszahlen anstatt Nullen überschreiben. Dabei willst du dir keine Gedanken um Partitionsangaben und Zwischenbereiche machen. Du überschreibst ALLES mit Nullen. Da du Zufallszahlen willst, nimmst du /dev/random. /dev/urandom wäre sowieso zu lahm, weil zu zufällig. Dann ist auch nix mehr zu lahm.

Das mit der Verschlüsselung ist eigentlich (in der Theorie) Quatsch (wurde hier aber praktisch gut begründet) - aber sollte es eben schneller sein, kannst du natürlich /dev/sda ohne Partitionen (die müssen vorher gelöscht werden) mit ...cryptsetup luksFormat... direkt zu einem /dev/mapper/luks verschlüsseln - und auf diesen dann mit dd die /dev/zero loslassen. zero, weil sie schneller sind als (u)random - und es ist trotzdem Zufall statt Nullen, weil ja LUKS für /dev/mapper/luks das alles ZUFÄLLIG verschlüsselt.

Fall 2: Du hast eine VERschlüsselte Festplatte sda1 und willst sie der NSA auf Ebay verkaufen. Du löschst mit dd mit Nullen die ersten paar MB (10 wären schon reichlich) von sda (und damit auch sda1). Damit ist dein Inhalt unwiederbringlich verschlüsselt und verloren. Auch wenn die NSA das Passwort aus dir rausprügelt, ist nichts mehr zu holen. Ausnahme: Sie finden eine Kopie des LUKS-Sektors, den du überschrieben hast UND kommen auf dein PW, sei es wegen der Einfachheit/ Kürze oder weil sie dich "ausfragen".

So eine Kopie kannst nur du selbst angelegt haben: Etwa beim Backup mit dd oder durch cryptsetup luksHeaderBackup auf ein weiteres Medium, welches NICHT verschlüsselt ist (und bei Verschlüsselung, wie gewöhnlich, eigene LUKS-Header haben muss, also nicht irgendwie den selben geklont). Also bei Backups und Clones aufpassen, ob das nun mit dd oder Clonezilla oder oder...geklont wird oder im Zug, während du auf Toilette bist.

Du bist dir nun also sicher, dass der LUKS-Header nur einmal existiert - machst ihn platt - und brauchst dafür dann die anderen 1 TB (- 10 MB) Sektoren nicht mehr überschreiben. Denn da kommt ja keiner ran, ist ja mit deinem PW gesichert. Und selbst das geht nun nicht mehr, weil du die einzige LUKS-Kopie zerstört hast, welche mit deinem PW was hätte anfangen können. Darin sind weitere Verschlüsselungsdaten gespeichert, ohne die gar nix geht.

Dein PW ist quasi nur der Schlüssel zu diesem eigentlichen extrem sicheren Schlüssel, den du aber zerstörst. Damit kannst du vorn ins Schloss stecken, was du willst, noch hinten am und hinterm Schloss (LUKS) fummeln, wie du willst - du wirst niemals mehr was aufbekommen. Ziel erreicht.

Grüße, Benno

PS: Find ich gut, dass du dir was aus dem Wiki aufschreibst oder aufmalst, wenn dir das hilft. 👍 Die Fragen sind auch gar nicht so dumm, die Materie ist für Laien erst mal sperrig - mit der Zeit kann man (muss aber nicht) den Durchblick bekommen. Der ist ganz simpel: Alles sind nur durchnummerierte Sektoren. Ob Festplatte oder SSD, prinzipiell erst mal egal. SSD haben zwar spezielle Reservebereiche im Vergleich zu denen der Festplatte, aber das muss dich jetzt nicht auch noch so sehr kümmern, nach dem, was bisher erklärt und gemacht wurde. Mit dd kann man die Sektoren überschreiben, z.B. komplett mit Nullen. Das war's schon.

Alle anderen Tools machen nix andres. wipe kocht genauso auch nur mit Wasser. Clonezilla kann dd oder vorher noch leere Sektoren auslassen. Alles führt also zu den Sektoren und dd zurück (oder etwas ähnlichem wie wipe, was kein dd benutzt:

$ apt-cache depends wipe
wipe
  Hängt ab von: libc6
  Kollidiert mit: wipe:i386
$

Sonst würde hier normalerweise dd als Abhängigkeit stehen.).

Das Thema Verschlüsselung gehört hier EIGENTLICH (theoretisch) gar nicht rein - nur für Fall 2 - da brauchst du dann aber fast kein wipe mehr, nur für paar Sektoren (der verschlüsselten Partition sdXY - und sicherheitshalber auch paar von sdX mit den Partitionsdaten).

Und davon ab, deine Fragen helfen hier ja auch anderen beim Verständnis.

Ganz herzlichen Dank für deine tolle, ausführliche und extrem gut verständliche Antwort, Benno-007! Ist mir schon des Öfteren aufgefallen, dass du sehr gut kompl. Zusammenhänge verständlich für Laien erklären kannst. 😉

Aber wie gesagt, ich habe jederzeit Verständnis dafür, wenn jemandem meine Fragen oder Schwerfälligkeit zu viel wird und man es mir mitteilt, aber eben in einem freundlichen (oder eben einfach den Thread verlassen).

Benno-007 schrieb:

Diese willst du (warum auch immer, überflüssig) mit Zufallszahlen anstatt Nullen überschreiben.

Ich habe es so verstanden, dass die Festplatte danach für Verschlüsselung genutzt werden soll. Zufallszahlen sind da zwar nicht zwingend notwendig, aber wenn es von der Geschwindigkeit eh keinen Unterschied macht, kann man es auch machen.

Das mit der Verschlüsselung ist eigentlich (in der Theorie) Quatsch (wurde hier aber praktisch gut begründet)

Das ist ein Standardverfahren. Gerade auf älteren Rechnern, kann /dev/urandom deutlich langsamer als eine HDD sein. Er schrieb, dass das Überschreiben (mit wipe) einer 1 TB HDD ein bis zwei Tage dauert, deshalb habe ich einen Vorschlag gemacht, der schneller ist.

kannst du natürlich /dev/sda ohne Partitionen (die müssen vorher gelöscht werden) mit ...cryptsetup luksFormat... direkt zu einem /dev/mapper/luks verschlüsseln

Da braucht man kein LUKS, sondern kann dm-crypt direkt benutzen. Was meinst du damit, dass die Partitionen gelöscht werden müssen? Wenn die ganze HDD überschrieben wird, sind die weg.

Fall 2: Du hast eine VERschlüsselte Festplatte sda1 und willst sie der NSA auf Ebay verkaufen.

Wenn die Festplatte verkauft werden soll, sind Nullen natürlich völlig ausreichend.

Sonst würde hier normalerweise dd als Abhängigkeit stehen.

Warum sollte dd eine Abhängigkeit von wipe sein? Das einzubinden wäre umständlicher, als die Funktionalität selber zu implementieren. Im Kern liest dd in einer Schleife Daten aus einer Datei und schreibt sie in eine andere. Ich verstehe gar nicht auf was du hinaus willst.

da brauchst du dann aber fast kein wipe mehr

wipe scheint mir im allgemeinen kein empfehlenswertes Tool zu sein.

• Es schreibt Daten in 16 KiB Blöcken. Das wird einer der Gründe sein, warum es so langsam ist (viele Kontextwechsel).

• Es ist umständlich in der Bedienung. (Das letzte Beispiel im Wiki ist z.B. falsch.)

• Das mehrfache Überschreiben (die Hauptfunktionalität) von Dateien/Devices macht keinen wirklichen Sinn.

• Es ist standardmäßig nicht installiert.

lubuntu-lulu schrieb:

am besten sogar mit den Befehlen

Fall 1: Die Festplatte mit Nullen überschreiben

dd if=/dev/zero of=/dev/sdX bs=64M status=progress

Fall 2: Die Festplatte mit Zufallsdaten überschreiben

dd if=/dev/urandom of=/dev/sdX bs=64M status=progress

Fall 3: Die Festplatte mit Zufallsdaten überschreiben (schneller)

1
2
3
4
5
6

DEV=/dev/sdx
CRYPT_DEV=sdx_crypt

dmsetup create $CRYPT_DEV --table "0 `blockdev --getsize $DEV` crypt aes-cbc-essiv:sha256 `tr -dc a-f0-9 </dev/urandom | head -c32` 0 $DEV 0"
dd if=/dev/zero of=/dev/mapper/$CRYPT_DEV bs=64M status=progress
dmsetup remove $CRYPT_DEV

Gekürzt:

g123 schrieb:

Das ist ein Standardverfahren. Gerade auf älteren Rechnern, kann /dev/urandom deutlich langsamer als eine HDD sein. Er schrieb, dass das Überschreiben (mit wipe) einer 1 TB HDD ein bis zwei Tage dauert, deshalb habe ich einen Vorschlag gemacht, der schneller ist.

Ich habe verwechselt, dass urandom ja schon schneller als random ist und somit keine Ausweichmöglichkeit außer etwa deine genannte besteht.

kannst du natürlich /dev/sda ohne Partitionen (die müssen vorher gelöscht werden) mit ...cryptsetup luksFormat... direkt zu einem /dev/mapper/luks verschlüsseln

Da braucht man kein LUKS, sondern kann dm-crypt direkt benutzen. Was meinst du damit, dass die Partitionen gelöscht werden müssen? Wenn die ganze HDD überschrieben wird, sind die weg.

Ich benutze selten Datenträger ohne Partitionstabelle, aber um sicherzugehen, dass sdXY nicht stört, hätte ich das Device auf sdX kastriert. Wenn die Partitionstabelle dabei sowieso verschwindet, um so besser.

Fall 2: Du hast eine VERschlüsselte Festplatte sda1 und willst sie der NSA auf Ebay verkaufen.

Wenn die Festplatte verkauft werden soll, sind Nullen natürlich völlig ausreichend.

Es geht aber in Fall 2 darum, nicht nullen zu müssen.

Sonst würde hier normalerweise dd als Abhängigkeit stehen.

Warum sollte dd eine Abhängigkeit von wipe sein? Das einzubinden wäre umständlicher, als die Funktionalität selber zu implementieren.

Finde ich ganz und gar nicht. Das wäre Unix-like. Clonezilla (partimage) kann auch dd nutzen.

Im Kern liest dd in einer Schleife Daten aus einer Datei und schreibt sie in eine andere. Ich verstehe gar nicht auf was du hinaus willst.

Musst du auch nicht - es war ein Erklärungsversuch an den Threadstarter. Es ging darum, dass alle Tools letztlich auch bloß dd aufrufen oder sowas ähnliches sind (wipe).

Fall 3: Die Festplatte mit Zufallsdaten überschreiben (schneller)

1 2 3 4 5 6

DEV=/dev/sdx CRYPT_DEV=sdx_crypt dmsetup create $CRYPT_DEV --table "0 `blockdev --getsize $DEV` crypt aes-cbc-essiv:sha256 `tr -dc a-f0-9 </dev/urandom | head -c32` 0 $DEV 0" dd if=/dev/zero of=/dev/mapper/$CRYPT_DEV bs=64M status=progress dmsetup remove $CRYPT_DEV

Und weil du oben fragtest, warum LUKS:

1. Weil ich es kenne.

2. Weil deine dmsetup-Zeile der blanke Horror gegenüber einem griffigen cryptsetup luksFormat ist. (Und Backticks machen das nicht lesbarer, sind auch schon lange durch $() obsolet.)

Grüße, Benno

cryptsetup open --type plain --cipher aes-xts-plain64 /dev/kaputt cryptkaputt

ist sicher leichter zu merken als dmsetup create, macht aber ganz das gleiche.

LUKS ist sicher noch einfacher aber LUKS überschreibt den Bereich 130kb-2M nicht.

Das Cryptdev mit Nullen vollschreiben:

shred -v -n 0 -z /dev/mapper/cryptkaputt

Durch die Verschlüsselung werden Zufallsdaten draus. shred ist mir allgemein viel lieber als wipe: ist praktisch überall installiert, nicht so viel kryptische Optionen mit so wenig Wirkung. Arbeitet mit voller Plattengeschwindigkeit und hat auch ne Fortschrittsanzeige.

Anschließend wieder einlesen. So kann man verifizieren daß auch tatsächlich alles überschrieben wurde.

cmp /dev/mapper/cryptkaputt /dev/zero
# oder
hexdump -C /dev/mapper/cryptkaputt | head

Wenn man sowieso nix verifizieren will ist es viel einfacher:

shred -v -n 1 /dev/kaputt

Und bei ner SSD kann man sich das überschreiben sowieso sparen:

blkdiscard /dev/kaputt

Es sei denn man ist paranoid und dann ist man wieder oben beim cryptsetup.

Habe es mal mit einem USB-Stick (3.0) angeschlossen an einem USB-2.0 Port getestet, /dev/urandom scheint ja wirklich sehr langsam zu sein:

1
2
3
4
5
6
7

USER@USER:~/Desktop $ sudo dd if=/dev/urandom of=/dev/sda bs=8M
[sudo] password for USER: 
dd: Fehler beim Schreiben von „/dev/sda“: Auf dem Gerät ist kein Speicherplatz mehr verfügbar
1876+0 Datensätze ein
1875+0 Datensätze aus
15728640000 Bytes (16 GB) kopiert, 7107,67 s, 2,2 MB/s
USER@USER:~/Desktop $ 

Fast zwei volle Stunden. Warum eigentlich ein Datensatz mehr ein als aus?

lubuntu-lulu schrieb:

/dev/urandom scheint ja wirklich sehr langsam zu sein:

Ab Kernel 4.8 nicht mehr, da fluppt es dann mit 300MB/s.

Fast zwei volle Stunden.

Ist wohl dem USB Stick anzulasten (bloss weil 3.0 draufsteht sind die noch lange nicht schnell und schon gar nicht bei hohem Schreibaufkommen - selbst viele SSD brechen da ein weil nur kleiner Schreibcache vorhanden), oder es ist eine besonders lahme CPU. Und bs=8M ist einfach zuviel, bleib bei bs=1M. Mach mal mit status=progress und of=/dev/null.

Warum eigentlich ein Datensatz mehr ein als aus?

Zu dem Zeitpunkt wo das Gerät "no space left on device" meldet hat dd schon den Datensatz eingelesen. Daher hat man da praktisch immer eins mehr gelesen als geschrieben.

Wo das nicht passieren darf ist wenn du eine ISO auf einen USB Stick schreibst. Die muss ja komplett draufpassen.

Ja, meine CPU ist natürlich unterirdisch (Netbook IntelAtom).

Danke, werde es mal mit anderen Werten ausprobieren - nur status=progress funktionierte bei mir beim ersten Mal nicht deswegen ließ es weg. Welche dd Version nutzt ihr? Oder ich tippte/kopierte was falsch aus diesem Thread.

Kann gut sein daß status=progress erst in Ubuntu 16.04 funktioniert. Kaum hat man sich an eine "neue" Funktion gewöhnt, denkt man gar nicht mehr dran. 😉

Vielleicht kann es ja in älteren Versionen so klappen (habe ich auf einem Technikblog gefunden):

Der Löschprozess kann maßgeblich beschleunigt werden, wenn man den Buffer (internen Zwischenspeicher) der Festplatte ausnutzt. Wie groß dieser für die aktuelle Platte ist, kann mit hdparm -i /dev/sdX herausgefunden werden. Hier ist es der Wert BufferSize=, welcher exakt so (ohne kB) für den dd Parameter bs übernommen werden kann. Zudem kann der Löschprozess in den Hintergrund gelegt werden, um während der Durchführung des Löschvorgangs eine Fortschrittsanzeige auszugeben:

Für die erste Festplatte /dev/sdX mit 8 MiB Puffergröße sieht dass dann so aus:

1	dd if=/dev/zero of=/dev/sdX bs=8M & pid=$!

Um nun die Fortschrittsanzeige auszugeben, kann folgendes Kommando auf der selben Konsole eingegeben werden:

1	while true; do kill -USR1 $pid && sleep 1 && clear; done