The problem is that &#x2F;dev&#x2F;random is too paranoid. It refuses to work if there isn&#x27;t enough entropy in the pool, yes. But when it produces numbers, it subtracts that amount from the supposed amount of entropy in the pool. Thus it will refuse to work again pretty soon in a lot of circumstances where it&#x27;s still completely safe to proceed.<p>For a concrete example, you start out with zero bits in the pool. &#x2F;dev&#x2F;urandom will produce a predictable stream of bits. This is extremely bad. &#x2F;dev&#x2F;random will block. this is good.<p>Now you add 1024 bits to the pool. Both &#x2F;dev&#x2F;random and &#x2F;dev&#x2F;urandom will produce good numbers.<p>Now let&#x27;s say you read 1024 bits from &#x2F;dev&#x2F;random. This will reduce the entropy counter back to zero. If you then try to read another 1024 bits from &#x2F;dev&#x2F;random, it will block.<p>But this is nonsense! Those 1024 bits you added before aren&#x27;t depleted just because you pulled 1024 from &#x2F;dev&#x2F;random! It is perfectly safe to proceed generating more numbers at this point (or at least it&#x27;s as safe as it was before), but &#x2F;dev&#x2F;random refuses to.<p>Many systems don&#x27;t add entropy to the pool very quickly so it&#x27;s entirely possible to &quot;deplete&quot; it in this way. Then your code using &#x2F;dev&#x2F;random wedges and you have a problem. However, few systems are ever in a state where they have zero entropy. Thus the advice to use &#x2F;dev&#x2F;urandom.<p>Ideally, you&#x27;d want a device which blocks if and only if the entropy pool hasn&#x27;t been properly seeded yet, but which never blocks again after that point. Apparently this is what the BSDs do, but Linux doesn&#x27;t have one.