None of those sources strike me as particularly random. For example if I order 30 or 40 Linux machines from Dell for desktops or something then I would be getting nearly identical machines.. same ram, same cpu, same everything. Even the Mac address would be fairly predictable and easy to fine. I suppose you need to get a seed from somewhere, though.
With modern Linux systems if you don't have a keyboard/mouse hooked up it can be a very significant problem to generate enough data for /dev/random. What makes the problem worse is that the modern use of virtualization means that many people are running VMs that suffer a acute shortage of random data. This can lead to a lot of performance issues.
I ran into this while trying to generate some RSA keys for IPsec stuff on various machines running modern kernels. On my local machine the key was generated instantly. On other machines not so much.
All the systems running on top of KVM had severe problems generating keys. On Fedora it just failed straight away. On Debian the keys just blocked.. it would of taken several hours to generate a key that was instantly generated on my laptop using the same system. I was able to work around this problem by connecting to their consoles via spice and literally rubbing my hand over my keyboard until it had enough 'random' data to generate the key. Very irritating. One system in particular was very difficult to deal with. It was running on real hardware, but it simply couldn't generate the 'randomness' that it needed and it was remote so I couldn't just rub the keyboard down.
I've looked into various solutions and the best one I've seen is to purchase a USB random data generator. Other ones like pulling random data from audio or video seemed cool, but I couldn't really get quality data.
Havege was dead simple to use and it seems 'good enough'. It uses the randomness generated by modern system processors. More or less executes some code to strain the cpu in a particular fashion then measures the time it takes to run it.
Now... the only very significant problem I see for it is when it's on virtual machines.
> This issue affects machines running within environments where the RDTSC call has been disabled or handicapped. Currently, the problem seems to be limited to some commercial cloud server providers.
> If affected, this means the RNG produces predictable random and as such security is severely compromised.
I read somewhere that this means that using RDTSC instructions in certain VMs returns 0x0 or some other predictable number, which destroys havege's algorythm's effectiveness. Does anybody know a good way to test these cpu instructions effectiveness in a VM to know if haveged can be safely used?