Aleatoriedade significa que o próximo valor que você recebe não depende do valor anterior e não há como predizer isso.
Isso é realmente difícil para um computador, já que um computador é basicamente uma calculadora muito rápida - então ele pode fazer matemática, mas sempre obterá a resposta exata todas as vezes. Você pode fazer algo próximo a aleatoriedade com matemática chamada "pseudo-aleatoriedade" - mas não é alta qualidade o suficiente para ser usada para criptografia.
O Linux coleta "aleatoriedade" em conjuntos de várias fontes (como o tempo entre eventos de entrada). A "quantidade" de aleatoriedade neste conjunto é a entropia. Menos entropia = padrões menos regulares, repetitivos e previsíveis - você quer o máximo de entropia possível. O kernel do Linux "preencherá" seu conjunto com entropia quando estiver baixo, mas isso depende do que está acontecendo no sistema, já que ele usa o tempo entre eventos de hardware imprevisíveis para gerá-lo.
Se o conjunto estiver vazio, /dev/random irá bloquear , ou parar de fornecer dados, até que o kernel obtenha entropia suficiente.
/dev/urandom continuará - usando técnicas pseudo-aleatórias para gerar números aleatórios.
Agora que você tem o básico, você sempre pode usar urandom e aqui está o porquê .
Veja um trecho desse artigo explicando por que isso não importa:
But let's assume you've obtained those “true” random numbers. What are you going to do with them?
You print them out, frame them and hang them on your living-room wall, to revel in the beauty of a quantum universe? That's great, and I certainly understand.
Wait, what? You're using them? For cryptographic purposes? Well, that spoils everything, because now things get a bit ugly.
You see, your truly-random, quantum effect blessed random numbers are put into some less respectable, real-world tarnished algorithms.
Because almost all of the cryptographic algorithms we use do not hold up to information-theoretic security. They can “only” offer computational security. The two exceptions that come to my mind are Shamir's Secret Sharing and the One-time pad. And while the first one may be a valid counterpoint (if you actually intend to use it), the latter is utterly impractical.
But all those algorithms you know about, aes, rsa, Diffie-Hellman, Elliptic curves, and all those crypto packages you're using, OpenSSL, GnuTLS, Keyczar, your operating system's crypto API, these are only computationally secure.
What's the difference? While information-theoretically secure algorithms are secure, period, those other algorithms cannot guarantee security against an adversary with unlimited computational power who's trying all possibilities for keys. We still use them because it would take all the computers in the world taken together longer than the universe has existed, so far. That's the level of “insecurity” we're talking about here.
Unless some clever guy breaks the algorithm itself, using much less computational power. Even computational power achievable today. That's the big prize every cryptanalyst dreams about: breaking aes itself, breaking rsa itself and so on.
So now we're at the point where you don't trust the inner building blocks of the random number generator, insisting on “true randomness” instead of “pseudo randomness”. But then you're using those “true” random numbers in algorithms that you so despise that you didn't want them near your random number generator in the first place!
Truth is, when state-of-the-art hash algorithms are broken, or when state-of-the-art block ciphers are broken, it doesn't matter that you get “philosophically insecure” random numbers because of them. You've got nothing left to securely use them for anyway.
So just use those computationally-secure random numbers for your computationally-secure algorithms. In other words: use /dev/urandom.