staging.inyokaproject.org

Das überschreiben mit Zufallszahlen dauert sehr lange, da /dev/urandom vergleichsweise langsam ist. Als Vorbereitung für eine spätere Datenträgerverschlüsselung sollten auch Pseudozufallszahlen (selbst urandom sollte größtenteils Pseudozufallszahlen enthalten) von einer Verschlüsselung reichen. Der ganze Prozess würde wesentlich schneller gehen, wenn man das Device kurzfristig mit einem temporären, zufälligen Schlüssel und dm-crypt AES-128 mountet und mit /dev/zero oder meinetwegen mit shred -vzn 0 <Gerät> mit Nullen füllt. Wäre das Ok bzw. sollte das in den Artikel oder auf einer neuen Seite?

Das verkompliziert die Sache allerdings.

Wenn man einfach den eigentlichen Crypt-Mapper vor Anlegen des Dateisystems mit Nullen überschreibt, spart man sich den Schritt... natürlich dauert es bei starkem Schlüssel dann länger. Vor allem kann das dann aber direkt bei den jeweiligen Verschlüsselungs-Artikeln stehen.

Hm, theoretisch sollte das kein Problem sein das endgültige Device mit Nullen zu überschreiben, aber andererseits hätte man dann sehr viele GB erratbaren Klartext, was mich persönlich stören würde.

Wer damit kein Problem hat, braucht auch nicht wirklich mit Nullen zu überschreiben, denke ich mal. ☺

Klar, guter Punkt - zumindest bis sich die Partition mit den ersten Daten füllt, und es durch die Schreibmethodik ein Glücksspiel wird, ob der Schlüsseltext nun von der angenommen 0, Dateisystemstrukturen oder Dateien stammt. Aber prinzipiell ist die Chance zu gut, ein großes Stück zusammenhängenden bekannten Klartext zu erwischen.

Wenn man den Datenträger gar nicht mit Zufallszahlen füllt, hat man eben mit den Dateisystemstrukturen eindeutig erkennbaren bekannten Klartext, da nur dort geschrieben wurde.

Da muss es doch eine elegantere Lösung geben.

Theoretisch könnte man einen Ein- oder Zweizeiler machen, der ein dm-crypt-Device mit Zufallspasswort erstellt und diese anschließen mit /dev/zero füllt und es dann wieder aushängt.

Die Zufallszahlen sollten für den Zweck ausreichen und es besteht keine Gefahr von "Known-Plaintext-Attacken", da das zu ermittelnde Passwort irrelevant wäre.

Erst danach wird halt das einzusetzende LUKS-Gerät erstellt. Ansonsten muss das ja auch nicht unter shred genannt werden sondern halt woanders. Andererseits wäre das ein wenig viel für jeden Verschlüsselungsartikel. Zu Not müsste man zum Überschreiben mit Zufallszahlen halt einen extra Artikel erstellen.

P=`cat /dev/urandom | head -c 32` && echo $P | cryptsetup -c aes-xts-plain -s 256 luksFormat <Gerät> && echo $P | cryptsetup luksOpen <Gerät> temp && P='' && shred -vzn 0 /dev/mapper/temp && sleep 2 && cryptsetup luksClose temp 

Mit dem Befehl sollte das funktionieren. Da dafür aber cryptsetup benötigt wird, würde es wohl den Rahmen von shred sprengen. Soll stattdessen die Zeile in jeden Verschlüsselungsartikel eingefügt werden?

Hallo,

Da dafür aber cryptsetup benötigt wird, würde es wohl den Rahmen von shred sprengen.

Genau. Abgesehen davon hat es genau genommen gar nichs mehr mit dem Programm shred zu tun ☺

Soll stattdessen die Zeile in jeden Verschlüsselungsartikel eingefügt werden?

-1 - das macht so gar keinen Sinn. Weil: du hast den gleichen Inhalt an X Stellen = Redundanz = böse.

Wenn überhaupt, dann mach dafür einen eigenen Artikel a la "Daten besonders sicher löschen" oder so ähnlich.

Gruß, noisefloor

Hm, eine Seite für einen Befehl?

Und es ist nicht super sicher, aber super schnell. Annähernd Festplattengeschwindigkeit, was man von urandom bei shred nicht gerade behaupten kann. Das dauert ein Vielfaches länger. Wer 500GB oder größer verschlüsseln möchte wird mit sehr großer Wahrscheinlichkeit bei shred abbrechen.

Ich habe den Befehl jetzt mal als Entwurf unter Baustelle/System verschlüsseln/Installation mit Schlüsselableitung eingetragen.

Hallo,

ein Topic - ein Thread. Hier geht es um shred.

Also mach bitte einen eigenen Thread dafür auf.

Danke. ☺

Gruß, noisefloor

Ist das so Ok und der Artikel wie gewünscht?

Gruß, unggnu

Hallo,

ja. Aufgrund der Kürze macht ein Platz unter Skripte Sinn.

Gruß, noisefloor

Der kann gerne verschoben werden, auch wenn es sich nicht um ein wirkliches Skript handelt. Also es wäre kein Problem als Skript, aber die Wirkung ist ein wenig zu desaströs um es als Skript rumfliegen zu haben und mal lustig die Devices auszuprobieren 😀

Gruß, unggnu

Dann nimm den Bearbeitungshinweis raus und wir schauen, ob bis zum Wochenende jemand Einwände hat. 😉

Hi ☺

Inhaltsverzeichnis fehlt (Link zur Datenrettung falls einer nicht aufmerksam genug die Warnungnen gelesen hat 😉 ) - ansonsten OK.

march schrieb:

Link zur Datenrettung falls einer nicht aufmerksam genug die Warnungnen gelesen hat 😉

Den Link kann man sich sparen - was überschrieben ist, ist unwiederbringlich weg. Egal ob Null, Zufall oder Pseudo-Zufall.

Wer kein Backup hat, die Warnungen überliest und dann Mist baut - dem ist im wahrsten Sinne des Wortes nicht mehr zu helfen.