Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

This question already has an answer here:

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?

share|improve this question

migrated from crypto.stackexchange.com Sep 27 '13 at 0:10

This question came from our site for software developers, mathematicians and others interested in cryptography.

marked as duplicate by Gilles, Adnan, Terry Chia, Xander, TildalWave Sep 27 '13 at 14:45

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

I don't understand this question... 128 bit of entropy for what exactly? And in the rest of the question you ask about your own system's inner workings, without giving even the slightest hint what your system is? I think you are missing to state your question clearly, so that it might be answered. –  tylo Sep 26 '13 at 14:59
Good point, Linux. On my Mac it isn't slow. I suspect that its slow out of box and needs to be fixed by reconfig. The 128 bits of entropy is referring to seed the prng. –  Blaze Sep 26 '13 at 16:09
on linux /dev/random only outputs as much data as the estimated entropy of the sources i.e. it aims for information theoretical security. /dev/urandom is a secure PRNG which only aims to be secure against computationally bounded attacks and assumes that its crypto is unbroken. On Mac /dev/random behaves like /dev/urandom on linux. –  CodesInChaos Sep 26 '13 at 16:17
Codes.. Thx, you really should use answers , you'd get selected all the time and it'd be easier to track your profile. Question.. Isn't information theoretical security overkill? –  Blaze Sep 26 '13 at 21:13
add comment

1 Answer 1

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:

  • Use HW entropy sources (e.g. /dev/hwrng), these require e.g. "rngd" program
  • Type characters with keyboards
  • Move mouse (under X Windows)

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. 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.)

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.