Exakt. Aber wenn es wirklich darum ging auf Funktionstüchtigkeit zu prüfen (und nicht auf Schreibgeschwindigkeit oder so) wäre schlechtblöcke (badblocks) im nichtdestruktiven Modus und bei ausgehängter Partition das bessere Werkzeug. Und sehr, SEHR viel langwieriger.
Danke für den Hinweis. Ich wusste, dass es Tools gibt, die „richtig” prüfen, ob eine Festplatte gut ist. So weit vertraue ich aber meinem Händler. Ich teste gerade hauptsächlich, ob die Kapazität wirklich korrekt angegeben wurde oder ob das Ding nach einem Terabyte wieder Daten überschreibt. Und ob sich sonst irgendwas Komisches bemerkbar macht.
Die Festplatte soll eigentlich nur das Internet cachen, also kommt es nicht einmal darauf an, dass die Blöcke gut sind.
Lieber nicht. random ist kryptografisch guter, “echter” Zufall. Wenn die Enthropie im System leer ist, blockiert das und man kann dann erst wieder lesen, wenn genug neue Enthropie vorhanden ist. urandom ist ein auf random basierender Pseudozufall, der niemals blockiert und schnell Daten liefert.
Oh. Ich wusste nicht, dass einem irgendwo die Entropie ausgehen kann. Klingt irgendwie sehr unphysikalisch (nicht, dass ich was davon verstünde). Woher weiß dass System denn, wann sie weg ist, und wie kommt sie wieder zurück?
Enthropie wird aus u.a. sowas wie Mausbewegung und Tastatureingaben gewonnen. Was genau die Quellen sind, weiß ich aus dem Stehgreif nich.
Ich hatte es schon, daß bei einem frisch gebooteten RasPi bei der ssh-key-erzeugung die Enthropie alle war und ich erstmal auf der Tastatur rumrollen musste, bis es weiter ging. Ist aber ne Weile her (4er Kernel)
Auf 'nem normalen Desktop gibt es vermutlich genug andere Quellen oder da hat sich was an der Implementierung geändert, aber ich habe gerade testhalber problemlos 50GB aus /dev/random gelesen… Vermutlich isses also einfach egal. :-)
Heute habe ich gelernt, dass es Informationsentropie (ohne h) gibt.
https://de.wikipedia.org/wiki/Entropie_(Informationstheorie)
Aber wie man die in einem Computer verringern kann , indem man sie zum verschlüsseln verwendet o.ä., erschließt sich mir trotzdem nicht.
Entropie kann nicht vernichtet werden. Ein Prozess, bei dem Entropie entstanden ist, kann nicht rückgängig gemacht (und somit die Entropie wieder auf den gleichen Wert erniedrigt) werden, ohne dass dabei eine größere Entropie an die Umgebung des betreffenden Systems abgegeben wird. Mit anderen Worten, selbst wenn der ursprüngliche Zustand des Systems wiederhergestellt werden kann, wäre nun die Umgebung in einem Zustand größerer Entropie als vorher. Eine spurlose Rückkehr zum alten Zustand von System und Umgebung ist daher unmöglich. Weil alle spontanen thermodynamischen Prozesse Entropie erzeugen, werden sie auch als irreversibel (= unumkehrbar) bezeichnet.
Soweit der physikalische Begriff - mit dem passt das jdfalls nicht zusammen
Manche Prozesse sind darauf angewiesen, zufällige Zahlen zu erhalten (z.B. Verschlüsselung, Mensch ärgere dich nicht). Für die Sicherheit der Prozesse ist es enorm wichtig, dass die Zufallszahlen tatsächlich vollkommen zufällig sind. Anderenfalls könnte ein Angreifer beim Mensch ärgere dich nicht schummeln.
Der Linux-Kernel produziert anhand eines Algorithmus eine unendlich lange Reihe zufälliger Zahlen, wenn man ihn darum bittet. (Das ist das cat /dev/random von oben). Der Algorithmus ist allerdings bekannt und deterministisch. Daraus lassen sich also keine echt zufälligen Zahlen generieren.
Um echt zufällige Zahlen zu erhalten, muss der Algorithmus geseedet, also mit echten Zufallszahlen gefüttert werden. Diese initialen Zufallszahlen generiert der Kernel aus verschiedenen Quellen, die hoffentlich nicht vorhersagbar sind. Ich habe keine gute Quelle gefunden, welche das sind, aber oft werden die Tastaturanschläge, Mausbewegungen und die über das Netzwerk eingehenden Nachrichten genannt.
(Bis hier bin ich mir ziemlich sicher, Recht zu haben. Der Rest ist Hypothese.)
Je mehr solcher Ereignisse vom System verwurstet wurden, desto unsicherer ist sein interner Zustand für einen potentiellen Angreifer – das System hat also eine hohe Informationsentropie. Da der Algorithmus zur Zufallszahlengewinnung weiterhin deterministisch ist, kann aus einem Seed nur eine gewisse Anzahl an zufälligen Zahlen gewonnen werden, bevor ein Angreifer wieder die nächsten Zahlen vorhersagen kann.
Deshalb müssen immer wieder neue Seeds benutzt werden, die aus dem Entropiespeicher gewonnen werden. Je mehr Seeds erzeugt werden, desto mehr weiß ein Angreifer wieder über den Zustand des Entropiespeichers. Die Entropie nimmt also ab. Schließlich, wenn die Maus nicht bewegt wurde, keine Tasten gedrückt wurden und keine Aktivität auf dem Netzwerk war, gibt es nicht mehr genug Entropie im Speicher, um noch sichere Zufallszahlen zu generieren. Der Speicher ist leer. Will man dann weitere Zahlen abfragen, bleibt die Abfrage buchstäblich hängen, bis man den Entropiespeicher wieder ausreichend gefüllt hat.
Google filmt übrigens ein Regal voller Lavalampen und gewinnt aus den chaotischen Bewegungen der Lava die Informationsentropie, die es für seine Zufallszahlen braucht.
Die verfügbage Entropie nimmt zumindest bei mir nicht ab. $ cat /dev/random > /dev/null & watch cat /proc/sys/kernel/random/entropy_avail bleibt bei 256 kleben.
Exakt. Aber wenn es wirklich darum ging auf Funktionstüchtigkeit zu prüfen (und nicht auf Schreibgeschwindigkeit oder so) wäre schlechtblöcke (
badblocks) im nichtdestruktiven Modus und bei ausgehängter Partition das bessere Werkzeug. Und sehr, SEHR viel langwieriger.Danke für den Hinweis. Ich wusste, dass es Tools gibt, die „richtig” prüfen, ob eine Festplatte gut ist. So weit vertraue ich aber meinem Händler. Ich teste gerade hauptsächlich, ob die Kapazität wirklich korrekt angegeben wurde oder ob das Ding nach einem Terabyte wieder Daten überschreibt. Und ob sich sonst irgendwas Komisches bemerkbar macht.
Die Festplatte soll eigentlich nur das Internet cachen, also kommt es nicht einmal darauf an, dass die Blöcke gut sind.
Aah OK. Mache ich so ähnlich auch gern bei dubiosen Speichermedien, wo es nur so halb drauf ankommt.
Wäre ja in dem Fall sogar übertrieben zu gucken, ob korrekt geschrieben wurde.
# blocksize 1M * 1k = 1G file dd if=/dev/urandom bs=1M count=1k status=progress | tee random.junk | md5sum md5sum random.junk(Prüfsummen sollten identisch sein)
Danke für die Idee. Hab’s ein bisschen weiter automatisiert.
#!/bin/bash set -euo pipefail OUTDIR="/mnt/HDD" COUNT=2621440 for i in $(seq 1 28); do outfile="$(mktemp -p ${OUTDIR})" checksum=$(dd if=/dev/random bs=4096 count=${COUNT} status=none | tee "$outfile" | sha256sum) filename="$(realpath --relative-to=${OUTDIR} ${outfile})" echo "${checksum/-/${filename}}" >> "${OUTDIR}/sums" done sha256sum -c "${OUTDIR}/sums"Nettes Skript. Ich würde aber das normale random nehmen statt urandom. Das ist zufällig genug.
Lieber nicht. random ist kryptografisch guter, “echter” Zufall. Wenn die Enthropie im System leer ist, blockiert das und man kann dann erst wieder lesen, wenn genug neue Enthropie vorhanden ist. urandom ist ein auf random basierender Pseudozufall, der niemals blockiert und schnell Daten liefert.
Oh. Ich wusste nicht, dass einem irgendwo die Entropie ausgehen kann. Klingt irgendwie sehr unphysikalisch (nicht, dass ich was davon verstünde). Woher weiß dass System denn, wann sie weg ist, und wie kommt sie wieder zurück?
Enthropie wird aus u.a. sowas wie Mausbewegung und Tastatureingaben gewonnen. Was genau die Quellen sind, weiß ich aus dem Stehgreif nich.
Ich hatte es schon, daß bei einem frisch gebooteten RasPi bei der ssh-key-erzeugung die Enthropie alle war und ich erstmal auf der Tastatur rumrollen musste, bis es weiter ging. Ist aber ne Weile her (4er Kernel)
Auf 'nem normalen Desktop gibt es vermutlich genug andere Quellen oder da hat sich was an der Implementierung geändert, aber ich habe gerade testhalber problemlos 50GB aus
/dev/randomgelesen… Vermutlich isses also einfach egal. :-)Heute habe ich gelernt, dass es Informationsentropie (ohne h) gibt. https://de.wikipedia.org/wiki/Entropie_(Informationstheorie) Aber wie man die in einem Computer verringern kann , indem man sie zum verschlüsseln verwendet o.ä., erschließt sich mir trotzdem nicht.
Soweit der physikalische Begriff - mit dem passt das jdfalls nicht zusammen
Ich kann dir auch nur grob die Idee erläutern.
Manche Prozesse sind darauf angewiesen, zufällige Zahlen zu erhalten (z.B. Verschlüsselung, Mensch ärgere dich nicht). Für die Sicherheit der Prozesse ist es enorm wichtig, dass die Zufallszahlen tatsächlich vollkommen zufällig sind. Anderenfalls könnte ein Angreifer beim Mensch ärgere dich nicht schummeln.
Der Linux-Kernel produziert anhand eines Algorithmus eine unendlich lange Reihe zufälliger Zahlen, wenn man ihn darum bittet. (Das ist das
cat /dev/randomvon oben). Der Algorithmus ist allerdings bekannt und deterministisch. Daraus lassen sich also keine echt zufälligen Zahlen generieren.Um echt zufällige Zahlen zu erhalten, muss der Algorithmus geseedet, also mit echten Zufallszahlen gefüttert werden. Diese initialen Zufallszahlen generiert der Kernel aus verschiedenen Quellen, die hoffentlich nicht vorhersagbar sind. Ich habe keine gute Quelle gefunden, welche das sind, aber oft werden die Tastaturanschläge, Mausbewegungen und die über das Netzwerk eingehenden Nachrichten genannt.
(Bis hier bin ich mir ziemlich sicher, Recht zu haben. Der Rest ist Hypothese.)
Je mehr solcher Ereignisse vom System verwurstet wurden, desto unsicherer ist sein interner Zustand für einen potentiellen Angreifer – das System hat also eine hohe Informationsentropie. Da der Algorithmus zur Zufallszahlengewinnung weiterhin deterministisch ist, kann aus einem Seed nur eine gewisse Anzahl an zufälligen Zahlen gewonnen werden, bevor ein Angreifer wieder die nächsten Zahlen vorhersagen kann.
Deshalb müssen immer wieder neue Seeds benutzt werden, die aus dem Entropiespeicher gewonnen werden. Je mehr Seeds erzeugt werden, desto mehr weiß ein Angreifer wieder über den Zustand des Entropiespeichers. Die Entropie nimmt also ab. Schließlich, wenn die Maus nicht bewegt wurde, keine Tasten gedrückt wurden und keine Aktivität auf dem Netzwerk war, gibt es nicht mehr genug Entropie im Speicher, um noch sichere Zufallszahlen zu generieren. Der Speicher ist leer. Will man dann weitere Zahlen abfragen, bleibt die Abfrage buchstäblich hängen, bis man den Entropiespeicher wieder ausreichend gefüllt hat.
Google filmt übrigens ein Regal voller Lavalampen und gewinnt aus den chaotischen Bewegungen der Lava die Informationsentropie, die es für seine Zufallszahlen braucht.
https://www.man7.org/linux/man-pages/man4/urandom.4.html
Die verfügbage Entropie nimmt zumindest bei mir nicht ab.
$ cat /dev/random > /dev/null & watch cat /proc/sys/kernel/random/entropy_availbleibt bei 256 kleben.Oh. Ich habe die beiden verwechselt.