Schnelle Möglichkeit, HD zu randomisieren?

Ich habe gelesen, wie Festplatten für die Verschlüsselung sicher gemacht werden, und einer der Schritte besteht darin, zufällige Bits auf die Festplatte zu schreiben, damit die verschlüsselten Daten nicht mehr von den übrigen Daten auf der Festplatte unterschieden werden können.

Als ich es jedoch dd if=/dev/urandom of=/dev/sdain der Vergangenheit versuchte , schien die ETA in der Größenordnung von Tagen zu liegen. Ich sah etwas über die Verwendung badblocksanstelle von Urandom, aber das schien nicht viel zu helfen. Ich möchte nur wissen, ob es irgendwelche Möglichkeiten gibt, die mir helfen könnten, dies zu beschleunigen, wie Optionen für ddoder etwas anderes, das mir möglicherweise fehlt, oder ob die Geschwindigkeit nur eine Einschränkung der HD ist.

dd if=/dev/urandom of=/dev/sdaoder einfach cat /dev/urandom >/dev/sda nicht der schnellste Weg, eine Festplatte mit zufälligen Daten zu füllen. Linux /dev/urandomist nicht das schnellste kryptografische RNG. Gibt es eine Alternative zu / dev / urandom?hat einige Vorschläge. Insbesondere enthält OpenSSL ein schnelleres kryptografisches PRNG:

openssl rand $(</proc/partitions awk '$4=="sda" {print $3*1024}') >/dev/sda

Beachten Sie, dass letztendlich die Verbesserung davon abhängt, welcher Teil der Engpass ist: die CPU oder die Festplatte.

Die gute Nachricht ist, dass das Befüllen der Festplatte mit zufälligen Daten meist unbrauchbar ist. Erstens, um einen gemeinsamen Mythos zu zerstreuen, Löschen mit Nullen auf der heutigen Hardware genauso gut . Mit der Festplattentechnologie der 1980er Jahre hinterließ das Überschreiben einer Festplatte mit Nullen eine geringe Restladung, die mit etwas teurer Hardware wiederhergestellt werden konnte. Es waren mehrere Überschreibungsdurchläufe mit zufälligen Daten (das "Gutmann-Wischen") erforderlich. Heutzutage hinterlässt bereits ein einziger Überschreibungsdurchgang mit Nullen Daten, die selbst unter Laborbedingungen nicht realistisch wiederhergestellt werden können.

Wenn Sie eine Partition verschlüsseln, ist es für die Vertraulichkeit der verschlüsselten Daten nicht erforderlich, die Festplatte mit zufälligen Daten zu füllen. Dies ist nur dann sinnvoll, wenn Sie den von verschlüsselten Daten belegten Speicherplatz von nicht belegtem Speicherplatz ununterscheidbar machen möchten. Wenn Sie ein verschlüsseltes Volume auf einem nicht zufälligen Container erstellen, erfahren Sie, welche Plattenblöcke jemals von dem verschlüsselten Volume verwendet wurden. Dies gibt einen guten Hinweis auf die maximale Größe des Dateisystems (obwohl es mit der Zeit immer schlechter wird) und wenig mehr.

Das OpenSL schien für mich nicht zu funktionieren. Ich habe "unbekannte Optionen" und andere Probleme mit den bereitgestellten Lösungen. Also bin ich mit dem Programm fio gelandet.

fio -name="fill" -ioengine=libaio -direct=1 -bs=512m -rw=write -iodepth=4 -size=100% -filename=/dev/md0

Die Ausführung von 19 TB auf 24 Festplatten scheint 3 Stunden zu dauern. Also rund 1.800 MB / s

smp-016:~ # fdisk -l /dev/md0
Disk /dev/md0: 18890.1 GB, 18890060464128 bytes

smp-016:~ # fio -name="fill" -ioengine=libaio -direct=1 -bs=512m -rw=write -iodepth=4 -size=100% -filename=/dev/md0
fill: (g=0): rw=write, bs=512M-512M/512M-512M/512M-512M, ioengine=libaio, iodepth=4
fio-2.2.10
Starting 1 process
Jobs: 1 (f=1): [W(1)] [2.7% done] [0KB/1536MB/0KB /s] [0/3/0 iops] [eta 03h:01m:11s]

Ich hoffe das sind eigentlich zufällige Daten. Die Manpage sagt fio "Default: Puffer mit zufälligen Daten füllen."http://linux.die.net/man/1/fio

Ich mache das nicht für Sicherheits- / Verschlüsselungszwecke, sondern versuche nur sicherzustellen, dass meine späteren Lesetests tatsächliche Daten und nicht nur Nullen sind. Derselbe Befehl fio kann für die SSD / NVMe-Vorkonditionierung verwendet werden. Da nur die Verwendung von / dev / zero dazu führen kann, dass die Komprimierung auf Plattenebene "betrügt", wie viel tatsächlich geschrieben wird. Obwohl ich eine hinzufügen würde-loops=2 Flagge , wenn es eine frische SSD für das Benchmarking ist.

Wenn Sie möchten, dass es sicher ist, können Sie möglicherweise die -randrepeat=bool Option verwenden, da hierdurch Option "Zufallszahlengenerator vorhersehbar festlegen, damit die Ergebnisse über mehrere Läufe hinweg reproduzierbar sind. Standardeinstellung: true." Umgeschaltet wird sicher, wie sicher das wäre.

