For the lazy, this is a link to a comment by Theodore Ts'o, kernel dev, who says:

> I am so glad I resisted pressure from engineers working at Intel to let /dev/random in Linux rely blindly on the output of the RDRAND instructure. Relying solely on an implementation sealed inside a chip and which is impossible to audit is a BAD idea. Quoting from the article...

Theodore Ts'o is maintainer of the ext filesystems (particularly ext4), as well as, IIRC, /dev/random and other CSRNG related components of the kernel.

Thank you, Theodore Ts'o.

Theodore Ts'o is responsible for perpetuating the myth that entropy/randomness can run out, leading systemd (and other software) to do crazy things, such as trying to use RDRAND, to avoid "drain[ing] randomness from the kernel pool". The bugs and security vulnerabilities resulting from this myth probably neutralize the benefit that came from from his resistance to RDRAND in the kernel.

> the myth that entropy/randomness can run out

Can you expand on this, or link to some sources that expand on this idea that the assumption above is wrong? As a person who has not dealt with crypto really at all I had heard this explained several times before and assumed it was generally accepted.

128-bits of random data is sufficient to securely generate a stream of 100s of terabytes of random data. It's not /that/ hard to find 128-bits of true entropy, even during boot phase. Here's one example:

    1. Seed with any fixed hardware IDs

    2. Mix-in the wall clock time

    3. Spin up a kernel thread and flip a bit on/off in a tight loop. Interrupt it every 100 nanoseconds and take the value of the bit at that time. Do this 256 times. Mix that in too.

    4. Mix-in 256-bits from RDRAND 

    5. Mix-in timings from other interrupts as and when they happen. 
 
    6. Repeat steps 4. and 5. ad infinitum. 

By step 4 we have taken 26 microseconds and we have the kind of entropy I would be comfortable generating an RSA private key with.

Note that step 3 is effectively a measure of how precise the system clock and CPU are. Attacks have been demonstrated against step 3, but they require co-resident processes and don't apply during the boot-phase, if you've got a dedicated core at least. In theory if system clocks and CPU got super precise it could become too deterministic, but the point is the likelihood of /both/ that happening /and/ RDRAND being broken.

>By step 4 we have taken 26 microseconds and we have the kind of entropy I would be comfortable generating an RSA private key with.

And yet Truecrypt made me wiggle the mouse around for like 30 seconds?

> 128-bits of random data is sufficient to securely generate a stream of 100s of terabytes of random data.

What you are describing is /dev/urandom. Your argument is basically "urandom is good enough for anybody". If you want to use that, use it.

/dev/urandom is not always sufficiently seeded.

/dev/random makes sure that it's seeded, then pretends it can run out somehow.

getrandom() with default settings is the right behavior almost always, and it took ages to get implemented.

The most pragmatic explanation is that if 128 or 256 bits of random could run out, the cryptography underlying almost everything we do online would be unsound. If you trust those crypto systems to take a sufficient seed and stretch it, why don't you trust the OS RNG to do so?

You could always read the discussion that was already here on this very page. (-:

* https://news.ycombinator.com/item?id=19850938