11–20 of 138 posts
Is there a good random library that's not the giant ball of death that's OpenSSL?
I've used Mersenne Twister[0] in the past. [0] http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html If you're talking about an RNG library for cryptographic purposes, then it depends on your use case.
So once again, the man page for urandom creates more problems than solutions. ( https://bugzilla.kernel.org/show_bug.cgi?id=71211 )
Why is there such a discrepancy between the prevailing sentiment on HN and the actions of whoever controls the manual? What is preventing one side from convincing the other, apart from stubbornness? Also, why are the Ruby devs so dead set on the manual page?
The reason this is a problem is simply that the Linux maintainer is obstinately wrong. Theodore Ts'o was on HN a year or so ago, and in defending the current design (and man pages), made some incoherent arguments, such as that urandom might be OK for nonces, but not key generation (a head-scratcher for anyone familiar with cryptography engineering).
So once again, the man page for urandom creates more problems than solutions. ( https://bugzilla.kernel.org/show_bug.cgi?id=71211 )
Why is there such a discrepancy between the prevailing sentiment on HN and the actions of whoever controls the manual? What is preventing one side from convincing the other, apart from stubbornness? Also, why are the Ruby devs so dead set on the manual page?
As for "Also, why are the Ruby devs so dead set on the manual page?" - because it makes sense. If I didn't know much about random number generation, I'd rely on manuals and most widely adopted software. That means: urandom says it's not good for that usage, while openssl is used by almost every system. If you used a dependency that documents it does X and someone tells you that actually it does Y, but you have no ability to prove it either way, would you listen to the docs or random-internet-person.
Regardless, whether it be OpenSSL first or /dev/urandom first, "haveged" entropy generation is still needed for virtual machines, which is the most common use case. In my experience both ways are a no-go without special measures like haveged being put in place to super-charge the available entropy. I've had processes hang up for MINUTES or just under TWO HOURS waiting for more entropy to be available.
Earlier quoted context omitted.
Depends on why you want to use a random number generating library. What are your requirements and specifically what are your requirements that aren't satisfied with the system's csprng. Once you have that defined, you can start looking at what algorithms you want and from there what libraries implement it. Edit: or to put another way, first define what is it that linux's getrandom() and /dev/urandom doesn't provide y…
This talk about C++ and rand being harmful is quite educational: https://channel9.msdn.com/Events/GoingNative/2013/rand-Consi... What it points out is that even a good random number generator can be used incorrectly, and without the right tools your efforts to produce truly random numbers are doomed from the start. C++ has an embarrassing wealth of random number generators. The Ruby core has almost nothing that can m…
Regardless, whether it be OpenSSL first or /dev/urandom first, "haveged" entropy generation is still needed for virtual machines, which is the most common use case. In my experience both ways are a no-go without special measures like haveged being put in place to super-charge the available entropy. I've had processes hang up for MINUTES or just under TWO HOURS waiting for more entropy to be available.
Also RDRAND can be executed in a VM, but I'm not sure if it is handled properly yet.
And like tptacek mentioned - why did you use blocking random in the app?
So once again, the man page for urandom creates more problems than solutions. ( https://bugzilla.kernel.org/show_bug.cgi?id=71211 )
[1] http://sockpuppet.org/blog/2014/02/25/safely-generate-random...
Earlier quoted context omitted.
I've used Mersenne Twister[0] in the past. [0] http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html If you're talking about an RNG library for cryptographic purposes, then it depends on your use case.
It does not depend on your use case. The answer, in all cases, is just to use /dev/urandom.
If you used a CSPRNG with a seed space smaller than the set of possible lottery outcomes, losers could argue (misleadingly, since we still couldn't feasibly bias the result) that not all outcomes were equally probable and try to get the results thrown out. That is, the fact that there are widespread misconceptions about /dev/random can very rarely be a reason to use it :P
However, I agree that the rule is that you should just use /dev/urandom.
So once again, the man page for urandom creates more problems than solutions. ( https://bugzilla.kernel.org/show_bug.cgi?id=71211 )
Obligatory "How To Safely Generate A Random Number" link[1] that I always wind up posting in threads like these. There's also the getrandom syscall[2] which uses the /dev/urandom pool. [1] http://sockpuppet.org/blog/2014/02/25/safely-generate-random... [2] http://man7.org/linux/man-pages/man2/getrandom.2.html