An Analysis of OpenSSL's Random Number Generator (opens in new tab)

A hash of the private key isn't actually bad to use for entropy. It's what's done in deterministic EC signatures, deriving the k value from the private key + message.

... I'm not sure I can take an article seriously that suggests "but what if the attacker can modify files in /dev?".

In any case, the meaningful concerns from that article have been addressed with the getrandom syscall on Linux, introduced a few months after this article was written: https://lwn.net/Articles/606141/

Perhaps we should start saying "getrandom" / "getentropy" instead of "/dev/urandom", but they're the same underlying CSPRNG (although getrandom has the distinct advantage of allowing you to tell if the urandom pool has been initialized, which /dev/urandom doesn't let you do), so I can understand being sloppy with usage. I would sort of assume anyone in a position to patch OpenSSL's RNG either upstream or in a distro is aware of getrandom and why it exists, but maybe that's a bad assumption.

That article says //Continue filling with other sources where it should say //exit with an error.

It fails in a poorly set up chroot, not any old chroot.

It also fails in a poorly set up root file system in the same way. No chroot needed.

I can't remember ever running out of file descriptors unless a program had a leak. But if you want to argue that position too, make sure you mention that cputime and memory could also be exhausted, leading to... well... any other method failing in a similar fashion.

A system call definitely has some minor benefits over a file in /dev, bit the reverse is also true (access from shells, or any language really, with no built in support).

But calling /dev/urandom unreliable is a little bit intellectually dishonest.

Also, it's a good idea to reseed your userspace CSPRNG from the kernel's entropy source periodically. This is precisely what OpenBSD did with their arc4random and arc4random_buf library calls. (Don't worry, they now use ChaCha20 instead of arcfour/RC-4, but have kept the function name unchanged, since it's a backward-compatible change... the only way a caller can tell RC-4 from ChaCha20 is by detecting small statistical biases in RC-4's outputs.)

nope, that's a myth http://www.2uo.de/myths-about-urandom/

No I definitly mean /dev/urandom[1] or the getrandom syscall which would be equal to /dev/urandom.

[1] http://sockpuppet.org/blog/2014/02/25/safely-generate-random...

Isn't 'semi-broken' equal to 'broken' for cryptographic purposes?