Frage Gibt es eine Alternative zu / dev / urandom?


Gibt es einen schnelleren Weg als / dev / [u] zufällig? Manchmal muss ich Dinge tun wie

cat / dev / urandom> / dev / sdb

Die Zufallsgeräte sind "zu" sicher und leider zu langsam dafür. Ich weiß, dass es da ist wipe und ähnliche Tools zum sicheren Löschen, aber ich nehme an, dass es in Linux auch einige Mittel dazu gibt.


21
2018-05-08 19:22


Ursprung


Äquivalent zu StackOverflow: stackoverflow.com/questions/841356/... - David Z
mögliches Duplikat von Schnellste und sicherste Methode zum Löschen einer Festplatte? - Kyle Brandt♦
Ist das nicht ein besserer Weg, dies zu tun? Vielleicht ein Anwärter auf den UUoC Award? - Tom O'Connor


Antworten:


Wenn Sie eine "sichere" Löschung einer Festplatte (oder einer Datei) vornehmen möchten, sollten Sie sich das Dienstprogramm "Shred" ansehen.

Wie die früheren Poster zeigen, sollen die / dev / * - Zufallsgeräte als Quelle für kleine Stücke zufälliger Daten verwendet werden.


12
2018-05-08 19:34



Laut der Manpage verwendet 'shred' / dev / urandom. Obwohl es eine gute Antwort für das Löschen der Festplatte ist, wird es keine Beschleunigung gegenüber anderen Techniken bieten, die von / dev / urandom lesen. (Ein weiterer Tipp, wenn 'shred' verwendet wird: Die meisten Leute werden wahrscheinlich mit 1-2 Pässen glücklicher sein, als die gigantische Standardzählung, so dass ein Wischen nicht Tage dauert.) - gojomo
Eigentlich ist Shred ist viel schneller als / dev / urandom. Meine Vermutung ist, dass es seine eigenen Pseudozufallsdaten mit / dev / urandom oder / dev / random als Seed liefert. - thomasrutter


Leider hat Linux eine schlechte Implementierung von Urandom. Sie könnten aes256-ctr mit einem zufälligen Schlüssel verwenden und mehrere hundert Megabyte Pseudozufälligkeit pro Sekunde erhalten, wenn Ihre CPU AES-NI (Hardwarebeschleunigung) unterstützt. Ich freue mich auf den Wechsel zu einem modernen Ansatz.

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

Dieser Welpe hat 1,0 GB / s auf meiner Box (im Vergleich zu 14 MB / s / Dev / Urandom). Es verwendet urandom nur, um ein zufälliges Passwort zu erstellen, und führt dann eine sehr schnelle Verschlüsselung von / dev / zero unter Verwendung dieses Schlüssels durch. Dies sollte eine kryptographisch sichere PRNG sein, aber ich werde keine Garantien geben.


24
2017-08-09 15:25



Danke für diese tolle Antwort, ich konnte von 9,5 MB / s mit / dev / urandom auf über 120 MB / s mit openssl aufsteigen. - GDR
Bis auf die erste Aussage, dass Linux hat eine schlechte Implementierung von UrandomIch stimme dieser Antwort zu. Gut genug, um eine Festplatte vor der Verschlüsselung zu löschen (oder zu füllen?). - Vikrant Chaudhary
Durchlaufen pv für eine schöne Fortschrittsanzeige. openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" -nosalt < /dev/zero | pv -pterb > /dev/sdb. - Vikrant Chaudhary
@VikrantChaudhary urandom produziert qualitativ hochwertige Pseudozufallszahlen, sicher, aber das ist keine Entschuldigung dafür, langsam zu sein. Der AES-Counter-Modus ist viel schneller und es ist schwierig zu argumentieren, wie es weniger sicher wäre als / dev / urandom. - Perseids
Nur um das hinzuzufügen pvEmpfehlung, zu der Sie pipen können pv -pterb -s $(blockdev --getsize64 /dev/sdb) >/sdb haben pv zeige dir den Fortschritt in Richtung des Schreibvorgangs. - asciiphil


