Warum ist GNU-Shred schneller als dd, wenn ein Laufwerk mit zufälligen Daten gefüllt wird?

8474

Beim sicheren Löschen einer Festplatte vor der Außerbetriebnahme fiel mir auf, dass dies dd if=/dev/urandom of=/dev/sdafast einen ganzen Tag shred -vf -n 1 /dev/sdadauert, wohingegen derselbe Computer und das gleiche Laufwerk nur wenige Stunden benötigen.

Wie ist das möglich? Ich denke, dass der Engpass der begrenzte Output von ist /dev/urandom. Verwendet Shred einen Pseudo-Zufallsgenerator, der weniger zufällig und nur für seinen einzigen Zweck (dh effizienter) als ausreichend ist urandom?

8
Beachten Sie, dass die beste Option zum Löschen von Laufwerken, insbesondere von SSD-Laufwerken, der Befehl zum sicheren Löschen von SATA ist. Jede andere Option - außer Zerstörung - wird fehlschlagen. Es ist auch viel schneller und dauert auf einer SSD nur Sekunden. Maarten Bodewes vor 8 Jahren 0

2 Antworten auf die Frage

10
RedGrittyBrick

Shred verwendet einen internen Pseudozufallsgenerator

Standardmäßig verwenden diese Befehle einen internen Pseudozufallsgenerator, der durch eine kleine Menge Entropie initialisiert wird. Sie können jedoch mit der Option --random-source = file zur Verwendung einer externen Quelle angewiesen werden. Ein Fehler wird gemeldet, wenn die Datei nicht genügend Bytes enthält.

Beispielsweise kann die Gerätedatei / dev / urandom als Quelle für Zufallsdaten verwendet werden. In der Regel sammelt dieses Gerät Umgebungsgeräusche von Gerätetreibern und anderen Quellen in einen Entropiepool und verwendet den Pool zum Erzeugen von Zufallsbits. Wenn der Pool zu wenig Daten enthält, verwendet das Gerät den internen Pool erneut, um mithilfe eines kryptografisch sicheren Pseudozufallszahlengenerators mehr Bits zu erzeugen. Beachten Sie jedoch, dass dieses Gerät nicht für die Massengenerierung von Zufallsdaten konzipiert ist und relativ langsam ist .

Ich bin nicht davon überzeugt, dass zufällige Daten ist jede effektiver als einem einzigen Durchlauf von Nullen (oder einem anderen Byte - Wert) bei dem Stand der Inhalt verschleiern.

Um ein Laufwerk sicher außer Betrieb zu setzen, verwende ich einen großen Magneten und einen großen Hammer.

2
jpalecek

Ich denke, es würde eher durch die ddVerwendung kleinerer Blöcke zum Schreiben der Daten verursacht werden. Versuchen Sie dd if=... of=... bs=(1<<20)zu sehen, ob es besser funktioniert.

Ich werde das bei der nächsten Gelegenheit versuchen und die Ergebnisse veröffentlichen. vor 12 Jahren 0
Die voreingestellte `dd'-Blockgröße ist 512. Sie wurde auf meinem Computer weit unterhalb der Festplattengrenzen ausgeführt. Piotr Findeisen vor 10 Jahren 0
/ dev / urandom ist wahrscheinlich ziemlich schnell - die dd-Blockgröße ist fast sicher das Problem. Dan Pritts vor 10 Jahren 0
Wenn Sie die Blockgröße erhöhen, scheint es, als könnte `/ dev / urandom` zu einem Engpass werden. Ich teste einige SSD-Laufwerke über USB 3.0 und mit dem gleichen` dd'-Befehl bekomme ich 326 MB / s für `if = / dev / zero` aber nur 12,8 MB / s für `if = / dev / urandom` austinmarton vor 9 Jahren 2

Verwandte Probleme