Denis Gauthier, Oracle
OpenSSL provides entropy for the non FIPS case, but not for the FIPS case.
BYOE - Bring your own entropy, if you're running in FIPS mode.
OpenSSL gets its entropy from /dev/urandom, /dev/random, /dev/srandom, but since /dev/urandom doesn't block, that's effectively where OpenSSL gets most of its entropy. And it never reseeds. We likely didn't have enough when we started, and certainly not later.
Reseeding: not everyone will get it right... there are too many deadlines and competing priorities. Looking at an ubuntu example, based only on time(0)... not good entropy.
There is no universal solution - the amount varies with each source and its operating environment. Use hardware, if it's available. Software will rely on timers - because, hopefully, events don't happen at predictable times (not to the nanosecond).
There is a misconception that keyboard strokes and mouse movements will give you a lot of entropy... unless the machine is a headless server... :)
You could use Turbid and Randomsound to gather entropy from your soundcard.
There are a lot of software sources, like CPU, diskstats, HAVEGED, interrupts, IO, memory, net-dev, time, timer-list and TSC. Denis had a cool graph about how much entropy he was getting from these various places.
You need to do due diligence, doing careful evaluation of your sources. Things are not always as advertised. Not just convincing yourself, but making sure the folks you're selling to trust your choices as well.
The best thing - diversify! You need multiple independent sources. Use a scheduler to handle reseeding for forward secrecy. But, be careful not to starve sources, either.
When using OpenSSL, bring your own entropy and reseed.
Testing 1, 2, 3 - Dropsafe is now entirely solid-state…