ubuntuusers.de

Mit /dev/null und bs=1M:

1
2
3
4
5
6

USER@USER:~ $ sudo dd if=/dev/zero of=/dev/sda bs=1M
dd: Fehler beim Schreiben von „/dev/sda“: Auf dem Gerät ist kein Speicherplatz mehr verfügbar
15001+0 Datensätze ein
15000+0 Datensätze aus
15728640000 Bytes (16 GB) kopiert, 877,603 s, 17,9 MB/s
USER@USER:~ $ 

Also gute 14 Minuten.

Ich habe mich jetzt mal heran gewagt und es mit erst mal mit einem Stick versucht. Ich versuche die schnellere Methode, weil(u)random ja bei mir zu langsam war.

Ich habe einen nicht-formatierten USB-Stick.

Also fing ich an ihn mit LUKS zu verschlüssenln:

sudo cryptsetup luksFormat -c aes-xts-plain64
-s 512 -h sha512 -y /dev/sdx

sudo cryptsetup luksOpen /dev/sdx usb-crypt 

Habe ich das richtig verstanden, dass wir diese erstellte verschlüsselte LUKS-Partition (/Gerät) nun nicht mit einem Dateisystem formatieren müssen. Wir füllen sozusagen nur das LUKS-Gefäß/Partition,stimmt's? Denn wenn ich es richtig verstand, dann wissen LUKS, die Formatierung usw. gar nicht voneinander.. Muss man gesondert irgendwie darauf achten, dass der verschlüsselte Stick gemountet ist? Da unformatiert, sehe ich ihn ja auch nicht im PCManFM 😛

Vermutlich ist das ganze mal wieder viel einfacher als ich vermute. 😀

USER@USER:~$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda           8:0    1  14,6G  0 disk  
└─usb-crypt 254:0    0  14,6G  0 crypt

Jetzt also nur noch folgendes?

(sudo) dd if=/dev/zero of=/dev/mapper/usb-crypt bs=1M

(und nicht statt usb-crypt /dev/sda verwenden).

Erholsames Wochenende noch und danke für jegliche Geduld mit mir,

lubuntu-lulu

Ja. Da aber laut frostschutz der Anfang bei LUKS nicht mit genullt wird, solltest du das dann manuell nachholen. Er hatte ja einen besseren Befehl geliefert. Also dann noch z.B. (wieder reichlich für alle Eventualitäten gerüstet, ohne nachdenken, nachschauen oder untersuchen zu müssen) 10 MB von sdX statt sdX-crypt löschen, ggf. mit urandom statt zero, weil ohne LUKS. Damit zerstörst du auch das LUKS, weil du sdX zerstörst und es darin eingebettet ist.

Habe bs=1M verwendet, trieb aber meine CPU auf 100% Auslastung, so dass ich mit gksu lxtask dd killen musste (könnte mir vorstellen, dass das schädlich für den Datenträger ist).

EDIT:

USER@USER:~ $ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sde           8:64   0 931,5G  0 disk  
└─usbusbusb 254:1    0 931,5G  0 crypt 

USER@USER:~ $ sudo dd if=/dev/zero of=/dev/mapper/usbusbusb bs=64
[sudo] password for USER:

Dann in einem anderen Terminalfenster:
USER@USER:~ $ sudo kill -USR1 PID; sleep 1; kill PID
bash: kill: (PID) - Die Operation ist nicht erlaubt

5620609+0 Datensätze ein
5620609+0 Datensätze aus
359718976 Bytes (360 MB) kopiert, 122,495 s, 2,9 MB/s
9583681+0 Datensätze ein
9583681+0 Datensätze aus
613355584 Bytes (613 MB) kopiert, 210,111 s, 2,9 MB/s
12433496+0 Datensätze ein
12433496+0 Datensätze aus
795743744 Bytes (796 MB) kopiert, 282,547 s, 2,8 MB/s
24840930+0 Datensätze ein
24840930+0 Datensätze aus
1589819520 Bytes (1,6 GB) kopiert, 609,516 s, 2,6 MB/s

Die PID muss man schon erklären, also einsetzen.

wo PID steht, habe ich "natürlich" dd's PID eingesetzt ☺ Aber ohne das $ davor.

