Linux contains two separate sources for random numbers: /dev/urandom and /dev/random.  On a reasonably-current Linux box, the urandom(4) man page states:

    As a general rule, /dev/urandom should be used for
    everything except long-lived GPG/SSL/SSH keys.

This seems to suggest that, in the eyes of its implementors, /dev/random returns ever-so-slightly superior random numbers, and that in certain limited circumstances you should prefer those.

AFAICT the secrets module doesn't make use of the /dev/random device on Linux.  Should it?  (Or, in the likely case that we make the getrandom() function directly callable, should it call getrandom(GRND_RANDOM)?)


p.s. FWIW, Linux's /dev/urandom isn't considered a true CPRNG in all circles.  This paper declines to call it simply either a CPRNG or a PRNG, instead christening it with the unfamiliar term "PRNG with entropy inputs".

https://eprint.iacr.org/2012/251.pdf

p.p.s. I went ahead and nosied the "cryptography" "interest category" from the nosy list.  Neat!

No we should not use /dev/random (or GRND_RANDOM(. It's numbers are not "more random" than /dev/urandom outside of the narrow window of prior to /dev/urandom being fully seeded. In fact, on Linux both /dev/urandom and /dev/random use the exact same CSPRNG the only difference is that /dev/random does some snake oil to try and guess "how much random" is left (which experts widely agree is a load of manure) and will block randomly (pun intended) throughout the running of the system whenever it's snakeoil decides that it's "random is running low".

I know what the manpage says, it's basically an urban myth, unchanged largely because of political pressure

For more information, read http://www.2uo.de/myths-about-urandom/ .

So, you assert getrandom(0) and getrandom(GRND_RANDOM) return random bits of identically high quality?

I'm curious about this political pressure you cite.  It seems bizarre to me that the Linux developers would bow to such a thing, given how they behave on... well, every other topic.  Can you point me towards resources about this political squabble?

p.s. Yes, I've re-read the "myths about urandom" page many times this week.  But there are enough experts on both sides of the topic that I don't know what to believe anymore.  Certainly I'm happy to leave it to you guys.

> So, you assert getrandom(0) and getrandom(GRND_RANDOM) return random bits of identically high quality?

Yes, except the latter will randomly block.

> I'm curious about this political pressure you cite.

Think about the last 4 days, now imagine that's happening on LKML where instead of having GvR disagree with you, you get told your parents should have aborted you.

I will add, /dev/random is not going to *hurt* when generating long lived cryptographic keys (e.g. like your SSH keys) because that's something you're generally going to do once every couple of years and if it takes a few seconds longer because of snake oil then who cares. It's not going matter once /dev/urandom is initialized (of course, it does matter if /dev/urandom hasn't been initialized yet). So it does guard against early on in the boot process in a way that /dev/urandom doesn't (but then, so does getrandom(0)).

It's obviously not acceptable for your webserver to randomly block for seconds at a time trying to generate signing keys for cookies just because of snakeoil though.

I understand.  It's just that the manpage for urandom (and in fact the comments in the source code for /dev/random and /dev/urandom) both recommend using /dev/random for these long-lived cryptographic keys.  Under normal circumstances I'd simply assume that was correct and I'd follow their advice.

But you're claiming that there are extenuating political circumstances surrounding these statements and they should be ignored.  I trust your judgement and I'd be happy to see the secrets module do as you suggest.  But you must admit, this is a surprising state of affairs.

> It's just that the manpage for urandom (and in fact the comments in the source code for /dev/random and /dev/urandom) both recommend using /dev/random for these long-lived cryptographic keys. 

It's a hedge because of the bad behavior of /dev/urandom on early boot in a situation where it's highly unlikely that the randomly blocking behavior of /dev/random is going to matter.

Please don't use /dev/random for anything, ever.

It can block applications unpredictably for no good reason.