Zusätzlich gibt es einige Festplatten der Enterprise-Klasse mit SED (Self Encrypting Drives), mit denen Sie den Verschlüsselungsschlüssel drehen können, um alle geschriebenen Daten sofort und sicher zu löschen.

Zuletzt habe ich in der Vergangenheit DBAN (auch bekannt als Dariks Boot and Nuke) verwendet, das über bootfähige CD- und USB-Optionen verfügt und ein Open-Source-Projekt ist, das auf SourceForge gehostet wird entfernt und nicht mehr wiederherstellbar "

Sie können OpenSSL veranlassen, /dev/zeromit einem zufälligen Kennwort zu verschlüsseln , wodurch annehmbare Pseudozufallsdaten sehr schnell bereitgestellt werden (sofern Ihre CPU die Beschleunigung unterstützt).

openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" -nosalt < /dev/zero | dd of=/dev/sda

Sie können dies durchleiten pv, um Fortschritt / ETA zu erhalten. Die Befehle, die ich gerade ausführe (in einer Root-Shell), sind:

DISK="sda"
DISKSIZE=$(</proc/partitions awk '$4=="'"$DISK"'" {print sprintf("%.0f",$3*1024)}')
apt-get install pv
openssl enc -aes-256-ctr -nosalt \
  -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" \
  < /dev/zero |
  pv --progress --eta --rate --bytes --size "$DISKSIZE" |
  dd of=/dev/"$DISK" bs=2M

Ich kam auf diese Idee aus dieser Antwort , nachdem ich das gleiche Problem hatte wie der irrationale John , der Gilles 'Antwort oben kommentierte . Dadurch erhöhte sich meine Löschgeschwindigkeit auf mein neues RAID-Array von 11 MB / s auf rund 300 MB / s, was eine Woche bis zu 10 Stunden in Anspruch nahm.

Ich werde hinzufügen, dass Sie in der Lage sein sollten, die kompliziertere Anweisung oben zu verwenden, aber es gibt einen Fehler, der es erlaubt , nur 16 MB Ausgabe zu produzieren. (Dieser Bug wurde im Januar 2016 abgelegt.)openssl rand #of_bytesopenssl enc ...ssl

Und gemäß der Antwort auf diese Frage und der Annahme, dass die CPU der Engpass ist, kann die Geschwindigkeit möglicherweise weiter gesteigert werden, indem mehrere parallele opensslProzesse auf separaten Kernen ausgeführt und mithilfe eines FIFO kombiniert werden.

Nach der Antwort von Marco benötigen Sie einen schnelleren Zufallsgenerator.

Sie verwenden ein einfaches Programm, das Zufallszahlen aus einer guten Bibliothek wie folgt wiedergibt boost::randomund diese in verwendet dd.

Wenn Sie Boost wählen, können Sie dieses Beispiel verwenden und die experimentFunktion an Ihre Bedürfnisse anpassen .

Der Flaschenhals ist weder die Blockgröße noch die Festplatte, sondern die langsame Erzeugung von Pseudozufallszahlen. /dev/urandomist um ein Vielfaches schneller als/dev/random da es einen Pool mit niedriger Entropie nicht blockiert.

Sie können dies bestätigen, indem Sie die Rohausgabe Ihrer Pseudozufallszahlen messen:

pv /dev/urandom >/dev/null

Diese Rate ist viel langsamer als die Schreibrate Ihrer Festplatte. Eine korrekte Lösung hängt ganz von der von Ihnen geforderten Sicherheitsstufe ab. Wenn Sie hohe Sicherheit benötigen, verwenden Sie entweder einen schnellen Hardware-Zufallsgenerator oder akzeptieren Sie die langsame Geschwindigkeit. Wenn Ihre Sicherheitsanforderungen nicht so hoch sind, können Sie ein paar Dutzend MB Daten erfassen und diese Zeichenfolge wiederholt auf das Laufwerk schreiben. Oder vielleicht sogar Nullen schreiben /dev/zeroist eine Option.

Zusammenfassung

/dev/random - sicher, sehr langsam
/dev/urandom- weniger sicher¹, langsames
Hardware-RNG - sicher, schnell, sehr teuer
( /dev/zero - überhaupt nicht zufällig, sehr schnell)

¹ _{Laut Ist ein Rand von / dev / urandom für einen Login-Schlüssel sicher? /dev/urandomist so sicher wie /dev/random. Vielen Dank an Gilles für diesen Hinweis.}

Ich habe versucht, eine externe 4-TB-USB-Festplatte zu füllen, dd if=/dev/urandom of=/dev/sdX status=progressdie viel zu langsam war (unabhängig von den bs=Einstellungen), und anscheinend opensslist die Anzahl der auszugebenden Zufallsdaten begrenzt (zumindest für Version 1.0.2p). Die beste Option, die ich gefunden habe, war der Kommentar von frostschutz zu verwenden shred, wie in:

shred -v -n 1 /dev/sdX

Stellen Sie sicher, dass Sie das verwenden, -n 1andernfalls wird das Gerät standardmäßig dreimal überschrieben (plus das, -vdas den Fortschritt anzeigt). Ich denke nicht, dass die Qualität der Pseudozufallszahlen so hoch ist, aber es reicht mir, eine tragbare Festplatte mit großer Kapazität für die Verschlüsselung vorzubereiten.