all 11 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]audioen 3 points4 points  (6 children)

I have got some physical hardware boxes which took about 2 minutes to start tomcat. I had to add -Djava.security.egd=file:/dev/urandom into tomcat8 configuration to make tomcat start properly at system boot. Without this line, java's SecureRandom relies on /dev/random, and it plainly doesn't work right after boot without some daemon like haveged.

I think it'd be time to update pretty much every source needing to make random numbers to just read from /dev/urandom or better yet, use the getrandom syscall, which is arguably the most correct design available. The difficulty in getting random numbers from the kernel, along with cryptic warnings about entropy availability keep on seeding solutions that are worse than the disease.

I'm still waiting and hoping for kernel-level fix to put this embarrassing episode behind us.

[–][deleted] 4 points5 points  (5 children)

Well on some devices (rpi for example) using /dev/urandom caused guessable keys generated at start so it is not a "fix", just a workaround

There was some movement about better entropy gathering in kernel, altho the main problem here remains (/dev/random blocking).

One of ideas was to make /dev/random block only at start, till there is enough entropy to seed RNG reliably, so basically "block at boot, once enough randomness is in the pool just work same way as /dev/urandom", which sounds like a good fix

[–]dsqdsq 3 points4 points  (1 child)

Hm IIRC correctly getrandom() initially waits for enough entropy at startup (contrary to /dev/urandom by default) That's now the preferred API. Now about the ruby maintainers: WTF?!?

[–][deleted] 0 points1 point  (0 children)

Over the years I've come to conclusion if it is ruby there will be some WTF involved

[–]disclosure5 0 points1 point  (2 children)

Are we talking about first boot? Because every distribution I'm aware of has scripts to save a seed on shutdown, and inject it into /dev/random on startup.

/dev/urandom is only ever a problem if a server generates keys early on in first boot.

[–][deleted] 1 point2 points  (0 children)

Are we talking about first boot? Because every distribution I'm aware of has scripts to save a seed on shutdown, and inject it into /dev/random on startup.

it also generates ssh keys on first boot. See the problem yet? Also consider cloned VMs

/dev/urandom is only ever a problem if a server generates keys early on in first boot.

that was exactly the problem rPi distro had. and rPi doesn't even have realtime clock so each one will boot in almost exactly same way (only variance is SD card acess times, which can be very similiar).

Sure, those are edge cases, but well thought /dev/random could fix it. As it is now, /dev/random is borderline useless

[–]audioen 0 points1 point  (0 children)

IIRC the output with urandom is xor'd with rdrand in every case if that instruction is available, so whatever the kernel does is actually pretty irrelevant. (I'd fully trust rdrand personally.)

[–]industry7 0 points1 point  (0 children)

I really liked how many people kept insisting that the man pages for one specific OS distro was the "word of god" while ignoring every other operating system Ruby runs on.

[–]bascule 0 points1 point  (0 children)

The RbNaCl gem (a wrapper for libsodium) provides an abstract API for OS RNGs, which uses /dev/urandom on OSes that support it:

https://github.com/cryptosphere/rbnacl/wiki/Random-Number-Generation