Ruby Bug: SecureRandom should try /dev/urandom first

Re:Ruby Bug: SecureRandom should try /dev/urandom first by decentrality on Tuesday May 03, 2016 @10:07PM (#11625676)

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.

[ Parent | on HN ]

Re:Ruby Bug: SecureRandom should try /dev/urandom first by tptacek on Tuesday May 03, 2016 @10:09PM (#11625681)

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".

[ Parent | on HN ]

Re:Ruby Bug: SecureRandom should try /dev/urandom first by matt_wulfeck on Wednesday May 04, 2016 @02:04AM (#11626530)

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.

[ Parent | on HN ]

Re:Ruby Bug: SecureRandom should try /dev/urandom first by viraptor on Wednesday May 04, 2016 @02:31AM (#11626608)

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")

[ Parent | on HN ]

Re:Ruby Bug: SecureRandom should try /dev/urandom first by throwaway2048 on Wednesday May 04, 2016 @04:12AM (#11626924)

Its much easier and less error prone to just replace the device node.

[ Parent | on HN ]

Re:Ruby Bug: SecureRandom should try /dev/urandom first by viraptor on Wednesday May 04, 2016 @04:53AM (#11627078)

I'd rather go for a limited scope. But yes, one way or another, you don't have to suffer just because someone hardcoded /dev/random in the app.

[ Parent | on HN ]

Re:Ruby Bug: SecureRandom should try /dev/urandom first by viraptor on Tuesday May 03, 2016 @10:12PM (#11625695)

That's one of the solutions, but not the only one. QEMU's solution is another virtio device: http://wiki.qemu.org/Features-Done/VirtIORNG I expect XEN and others to follow soon.

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?

[ Parent | on HN ]

Re:Ruby Bug: SecureRandom should try /dev/urandom first by matt_wulfeck on Wednesday May 04, 2016 @02:10AM (#11626550)

Actually it's still kind of an issue. The qemu virtio device reads only from the hosts /dev/random device (not urandom) so you can still starve the hypervisor. Also the guest -- even though is properly seeded -- can entropy starve because who knows what is installed on it. And clearly there's still confusion about using /dev/random.

I don't even think the solution is to point everything to /dev/urandom. Why maintain two? Why constantly have to explain to people the difference? The BSD developers merged both devices into /dev/urandom and I think that's the right approach.

[ Parent | on HN ]

Re:Ruby Bug: SecureRandom should try /dev/urandom first by viraptor on Wednesday May 04, 2016 @02:23AM (#11626583)

It's configurable. You can even forward host's /dev/urandom as guest's /dev/random.

[ Parent | on HN ]

Re:Ruby Bug: SecureRandom should try /dev/urandom first by matt_wulfeck on Wednesday May 04, 2016 @11:55AM (#11629218)

Actually it's not supported with virtio-rng. Here[0] is a proposed patch to add support.

[0] http://www.redhat.com/archives/libvir-list/2016-March/msg010...

[ Parent | on HN ]

Re:Ruby Bug: SecureRandom should try /dev/urandom first by viraptor on Wednesday May 04, 2016 @07:58PM (#11632946)

I knew you can change the source (it accepts egd after all), but didn't know they actually prevent you from choosing urandom. This is sad :(

[ Parent | on HN ]

Re:Ruby Bug: SecureRandom should try /dev/urandom first by mioelnir on Wednesday May 04, 2016 @02:25AM (#11626587)

That VirtIORNG documentation page is really sad though, with all the warnings and quirks about the guest starving the host of entropy. The source end of that device should be fed by something like fortuna, or attach directly to urandom if available.

The way this currently looks to me, is that it all but ensures poor adoption rates.

bhyve on FreeBSD has virtio_random, and it simply hooks up to /dev/random (which on FreeBSD is nonblocking and can't starve).

[ Parent | on HN ]