[marios]

I am by not means qualified to judge on the quality of the patch, but I'm glad Linus is moving away from adding flags to getrandom() (resulting in subtly different behaviour than the Open/FreeBSD implementations). Now if only Linux fixed the "/dev/random provides higher quality random numbers than /dev/urandom and blocks when the entropy pool is empty" nonsense, that would be great.

[dev_dull]

They should do exactly what’s been done in Mac/bsd variants and make both of them the same CSPRNG via fortuna[1]. Then the only thing the system ever need to worry about is getting a few bytes of random data seeded and you can read securely all day long.

1. https://en.m.wikipedia.org/wiki/Fortuna_(PRNG)

[the_why_of_y]

They already use the same CSPRNG algorithm; the only difference is the entropy accounting.

See 2nd point here: https://www.2uo.de/myths-about-urandom/

[ploxiln]

My understanding is that /dev/random "entropy depletion" is because of FIPS or other enterprise/government certification requirements. It does not make logical sense, it just has to be that way, because requirements, because security.

[wbl]

That's not the case. FIPS only recently covered random numbers and permits on time initialization.

[thenewnewguy]

What's the issue there? As far as I can tell that's intended behavior - for most randomness /dev/urandom _never_ blocks, and for the paranoid /dev/random blocks when there's no entropy.

[toast0]

Classically, on Linux you had /dev/urandom which always gave you something, even if the system hadn't achieved a seeded state, and /dev/random which would block in case the system wasn't seeded and also in case random had been used too much without more input into the entropy.

Neither one of those is usable for key generation. urandom may give you repeatable data if the system hasn't seeded itself yet. random may block on accounting that most experts find problematic.

getrandom() finally provided the right semantics of only blocking when the system isn't seeded, and without a filesystem/device node dependency; however changes in startup software, including filesystem improvements have resulted in shortened boot sequences and less entropy gathered. In some cases, systems were blocked waiting on entropy before any (non human interfaced) entropy sources were enabled.

[feanaro]

The issue is that entropy isn't actually expended by generating a large amount of random data from a CSPRNG. Therefore, the only time there is a need for blocking is prior to the initial seeding of the generator. Later on, entropy counting is just hoodoo and cargo culting.