Maybe those implementations block until it is seeded?

urandom by definition doesn't block.

The only time you'd have to worry about this is during boot. Ideally, whatever you're trying to do at boot time should be moved to post-boot time, when the kernel has taken care of all the concerns for you.

I don't know what the answer is to "If you want to generate secure random numbers during boot before urandom is seeded, how would you do it?" I assume it's "Seed urandom, then use it."

> urandom by definition doesn't block.

That's precisely why getrandom(2) is preferred on newer kernels, and the following hacky workaround from the article is given on older kernels:

  For software that runs during the Linux boot, poll /dev/random until it's available.
  This means /dev/urandom has been seeded and you can safely read from /dev/urandom for
  all your cryptographic purposes. Don't read from /dev/random.

I believe it blocks on some BSDs during early boot, when not enough entropy has been collected, maybe OpenBSD?

Not on OpenBSD. The bootloader supplies entropy, so that basically as soon as the kernel starts booting, random numbers are available.

Edit: /dev/random on OpenBSD also does not block.

Thanks for the correction! I didn't know that was possible. It makes sense; it's the only way to ensure urandom is always safe to use.

Does anyone know how other operating systems behave in that situation?

1) Define "enough" in terms of each and every specific piece of hardware, combined with the mixing heuristics and functions in every kernel of interest. It's one thing to say you want N bits of entropy; it's quite another to accurately quantify it. (Count the number of times you see a word like "assume", "estimate", etc, in papers discussing kernel entropy estimation, and you'll never look at entropy estimation the same way.)

2) If you managed that and were able to conclude in the negative for a specific combination of kernel, kernel revision, and hardware models and revisions, what then? Are you going to recreate all that infrastructure in your app or through a gargantuan dependency along the lines of egd or havaged (which we've already learned from experience is a poor idea)?

My point being, the question is arguably irrelevant. If available entropy at boot time (usually first boot, as the shutdown/startup process recycles entropy pools) is insufficient, better to pressure vendors (software and hardware) to address it than to add another layer of cruft or a complex mitigation. The fix will probably be out in the next year or so (indeed, with RDRAND has been out for years); the hack will linger for far longer, perhaps eventually becoming the weakest link in the chain.

For similar reasons I think the article's as well as libsodium's choice to only use the most recent arc4random implementation as shipped in recent OpenBSD releases is misguided. Every other *BSD provides arc4random, and arguably applications should always prefer to use the libc's arc4random implementation. Eventually they'll be upgraded, at which point your application will have a useless dependency adding at best needless complexity and at worst vulnerabilities.

Once you look behind the interface of arc4random, you're obliged to look behind the interface of /dev/urandom, etc, and I doubt it will look much better. Until the recent overhaul (last month), the PRNG infrastructure in Linux relied on SHA-1, which isn't much better than RC4, especially when considering that the RC4 used in the classic arc4random implementations discarded the first 1k of output and reseeded regularly. SHA-1 hasn't been recommended for cryptographic purposes for several years, and while you could make pragmatic arguments for why it was still acceptable, you could do the same for the particular use of RC4 in older arc4random implementations. I don't see libsodium skipping /dev/urandom for kernels before 4.9. At some point you have to stop bending over backwards to support platforms with poor QoS and leave things as you found them as long as they're not utterly broken. If experience with egd and, more generally, the boots-and-suspenders approach to security is any measure, classic arc4random is well within the bounds of reasonable. Simplicity is the rule of the day; experience has taught that complexity is invariably a net loss in security, especially when the weakest link remains unchanged.

Not really, you can always improve upon an existing PRNG by XOR'ing the random number stream with the output of your own PRNG without thereby weakening security. So if you think /dev/urandom does not produce enough entropy, rolling your own PRNG with additional entropy sources (e.g. mouse movements) on top of it cannot harm if you use XOR for combination.

However, you can also feed the system-wide PRNG with additional entropy, and for many applications this might be the better choice.

I would add, while this is mostly accurate (XOR is perfectly fine for retaining 'randomness' in the sense you're talking about - even if the second stream isn't random the output will still be as random as the initial) there is the big issue that you don't want to accidentally reuse an entropy source.

For example, imagine /dev/urandom is already using mouse movements as an entropy source. If you then decide to also use mouse movements, you may have weakened the randomness of the resulting stream because now some of the random bits get reused.

In the worst case, if you were the only user of /dev/urandom and output the exact same sequence of bits from the mouse movements, an XOR would completely remove all randomness from the mouse movements (All 1's get flipped to 0's, all 0's stay the same). Even without the worst case though, it could still influence a pattern into the bits due to the reuse.

> Not really, you can always improve upon an existing PRNG by XOR'ing the random number stream with the output of your own PRNG without thereby weakening security.

Unless an attacker gets to acctively control your PRNG results.