srand() und rand() auslagern

hustbaer

Genau!

@wob Alles nach "hab ich mt19937 genommen" bezieht sich auf's Seeden. CryptGenRandom, /dev/random, /dev/urandom und std::random_device, alles gut zum Seeden geeignet, nix davon gut zum Erzeugen guter Zufallssequenzen geeignet. Zumindest nicht ohne "Nachbearbeitung" der Daten, und nicht wenn man gute Performance will.

Zhavok

Ok? Ist es dann immernoch aus kryptografischer Sicht legitim, z.B. CryptGenRandom nur als Seed für den Mt19937 zu nutzen? Beispiel wäre die Erstellung eines Salts für Hashverfahren. Oder entstehen da dann wieder Lücken, welche sich Dritte zu Nutze machen können?

@hustbaer sagte in srand() und rand() auslagern:

@wob Alles nach "hab ich mt19937 genommen" bezieht sich auf's Seeden. CryptGenRandom, /dev/random, /dev/urandom und std::random_device, alles gut zum Seeden geeignet, nix davon gut zum Erzeugen guter Zufallssequenzen geeignet. Zumindest nicht ohne "Nachbearbeitung" der Daten, und nicht wenn man gute Performance will.

ich dachte, urandom wäre der standard? mein testprogramm (1,2 GHz) hat jedenfalls knapp 3,3s für 1 Gb gebraucht. wie schnell muss das denn sein?

@Zhavok sagte in srand() und rand() auslagern:

Ok? Ist es dann immernoch aus kryptografischer Sicht legitim, z.B. CryptGenRandom nur als Seed für den Mt19937 zu nutzen?

laut wikipedia ist das teil nicht für kryptografische anwendungen geeignet.

hustbaer

@Zhavok
mt19937 ist für Crypto Zeugs nicht zu gebrauchen.

hustbaer

@Wade1234 sagte in srand() und rand() auslagern:

ich dachte, urandom wäre der standard?

Standard für was?

mein testprogramm (1,2 GHz) hat jedenfalls knapp 3,3s für 1 Gb gebraucht. wie schnell muss das denn sein?

Normalerweise will man nicht Megabyteweise Zufallszahlen am Stück generieren sondern an verschiedenen Stellen pro Durchlauf ein oder zwei Zufallszahlen ziehen.

@hustbaer sagte in srand() und rand() auslagern:

Standard für was?

für die erzeugung von zufallszahlen aller art auf unix-systemen. edit: also vorausgesetzt, man möchte diese zufallszahl über das betriebsystem beziehen.

Normalerweise will man nicht Megabyteweise Zufallszahlen am Stück generieren sondern an verschiedenen Stellen pro Durchlauf ein oder zwei Zufallszahlen ziehen.

macht das denn so einen unterschied?

hustbaer

@Wade1234 sagte in srand() und rand() auslagern:

macht das denn so einen unterschied?

Was meinst du geht schneller, 1-2 Multiplikationen und 2-3 ADDs/XORs, oder read() für 8 Byte aufrufen?

naja wenn read schneller wäre, würdest du mich das wahrscheinlich nicht fragen. evtl. - sag ich mal - 256 kB in einen puffer laden und bei bedarf auslesen?

Swordfish

Je nach dem wo dieser puffer ist ist rechnen immer noch schneller.

hustbaer

@Wade1234 Ja, blub. Das ist doch alles Quatsch. Viel zu umständlich. Und das dafür dass man dann Zahlen hat über deren Qualität (Gleichverteilung, "Zufälligkeit") man nichts (oder nicht genug) weiss, weil vermutlich nicht oder nicht ausreichend spezifiziert ist welchen Qualitätsansprüchen urandom genügen muss.

Wenns einem wurscht ist was man für Zahlen bekommt, dann ja, dann kann man schon urandom nehmen. Aber "der Standard"...? Hoffentlich nicht.

SeppJ

@hustbaer sagte in srand() und rand() auslagern:

@Wade1234 Ja, blub. Das ist doch alles Quatsch. Viel zu umständlich. Und das dafür dass man dann Zahlen hat über deren Qualität (Gleichverteilung, "Zufälligkeit") man nichts (oder nicht genug) weiss, weil vermutlich nicht oder nicht ausreichend spezifiziert ist welchen Qualitätsansprüchen urandom genügen muss.

Ziemlich hohen Ansprüchen übrigens, wenn's ein Linux ist. urandom ist für kryptographische Anwendungen ausgelegt und erfüllt diese Ansprüche. Ist natürlich völlig unnötiger Overhead und/oder hat unerwünschte andere Eigenschaften, wenn man keine Kryptographie macht.

PS: Von daher würde ich scohn sagen, dass "wenn du nicht weißt, was richtig ist, dann liegst du mit urandom nicht verkehrt" schon ein guter Ratschlag ist, und das umgekehrt für keine der anderen Quellen von Zufallszahlen gilt. Wenn man Spezialansprüche an die Zufallszahlen hat, die urandom nicht so gut erfüllt (z.B. speicherbarer State) dann weiß man offensichtlich, wovon man redet.

hustbaer

@SeppJ Ja, dass das Ding so gut wie sinnvoll möglich kryptographisch sicher ist, davon gehe ich aus. Aber wie sieht's mit Gleichverteilung aus? Ich würde mal ganz naiv schätzen schlecht, denn ich vermute dass die Massnahmen die man setzen müsste um ne schöne Gleichverteilung zu garantieren sich nicht mit "kryptographisch sicher" vertragen.

Also wenn man Kryptographie macht, ja, dann ist urandom vermutlich gut geeignet.

Ich schätze aber: wenn man nicht weiss was man genau braucht, aber zumindest sicher weiss dass man keinen kryptographisch sicheren Generator braucht, ist man meistens mit nem über urandom geseedeten PRNG besser dran.

EDIT:

Ist natürlich völlig unnötiger Overhead und/oder hat unerwünschte andere Eigenschaften, wenn man keine Kryptographie macht.

Opps, das hatte ich beim 1. mal Lesen ... überlesen Also ja, im Prinzip genau das was du geschrieben hast.