Trick: /dev/random beschleunigen
-
Ich schreibe gerade ein makepasswd, das Umlaute kann und erzwingt, weil die Amis und der RestDerWelt nur Rainbow-Tables ohne Umlaute bauen[1].
Ertmal nahm ich C++/std::random_device und war erschüttert, daß es nicht an /dev/random hängt (Linux/GCC4.8.3).
Dann nahm ich /dev/random selber und war überrascht, wie lahm es ist. So ca 1 bis 2 Bytes pro Sekunde. Mauswedeln beschleunigt den Output.
Hab dann mal im Kernel HW_RANDOM/* angemacht und ihn compiliert. Uff, während des Kernelcompilierens kommen die Zufallszahlen nur so reingeflogen, 10 oder mehr pro Sekunde. Ich verlasse mich mal drauf, daß die Kernel-Leute wissen, was sie tun, und die Zahlen weiterhin sicher sind.
Damit ist das ein Trick, wenn man mal einen kleinen Haufen Passwörter braucht: Großen Compilierjob anstoßen und dann das Script starten, was 10 lange Passwörter generiert.
-
Die übliche Beschleunigung wäre, /dev/urandom zu benutzen. Das Ding hängt schließlich letztlich am selben Generator wie /dev/random, bloß ohne irgendwelche Pseudosicherheit durch mythische Entropiezählerei.
-
SeppJ schrieb:
Die übliche Beschleunigung wäre, /dev/urandom zu benutzen. Das Ding hängt schließlich letztlich am selben Generator wie /dev/random, bloß ohne irgendwelche Pseudosicherheit durch mythische Entropiezählerei.
Der Witz ist doch "durch mythische Entropiezählerei".
Hole ich mehrer Passwörter pro Sekunde von /dev/urandom, hängen sie über den noch als sicher geltenden prng-Algo zusammen. /dev/random dürfte ihn kaum weiter gefüttert haben, ist nicht schnell genug.
Hole ich mehrere Passwörter pro Sekunde von /dev/random, hängen sie nicht zusammen? Naja, doch vielleicht mit dem Trick. Kann sein, daß mechanische Plattenzugriffzeiten (echter Zufall) in den Pool gehen und meine SSDs (evtl komplett unzufällig) für mechanische Plattenzugriffzeiten gehalten werden. Ja, das ist
mystischpseudowissenschatlich.Bin am Hadern, ob ich /dev/random eher glauben soll oder /dev/urandom.
/dev/random:
+ "Echte Entropie"
- fragwürdige Quelle: Evtl schnell auslutschbar./dev/urandom:
- …
…Mist, ich glaube, ich habe es verstanden./dev/urandom:
+ sicher, wenn man dran glaubt.
- unsicher, wenn man nicht dran glaubt.Ok, keine Verfahren sind bekannt, sagen wir mal einen 64-bit-Seed zu extrahieren aus einem aktuellen /dev/urandom. Und wenn der Anfkug eines Verdacxhtes käme, wprden die Kernel-Leute einfach mit 128 Bits seeden. Meine Kundenpasswörter müssen nicht viel mehr als ein paar Jahre halten.
Ich hau ein sleep(3600) zwischen die Bytes, dann ist genug Entropie da. Für meine Kunden schnell genug.
Um /dev/urandom zu knacken, muss der Angreifer voll die Kryptoanalyse benutzen&/erfinden und 50 Jahre warten auf die Hardware. Nö.
Acer im Falle eines "Jo."? Wohin hatte ich die Maus geschwungen beim vierten Passwort?
-
/dev/random und /dev/urandom sind der gleiche Generator. Der wird ständig neu gefüttert, wenn neue Entropie da ist. /dev/random gibt aber nur was her, wenn die eingeflossene Entropiemenge (was immer das auch genau sein mag, aber nehmen wir mal an, dass es irgendwie vernünftig messbar ist) größer ist als die Anzahl der entnommenen Zahlen. Das ist ein Ansatz, den man machen kann, wenn du informationstheoretische Sicherheit brauchst, also beispielsweise ein OTP erstellen möchtest. Wie du sicher weißt, sind die meisten dieser Anwendungen in der Praxis Quatsch, auch wenn sie in der Theorie absolute Sicherheit versprechen.
Was du doch vermutlich möchtest, ist praktische Sicherheit. Wo der Cracker eben 2^256 Möglichkeiten probieren müsste, um irgendetwas zu erraten. Das erfüllen beide, randum und urandom, wenn man irgendwann in der Vergangenheit 256 Bit Entropie eingespeist hat. Es ist nicht nötig, dass für jedes gezogene Bit ein weiteres Bit Entropie einfließt. Dieser Punkt ist die Pseudowissenschaft, da es die Zahlen nicht "zufälliger" macht, als sie es für alle praktischen Zwecke schon sind. Letztlich kann der Cracker schließlich versuchen die Passwörter zu Brute-Forcen, eben weil du kein informationstheoretisch sicheres Verfahren nutzt, sondern eines, dessen Sicherheit darauf beruht, dass der Cracker lange brauchen würde für den Brute-Force Angriff. Ob der Cracker versucht, irgendwie den Seed deines CSPRNG zu forcen oder direkt das Passwort, macht doch keinen Unterschied.
-
volkard: Der wird dich jetzt vmtl. nicht sehr beeindrucken oder sehr neu für dich sein, aber ich fand den Artikel hier recht gut: http://www.2uo.de/myths-about-urandom/
