If it's true you only need about 128 bits of entropy to fuel enough data forever, why is it that /dev/random is so slow? My system has uptime of 214 days!
Is it really only gathering .000000001 bits of entropy every sample? Shouldn't a mere jitter reading from the kernel provide at least 1 bit of entropy? Hasn't it been sampling for the last 214 days?
Is this a colossal design mistake or am I missing something?
BTW, I consider this to be more of question of IT security or Linux operating system than cryptography.
A problem with Linux's /dev/urandom is that it is not possible to test if it has been properly seeded. The random number generator may return values which are based on insufficient entropy.
Thus, many turn to /dev/random instead. However, there are significant differences between /dev/random implementations on different POSIX compliant (or clone) systems. On FreeBSD, /dev/random is works the same than /dev/urandom on Linux. Mac OS X is similar to FreeBSD in many things and also here: /dev/random is just like /dev/urandom.
The goal of Linux /dev/random is to basically return full entropy (one output bit contains one bit of entropy). The approach to this goal is to estimate amount of entropy collected and use that estimate and collected entropy material to produce output. Without Linux support hw-based entropy sources available, the basic entropy collection mechanisms will gather entropy quite slowly.
There are a few ways to accelerate entropy collection, including:
If the /dev/random is empty after long uptime of the machine it means that some applications have been using the randomness devices. In Linux, /dev/random considers that the same amount of entropy is lost from entropy pool than was total amount of bits requested. (I.e. even if linux has full 4096 bits in entropy pool, it still wont take very many requests of say 128 or 256 bits to deplete the pool). Occasionally pool is depleted because some application misuses /dev/random. Some applications may attempt to read large amounts of data, like 2048 bits from it.
Long story short, you should read appropriate man page (man 4 random), and decide if /dev/random or /dev/urandom is actually what you need. If the mac's /dev/random would be ok for you, chances are you would be happy with /dev/urandom. The reason random number generation appeared from /dev/random much faster on Mac is that on Mac /dev/random means something different than /dev/random on Linux. Last, but not least, I would want to say: I like the fact that Linux offers two different semantics, operating systems where /dev/urandom and /dev/random are the same offer much less choice.
I would say this is not colossal mistake, the design is just bit odd from perspective of many. Once you are familiar with the design and restrictions and know how to use the devices, the design feels fairly good.
(BTW, other systems like NetBSD still have little bit different semantics for /dev/random and /dev/urandom.)
