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.
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.
> 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.