Myths About /dev/urandom

He says both are CSPRNGs. Part of the requirement of a CSPRNG is keeping the seed secret. Not using actual entropy sources makes state compromise extension attacks possible. Both tools have their place. You may want to use /dev/urandom for generating noise in image filters, where there is a need for a bulk of data. You can use the entropy collected by the pools of the blocking source as a seed to create a CSPRNG, but using just urandom results in some somewhat unrealistic, yet possible opportunities to attack. See "cryptanalytic attacks on pseudorandom number generators" by schneir and company. The definition of random I like for RNG (and other stuff in general) is that a uniform distribution is formed for outputs. Often a linear congruential generator function is used, and if parameters are chosen carefully, you can choose any input (besides zero, that is problematic value in crypto in many cases) and it will go ahead and create a provably uniform distribution across a given range. It's possible to do it and get the period to be 2^32 - 1 for a 32-bit seed, longer if you pick nice primes (I believe the Linux RNG uses a mersenne twister generator) that has a period of much higher than that. That's actually too perfect for randomness however (sometimes you roll back to back 7s, it happens even for a 2^32 faced die), that's why reseeding is important, and why you want to mix in actual random sources.

His whole article is riddled with "I believe" and "I don't think that's important". His pretty rough simplification is wrong. That's the argument I'm making. The pools are completely separate buffers. Berstein goes on to say in his post:

"I'm not saying that /dev/urandom has a perfect API. It's disappointingly
common for vendors to deploy devices where the randomness pool has never
been initialized; BSD /dev/urandom catches this configuration bug by
blocking, but Linux /dev/urandom (unlike Linux /dev/random) spews
predictable data, causing (e.g.) the widespread RSA security failures
documented on http://factorable.net. But fixing this configuration bug
has nothing to do with the /dev/random superstitions."

So using /dev/urandom may be all fine and dandy (I disagree but I've got time to wait for blocking 256 bits from /dev/random), unless it's not initialized or there is some other implementation problem. With the blocking source, at least you get some bits from source that are local and largely not reproducible (time between keyboard interrupts sampled possibly in the gigahertz), you're already ahead when you get through the hash function. So why not raise the bar when generating keys, if you're this concerned with security and have a high performance need for key generation there are solutions out there also.

tl;dr Blog author doesn't care about some of the theoretical attacks, they're too hard and other crypto will probably break first so why bother