Springe zum Hauptinhalt Profilbild Hartmut Goebel

Hartmut Goebel

Diplom-Informatiker, CISSP, CSSLP, ISO 27001 Lead Implementer



Anfrage
Logo Goebel Consult

Warum man die Performance von /dev/urandom kaum erhöhen kann

Ich baue momentan ein kleines NAS zum Server um. Mein Ziel ist, ein stromsparender kleinen Server für unserer Bürogemeinschaft. Natürlich müssen die Daten darauf verschlüsselt werden. Die Platte vorher mit Zufallsdaten zu beschreiben erweist sich als langwierig.

Ich baue momentan ein kleines NAS zum Server um. Mein Ziel ist, ein stromsparender kleinen Server für unserer Bürogemeinschaft. Natürlich müssen die Daten darauf verschlüsselt werden. Die Platte vorher mit Zufallsdaten zu beschreiben erweist sich als langwierig.

Dummerweise habe ich mir ein NAS empfehlen lassen, dass nicht von Haus aus verschlüsseln kann. Habe ich nicht aufgepasst. Dazu und zu anderen Unzulänglichkeiten des NAS ein andermal mehr. Ich hatte auch kurz die Idee, mir ein anderes zu kaufen, statt viel zeit hinein zu stecken. Aber wer weiß, ob ich da nicht vom Regen in die Traufe käme.

Das NAS ist gerootet, Debian ist installiert. Nun baue ich nach dieser Anleitung das verschlüsselte RAID. Die Anleitung ist kurz und gut, und die nötigen Befehle sind in zirka einer halben Stunde eingegeben.

Aber: Ein Schritt ist, die Platte mit Zufallsdaten zu beschreiben. Und das dauert ...
... und dauert ...
... und dauert ...
... und ich werde ungeduldig. Das muss man doch beschleunigen können?!

Zusammengefasst: Schneller geht nur mit schnellem Rechner.

Das Kommando

dd if=/dev/urandom of=/dev/md127 bs=10M

liefert auf dem NAS 1,8 MB/s, bei 2 TB macht das gute 300 Stunden also über 12 Tage. Urgs.

Also Platte ausgebaut, und per USB an den Desktop angeschlossen. Hier die Ergebnisse verschiedener Versuche (alle Messungen am Desktop):

of=/dev/md.. (also über RAID-Schicht)

3,8 MB/s

135 Stunden

5 1/2 Tage

of=/dev/md.. + Runlevel 0

4,0 MB/s

135 Stunden

5 1/2 Tage

of=/dev/md.. + timer_entropyd

3,7 MB/s

135 Stunden

5 1/2 Tage

of=/dev/sd.. (also ohne RAIS-Schicht)

3,8 MB/s

135 Stunden

5 1/2 Tage

if=/dev/zero

ca. 66 MB/s

8 Stunden

1/3 Tag


Meine Erkenntnisse daraus:
  • urandom ist der begrenzende Faktor, nicht der USB-Anschluss.

  • Die Blockgröße ist fast egal: Auch größere und kleinere Input-Blocks (ibs=...) ändern nichts Nennenswertes.

  • Mehr Entropie bringt keinen Speed: Ich dachte, dass urandom schneller wird, wenn das System mehr Entropie hat. Dazu habe ich timer_entropyd eingesetzt, um die Entropie zu bekommen. Hat nichts gebracht, ja eher geschadet: Die Performance ist leicht gesunken.

  • Nachdenken hilft: urandom liefert Psuedozufallszahlen, rechnet also und braucht dazu CPU-Power. Mehr Entropie macht die Zufallszahlen zwar "zufälliger", aber deren Erzeugen nicht schneller.

Ich habe nun also ein paar Stunden Zeit, zu entscheiden, ob es das Risiko einer Krypto-Attacke gegen meine Platte wert ist, sie vorher 5 1/2 Tage mit Zufallszahlen zu beschreiben.