Optimale Größe für geli-Keyfile

[raina]

Hallo,
in der geli manpage wird in den Beispielen jeweils ein Keyfile mit 64B erzeugt.
In einem Bsdforen-Wiki wird ein Keyfile mit 128B benutzt, in zwei anderen sogar welche von 1MB. Wenn man zusätzlich eine Passphrase benutzt, hat diese normalerweise eine Länge von weniger als 100 Zeichen. Ist es dann wirklich sinnvoll, Keyfiles von mehr als 1kB zu verwenden?

[Crest]

Afaik wird der Keyfile gehasht d.h. alle Entropie, die max. Entropie der Ausgabe der Hashfunktion übersteigt, ist überflüssig schadet aber nicht.

[nakal]

Wenn man davon ausgeht, dass /dev/random schlecht ist, dann sollte man vielleicht mehr generieren als nur die Key-Länge.

Einfache Kalkulation: je mehr Daten, desto höher die Wahrscheinlichkeit, dass die volle Entropie genutzt wird.

Entropie muss im Rechner gesammelt werden und das ist nicht nur teuer, sondern auch schwierig. Wenn du davon ausgehst, dass der Rechner schlecht mit Zufallszahlen umgeht, dann generiere lieber mehr und dann lass einen Hash draus machen, der die gewünschte Key-Länge hat. Eigentlich wird das auch intern so gemacht. Wenn man nämlich den Key ausliest, dann hat man den Hash über die Daten und dann braucht man nur diesen zu speichern (natürlich).

[Aldo]

Zitat von nakal

Wenn man davon ausgeht, dass /dev/random schlecht ist, dann sollte man vielleicht mehr generieren als nur die Key-Länge.

Sorry daß ich OT werde, aber in diesem Zusammenhang ist mir etwas aufgefallen:
Unter OSX ist 'cat /dev/random > /irgend/ein/file.rnd' um Welten schneller als unter FreeBSD oder Linux.
Kennt jemand den Grund?

[nakal]

Zitat von Aldo

Unter OSX ist 'cat /dev/random > /irgend/ein/file.rnd' um Welten schneller als unter FreeBSD oder Linux.
Kennt jemand den Grund?

Das kann daran liegen, dass Apple Pseudozufallszahlen auskotzt, anstatt teuer Entropie zu sammeln. Sichere Algorithmen WARTEN bis genügend Entropie zusammenkommt, um eine Zufallszahl zu generieren. Deswegen blocken sie. Das sollte die Standardeinstellung für /dev/random sein. Linux/FreeBSD hat auch ein /dev/urandom. Da kannst du so etwas auch mitmachen.

[Yamagi]

Unter FreeBSD ist /dev/urandom lediglich ein Dummy-Device zur Rückkompatiblität. Der /dev/random zu Grunde liegende "Yarrow"-Algorithmus liefert eine endlose Folge von kryptografisch nutzbaren Pseudozufallszahlen, weshalb das Device unter FreeBSD nicht blockierend ist. random(4) enthälte eine umfassende Abhandlung darüber.