> Firstly, a freely oscillating circuit inside the CPU to generate random bits doesn't seem complicated to me. It should extract true randomness as fast as you could move bits from the CPU to memory. Why hasn't it been done?
I think a few Intel CPUs implement some form of hardware entropy generation. I don't know the feature very well. There is Via Padlock, which will do this, but I don't have one of those systems. There are a few examples besides that.
I think there are a few problems. One of which is that generating entropy is a lot harder then it sounds like it should be. Another problem is that for many interested parties who would want a good source of entropy there is a number of certification requirements that they have to deal with and for hardware manufacturers it likely expensive and irritating to deal with.
I know from my work with embedded devices used in various places we could not take advantage of the Via padlock system due to it not being up to certification requirements.
(these certifications are largely a bureaucratic matter based mostly around documentation and provability of correctness using certain specific tests. It's very possible to have a secure system that doesn't match government requirements (thus being illegal), but have a insecure one that does. (thus being legal))
> It only takes in the hundreds of bits range of true randomness to properly seed a random number generator, after which it can be run for significant periods (probably years?) without leaking the prng state. In fact, if you unpredictably flip the bits in the prng state based on true random inputs, the problem seems entirely solved to me, as no amount of reading the prng output reveals anything consistent about its state. Am I missing something, again?
I don't know. This does not seem to be a solved problem. I don't know the details, but I know if it is a solved problem then I wouldn't be having these problems with /dev/random and there wouldn't be any reason to have /dev/urandom. It seems that it would be a simple thing to have a PRNG generator in the kernel then to eliminate all the problems people have with dealing with large numbers of SSL connections and such things. It would simplify matters massively.
Haveged seems like a decent solution, but like that advisory said that 'HAVEGE' depends (which is what haveged is based on) on RDTSC to be functioning. Now I know the deamon itself sources the data from the algorithm and then feeds it through PRNG and it could be doing other things for random data, so the actual daemon may not have the same weakness that the algorithm does.
> (Hypothetical answer: people simply are really paranoid about randomness of their random numbers. But is such paranoia justified?)
It can be justified based on the circumstances. Well funded corporate espionage is real. 'Hackivism' is real. Military security concerns are real. Professional organized computer criminals are real. People trying to pursue and defeat governments attempts to monitor and document their activities is real. It's easy to half-ass things and have it work fine, but it's very difficult to be able to prove if it's actually working correctly.
I don't have any strong reason to care right now and probably just symbolic linking /dev/urandom to /dev/random would be perfectly fine for my purposes... however I would like to know the right way to do things and I don't have the expertise to figure it out for myself. :(