Cómo se usa la aleatoriedad en la seguridad

• OpenSSL en Debian. En 2008 se encontró un error en la implementación. Se eliminaron dos líneas críticas en la generación de números aleatorios para usar en la creación de las claves. Esto dejó la función devolviendo números cuyo único factor para alimentar la aleatoriedad era solamente el PID del proceso (entre 1 y 32768). Estas líneas fueron eliminadas por sugerencia de Valgrind (un software que busca fugas de memoria en códigos C) mientras se depuraba el código de OpenSSL.
• Otro caso sonado fue el de Windows 2000 y XP. A finales de 2007,  se descubrió una debilidad en su código de generación de números pseudoaleatorios. Aunque sin disponer del algoritmo, se consiguió llegar a un punto en el que un posible atacante podría predecir los números que habían sido generados previamente y podrían ser generados en un futuro. 
• En 2010, la Play Station 3 sufrió también las consecuencias de una mala implementación en la generación de números pseudoaleatorios. En realidad, ni siquiera había aleatoriedad. La generación de claves privadas ocurría siempre a partir del mismo número, por lo que cualquier persona podía firmar una aplicación para PS3.
• En agosto de 2013, se supo que la función SecureRandom que usa Android no accedía a /dev/urandom (cuando debería). Cualquier software que usara esa función se veía afectado, por ejemplo, las carteras de bitcoins.
• Hace muy poco, durante la CanSecWest, se descubrió que en la versión 7 de iOS se introdujeron problemas en su generador de números.

/dev/random y /dev/urandom son dos archivos especiales en el Kernel de Linux cuya función es mantener una fuente de entropía (como una especie de almacén) que consigue de diferentes fuentes (como las mencionadas anteriormente). Desde esa fuente selecciona algunos bytes de entropía y genera un número aleatorio cuando se le llama.
No se suele hacer una llamada directa de sistema a /dev/random y a /dev/urandom en busca de números aleatorios, sino que se consiguen una serie de bytes de cualquiera de las dos fuentes y se usan como semillas para métodos/funciones implementadas en el programa que las necesite, a modo de PRNG. Cada programa podrá tener su PRNG.
Veámoslo con un pequeño diagrama:

Esquema básico de funcionamiento de /dev/random y /dev/urandom

En él se observa cómo se “rellenan” (de forma simplificada) /dev/random y /dev/urandom. Del colector de entropía (de las fuentes que hemos mencionado antes) se estima la cantidad útil y se suma al contador de entropía. A esta entropía se le quita parte del bias (eliminación de muestras no válidas por diversas razones)  y después de pasar por el generador de números pseudoaleatorios es añadido a la fuente de aleatoriedad.

Volcado directo de /dev/random

Por el contrario, en la siguiente animación, se comprueba que /dev/urandom devuelve tanto como se le pida, sin bloqueos, puesto que no espera a que la entropía sea suficiente.

Volcado directo de /dev/urandom

.

• /dev/random ofrece números con aleatoriedad “de mayor calidad”, pero el bloqueo puede ser un problema si se encuentra bajo gran demanda.
• /dev/urandom ofrece números con aleatoriedad “menor” pero sin bloqueos ni “esperas”. 

Existen muchos puntos de vista al respecto sobre cuál usar para qué, pero está relativamente establecido que para generar claves criptográficas que vayan a tener una larga duración, como las usadas en SSH o SSL se debe usar /dev/random. Para prácticamente todos los demás usos, es más rápido y menos “arriesgado” utilizar /dev/urandom.