In einem schnellen Test unter Ubuntu 8.04 auf einem Thinkpad T60p mit T2500 CPU, 1GB zufällige Daten aus openssl rand war 3-4x schneller als /dev/urandom. Das ist,

time cat /dev/urandom | head -c 1000000000 > /dev/null

... war ca. 4 Minuten während ...

time openssl rand 1000000000 | head -c 1000000000 > /dev/null

... war etwas über 1 Minute.

Nicht sicher, ob es einen Unterschied in der Random-Qualität gibt, aber für HD-Wiping ist wahrscheinlich beides in Ordnung.


7
2018-06-01 05:41





Ich sehe viele Antworten, die sagen, dass die Verwendung von Zufallsdaten nicht wichtig ist. Das ist ziemlich wahr, wenn Sie nur versuchen, das Laufwerk zu löschen, aber nicht so sehr, wenn Sie es in Vorbereitung auf die Festplattenverschlüsselung löschen.

Wenn Sie ein Gerät mit nicht zufälligen Daten füllen und dann eine verschlüsselte Partition darauf platzieren, könnte es zu einem Problem kommen. Der Teil des Laufwerks, auf dem verschlüsselte Daten gespeichert sind, hebt sich vom Rest des Laufwerks ab, da die verschlüsselten Daten zufällig aussehen und der Rest nicht. Dies kann verwendet werden, um Informationen über die Kryptoplatte zu bestimmen, die beim Cracken verwendet werden könnten. Der unten stehende Link erklärt die Theorie dahinter, wie einige der häufigsten Angriffe funktionieren und wie man sich gegen sie verteidigen kann (jedenfalls unter Linux).

Linux Festplattenverschlüsselungseinstellungen


5
2017-12-13 20:14



Sehr richtig. Bei relativ modernen Festplatten (> 20 GB) reicht ein Überschreiben einzelner Passwörter aus. Selbst der NSA und Co. würden sich schwer tun, eine nennenswerte Menge an Daten vom Laufwerk zu bekommen. Und es ist sehr teuer. Denken Sie an $ 100.000 pro Megabyte. Die Bemerkung über Verschlüsselung ist sehr wahr. Sie möchten, dass die nicht verwendeten Teile der Platte "so zufällig" wie die verwendeten Teile aussehen. - Tonny
Verwürfelt Ihre Geräteverschlüsselungssoftware nicht die gesamte Festplatte? - Nathan Garabedian


Wenn Sie eine HD sicher abwischen müssen, gibt es ein Tool sehr mächtig: DBAN


5
2017-08-09 15:55





Wenn Sie ein riesiges Blockgerät löschen wollen, dann habe ich festgestellt, dass es robuster ist dd und der Gerätezuordner anstelle der Ausgabeumleitung von Zufallsdaten. Das Folgende wird zugeordnet /dev/sdb zu /dev/mapper/deviceToBeErased Ein- und Entschlüsseln dazwischen. Um das Gerät am verschlüsselten Ende aufzufüllen, werden Nullen in die Nur-Text-Seite des Mappers kopiert (/dev/mapper/deviceToBeErased).

cryptsetup --cipher aes-xts-plain64 --key-file /dev/random --keyfile-size 32 create deviceToBeErased /dev/sdb
dd if=/dev/zero of=/dev/mapper/deviceToBeErased bs=1M

Die verschlüsselten Daten auf /dev/sdb ist garantiert nicht von zufälligen Daten zu unterscheiden, wenn es keine gibt ernst Schwäche in AES. Der Schlüssel verwendet wird aus abgegriffen /dev/random (Mach dir keine Sorgen - es verwendet nur 32 Bytes).


5
2018-02-16 01:00





check fragand

http://billauer.co.il/frandom.html

Laut meinem Test ist es am schnellsten