Aber sollte ich vlt. eine sehr hohen Buffer (bs=?M) nehmen, weil es so unglaublich langsam Nullen auf das luks gerät schrieb?

Eine wie hohe Zahl für den Buffer (bs=?M) kann ich denn verwenden, damit es schneller geht? Denn selbst mit 64M war es ziemlich langsam. Verliert man an Genauigkeit oder Sicherheit durch Verwendung einer höheren Zahl?

Bin mir nicht sicher ob ich es korrekt verstanden habe: Wir füllen nicht den LUKS-Mapper/Container mit Nullen sondern überschreiben ihn mit Nullen? Ich ging bis jetzt immmer davon aus, dass der mit Nullen schneller "gefüllt" wird als wenn man 1000gb Mp3 Dateien auf das eine verschlüsselte Parition schreiben würde. Wir wollen ja einen vollen Lukscontainer haben der die gesamte Festplatte belegt und wenn den LUKS Header/die ersten und letzten MBs dann löschen, sind alle vorher verschlüsselten Daten (unsere mp3s oder die Nullen von dd) nicht zu rekonstruieren. Egal ich habe es versucht zu verstehen, aber das wichtigste vorerst ist ja dass die Befehl funktionieren ☺

Ich liege mit dem "Befüllen mit Nullen" vermutlich komplett falsch und wir 'überschreiben' wirklich nur, weil müsste man nicht zum befüllen ein Gerät oder Partition mounten? Ich weiß, dass bei dem 'überschreiben' mit wipe ich die Partitionen nicht einhängen muss/darf.

shred -v -n 0 -z /dev/mapper/usb-crypt

Muss ich nun noch etwas verifizieren oder wurde auch der Anfang den LUKS nicht beschreibt überschrieben?

Sorry für meine Verwirrung, kann verstehen wenn eure Geduld am Ende ist.

lubuntu-lulu

Lies mal mount und dd - die Blockgröße ist im Prinzip egal, nur geschwindigkeitsrelevant. Nullen nimmt man, weil man keine 1 TB MP3 (wiederholend) vorhalten und übertragen muss.

lubuntu-lulu schrieb:

weil es so unglaublich langsam Nullen auf das luks gerät schrieb?

Du hast bs=64 (64 Bytes) benutzt, das ist kleiner als der Default (512 Bytes), richtig schnell wirds so ab 64K (65536 Bytes). 1M (1'048'576 Bytes) benutzt man weil das für Menschen die verständliche Größe ist.

Also wäre es wohl angebracht dd mit bs=600M oder so zu benutzen. Shred schreibt doch auch nur Nullen - ist aber nach ca. 2 Stunden auch nur so weit:

sudo shred -v -n 0 -z /dev/mapper/usbusbusb
shred: /dev/mapper/usbusbusb: Durchgang 1/1 (000000)...50GiB/936GiB 5%

möglicherweise liegt es einfach nur an der USB-Hardware.

Im Endeffekt braucht man anscheinend schon einigermaßen vernünftige Hardware zum "wipen", stimmt's?

Denn ich habe momentan leider nur "Steinzeit" Hardware: Netbook (1GB RAM,Intel-Atom) sowie einen Raspberry-Pi 2.

Ich habe jetzt shred, dd und wipe ausprobiert und auch verschiedene Buffer (bs=1M, bs=8M, bs=256M, bs=256, bs=500) ausprobiert, aber dd und shred benötigen immer zum einen viel zu viel CPU (100% Auslastung laut htop) und sind 'viel' zu langsam (wenn ich von ihrer Anfangsgeschwindigkeit ausgehe, werden dd/shred für 1TB sieben bis sogar 20 Tagen benötigen).

Mit wipe schaffte ich es vor ein paar Wochen mal 250GB in zwei Tagen zu wipen. Dabei wipete ich jede Partition einzeln (hätte natürlich auch den gesamten Datenträger auf einmal wipen können). Aber dd und shred sollen ja wohl auch die ersten/letzten Bytes überschreiben..bzw. sind genauer.

Ich nutzte shred & dd immer für das Beschreiben des LUKS-Gerätes mit Nullen.