Cryptographic weakness on Debian systems

Because there are two sorts of random numbers that you may need from a system. General random
numbers, which don't need to be truly random, but are fine for various applications such as
statistical modeling, games, etc, and cryptographically random numbers, which really truly
need to be as random as possible. You need entropy to generate the latter, and the more
numbers you generate, the more clues there are to work out what inputs the algorithm had, so
you don't want to just use the latter for everything.

Because not all software are only run on systems with /dev/random, and /dev/random doesn't
provide all the needed flexibility that some applications (especially those directly dealing
with security) require (e.g., knowing how much entropy it reflects).

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.

For portability. Lots of OSes don't have it. Lots of other OSes have slightly or seriously
broken /dev/randoms, or /dev/random readable only by root, or something like that.

(Most modern OSes have /dev/random these days, but this certainly was not always the case.)