4
2017-07-08 20:05



Frandom sollte nicht mehr als kryptographisch sicher betrachtet werden, da RC4 verwendet wird. Sehen blog.cryptographyengineering.com/2013/03/... ein Beispiel für einen praktischen Grenzangriff (!) auf TLS bei Verwendung von RC4. - Perseids


Je schneller Ihr Werkzeug ist, desto unsicherer wird das Ergebnis. Eine gute Zufälligkeit zu erzeugen, braucht Zeit.

Wie auch immer, du könntest sowas benutzen dd if = / dev / zero von = / dev / sdb, aber offensichtlich wird das nicht zufällig sein, es wird viel schneller gelöscht werden.

Eine andere Möglichkeit könnte sein, diese Methode zu verwenden / sbin / badblocks -c 10240 -s -w -t random -v / dev / sdb es ist schneller als der Zufall, aber der Badblocks PRNG ist weniger zufällig.


2
2018-05-08 19:28



und ehrlich - das ist es Vielfach der Sicherheit für das Laufwerk - warren
Mehrere Überschreibungen, wie Shred, benötigt Zeit und bietet mehr Sicherheit als ein Überschreiben von "perfekt" zufälligen Daten. - Dennis Williamson
"Je schneller Ihr Werkzeug ist, desto weniger sicher ist das Ergebnis. Die Erzeugung einer guten Zufälligkeit erfordert Zeit." - Das ist nicht wahr. Ein AES-Zählermodus- (Pseudo-) Zufallszahlengenerator ist viel besser analysiert und um Größenordnungen schneller als / dev / urandom. (Siehe Tronic's Antwort.) - Perseids


/dev/random verwendet eine große System-Entropie und erzeugt daher nur einen langsamen Datenstrom.

/dev/urandom ist weniger sicher und schneller, aber es ist immer noch auf kleinere Datenblöcke ausgerichtet - es ist nicht dazu gedacht, einen kontinuierlichen Strom von Hochgeschwindigkeits-Zufallszahlen bereitzustellen.

Du solltest einen PRNG deines eigenen Designs machen, und es mit etwas von säen /dev/random oder /dev/urandom. Wenn Sie es etwas zufälliger benötigen, säen Sie es regelmäßig - alle paar MB (oder was auch immer die Länge Ihres prng ist). Das Erhalten von 4 Bytes (32-Bit-Wert) von Urandom oder Random ist schnell genug, dass Sie dies alle 1k Daten tun können (resed Ihre Prng alle 1k) und sehr zufällige Ergebnisse erhalten, während Sie sehr, sehr, schnell gehen.

-Adam


2
2018-05-08 19:29



Es ist sehr selten, dass jemand seinen eigenen Zufallszahlengenerator schreiben kann, der besser ist als solche, die bereits verfügbar sind. In den meisten Fällen ist das Ergebnis ein vorhersehbares Muster und ein falsches Sicherheitsgefühl. Ich würde empfehlen, Shred auf einem Laufwerk über seinen / dev-Eintrag oder eine sehr gründliche physische Zerstörung zu verwenden. - Dennis Williamson
Genau. Ich würde shred verwenden, das standardmäßig urandom verwendet (was ich ehrlich gesagt nicht langsam finde). Als Anmerkung ist es möglich, / dev / random mit shred (durch Angabe von --random-source = / dev / random) zu verwenden, wenn Sie sehr geduldig sind. - Matthew Flaschen


Wenn Sie eine Festplatte schnell löschen möchten, schreiben Sie nicht-zufällige Daten darauf. Dies ist nicht weniger sicher als die Verwendung von Zufallsdaten. In jedem Fall können die Originaldaten bei Anschluss an einen Computer nicht gelesen werden. Überschreiben von Festplatten-Daten: Die große Abwischkontroverse zeigt, dass die Originaldaten auch nicht mit einem Mikroskop gelesen werden können.


2
2017-07-08 20:40