[deleted]
Ruby Bug: SecureRandom should try /dev/urandom first
61–70 of 138 posts
Re: Ruby Bug: SecureRandom should try /dev/urandom first
#62Earlier quoted context omitted.
No, it's not. Don't use haveged. Virtual machines should simply get their initial entropy from the already-seeded urandom pool of their hypervisor host. Processes don't "hang waiting for more entropy"; they hang because /dev/random inexplicably goes on strike. The answer to that problem is "never use /dev/random".
true but even if we don't want to use /dev/random, there's still software using it all over the place that we don't necessarily want to patch. I end up installing haveged just because I don't want the system mysteriously locking up because some random daemon wants to create a 4096 bit key on first startup.
Replacing random with urandom for one app is just one LD_PRELOAD away. Similar to https://rafalcieslak.wordpress.com/2013/04/02/dynamic-linker... you can replace open("/dev/random") with open("/dev/urandom")
Re: Ruby Bug: SecureRandom should try /dev/urandom first
#63Well, I dunno what the man pages say and what some dudes on the internet say, but I know that on CentOS release 6.7 (Final) I need to run with -Djava.security.egd=file:///dev/urandom or else I can't connect to Oracle half the time because Java runs out of entropy. So there must still be some difference between /dev/random and /dev/urandom.
Nobody's claiming there's no difference between /dev/random and /dev/urandom. They're just saying you should always use /dev/urandom.
Re: Ruby Bug: SecureRandom should try /dev/urandom first
#64I was recently told about a method to generate a random number using something called "quadratic residue". There was too much math for me to understand it. Is anyone familiar with this?
Re: Ruby Bug: SecureRandom should try /dev/urandom first
#65This is sad and embarrassing for every involved party. The people leaving rude, entitled, hyperbolic comments in the thread, the Ruby developers who refuse to look into the best practice suggested by experts in the field, and the man page maintainer who refuses to update the man page in accordance with similar information.
Agreed that tensions are running high. But I think the ruby devs are in the right here. They are just following the man page. What else is the authoritarian source?
How is one supposed to know who wrote those blog posts? Just because it is linuxexpert.com does not mean they are linux experts. It's funny, if people changed it randomly following blogs then people will claim this is some NSA conspiracy :-) How does one verify the person behind the blogs?
node has similar https://github.com/nodejs/node/issues/5798
Re: Ruby Bug: SecureRandom should try /dev/urandom first
#66I really don't like the sentiment of "We shouldn't change it unless the man page says we can". That's exactly the kind of senseless bureaucracy that the open source community should be avoiding.
Huh? So you want them to make code changes which is against the man page recommendation? Why have man pages at all then? Do you expect ruby developers to dig into kernel source code and more importantly actually understand what is in there?
If you think they should take the word of 'experts', how does one qualify as an expert? How do you verify that the expert is the one who wrote the blog post or mail etc etc.
The process is already there. Get the change for man page in kernel and user space will follow suit.
Re: Ruby Bug: SecureRandom should try /dev/urandom first
#67I really don't like the sentiment of "We shouldn't change it unless the man page says we can". That's exactly the kind of senseless bureaucracy that the open source community should be avoiding.
The manpages for syscalls and device nodes are basically their API specifications. They tell you what behaviours can be guaranteed (i.e. what properties are a part of the interface contract) and what behaviours cannot (i.e. what properties are implementation details of the current implementation, and could change at any time.)
Just because the implementation of /dev/urandom has good properties that make usable as a system-wide CSPRNG, doesn't mean that it's supposed to have those good properties. Only the docs can make that assertion. Without such an assertion, the kernel is free to make /dev/urandom have less-sound properties in a future release—because there's no spec saying they shouldn't. (They try not to break userland code, yes, but userland code only relies on things the docs say it can, so...)
Re: Ruby Bug: SecureRandom should try /dev/urandom first
#68Is there a good random library that's not the giant ball of death that's OpenSSL?
ISAAC ( http://burtleburtle.net/bob/rand/isaacafa.html ) for a CSPRNG. But what is your use-case for something non-standard? Just use /dev/urandom
How about, backing the equivalent of /dev/urandom for a unikernel OS?
Re: Ruby Bug: SecureRandom should try /dev/urandom first
#69Earlier quoted context omitted.
As others have said it depends on your needs[6] and whether or not it has to be a CSPRNG (cryptographically secure). Since you mentioned OpenSSL I'll assume that in this context we are talking about a CSPRNG. The short answer is to just use the OS provided one if available. Linux has /dev/urandom[1] and the getrandom[2] syscall and Windows has RtlGenRandom[3][4] (there's also CryptGenRandom on Windows which is the "o…
/dev/urandom is a shared resource across all processes, and that implies locking/synchronization that can run you into scalability issues if you are trying to generate a large volume of random numbers in parallel on multiple cores.
I'm surprised there's no talk of essentially making reads from /dev/urandom occur via a VDSO that grabs a seed for each process from the common pool, and then runs entropy generation from then on in the process's address space.