Hacker News Reader

Is this because there is 0 entropy available at boot and therefore even /dev/urandom is unavailable? Or is this because legacy tools are still relying on the concept of being able to "drain" the entropy pool? I'm not sure which the "getrandom()" call is related to.

View on HN

The problem with /dev/urandom is that it's always available, even before any entropy was added. Fixing /dev/urandom to block until enough entropy is available once causes breakage like in the article. That is one of the reasons why getrandom() was added, so that existing applications can keep using the old and broken behavior but applications that care about the RNG being properly initialized can wait for it. So software that does crypto switched to it, and then things broke anyway.

> Fixing /dev/urandom to block until enough entropy is available once causes breakage like in the article.

... not to mention it is the entire point of /dev/urandom .. if you want something to block for entropy, you use /dev/random. if you are using /dev/urandom, you are saying I want something 'randomly random' and I'm okay if I can't get something random enough..

getrandom blocks until 128 bits of entropy have been collected since boot. It doesn't have the concept of "draining" the pool after the pool has been initialised.

Reply on news.ycombinator.com