This software does use /dev/random (if configured to do so).
But although it might be tempting to get random numbers by just opening /dev/random and
reading bytes out of it, and although this would, indeed, actually work, it is not the
recommended way to go about things because it depletes a very limited resource, and it's also
not at all portable...
So, OpenSSL and similar software always includes its own entropy pool handling, so that it can
use /dev/random just as a seed (treating the system entropy source as the limited supply that
it is) and also so that it can integrate other entropy sources without having to sprinkle
conditionals for each platform throughout the code.
Perhaps there's a case to be made for "simpler is best" and everything just tapping into
/dev/urandom for its source of random numbers. But there's a price to pay for that, which not
everyone is comfortable with.
Posted May 14, 2008 21:19 UTC (Wed) by alankila (subscriber, #47141)
[Link]
What exactly is the price you allude to? Predictability of the random numbers? Some kind of
timing-related attack, because packet arrival times may affect the entropy pool input? A
kernel exploit that allows simultaneous compromise of all applications using the /dev/u?random
file?