4 ms·
> a non-CSPRNG makes sense, as they're still faster Nowadays with highly optimized and often hardware-accelerated crypto, I honestly doubt it matters. Using "
by tgsovlerkhgsel 7y ago
> a non-CSPRNG makes sense, as they're still faster
Nowadays with highly optimized and often hardware-accelerated crypto, I honestly doubt it matters.
Using "openssl rand", I can generate randomness 2x as fast as with a naive
while (1) { r = rand(); fwrite(&r, 4, 1, stdout); }
compiled with -O2. If I replace "openssl rand" with "openssl enc -aes-128-ctr < /dev/zero", I get randomness 4 times faster again, i.e. 8 times as fast as with the naive approach using rand(), hundreds of megabytes on a single core.
And I don't have to worry about the properties of the PRNG.
- FabHK 7y agoYes, good point. As O'Neill pointed out in a blog post last year on "Efficiently Generating a Number in a Range" [1], the impact of choosing a faster PRNG is smaller than the impact of choosing a good algorithm to generate an integer in a range. There'll be very few applications where choosing a faster PRNG has any significant impact. [1] http://www.pcg-random.org/posts/bounded-rands.html http://www.pcg-random.org/posts/bounded-rands.html
- wolf550e 7y agoNot "hundreds of megabytes on a single core", 5 GB per second on a single core on a i7-6700HQ. Use `openssl speed -evp aes-128-ctr`, look at right-most column of 16kb blocks (like TLS record layer).
- ahh 7y agoFair, but rand() is kinda trashy, and the overwhelming part of that cost is fwrite anyway.
- tgsovlerkhgsel 7y agoA large part of the cost being "not random number generation" is part of the point - speed of random number generation generally doesn't matter compared to the speed of what you do with the numbers, and optimizing other things, e.g. how to get the bits converted to random numbers usable by an application, are much more important than quickly generating the random bits.