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.
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.
And yet Truecrypt made me wiggle the mouse around for like 30 seconds?
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/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.
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.