Comment by colmmacc
7 years ago
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.