¿Es adecuado `/ dev / urandom` para propósitos de simulación?

Parece que al utilizar C simple en sistemas similares a Unix, la forma más sencilla de extraer bytes aleatorios de alta calidad es fread de /dev/urandom . Necesito ejecutar una simulación que necesita aproximadamente 10k números aleatorios de 32 bits por segundo, y puede durar varios días. ¿Se puede usar /dev/urandom para este propósito? ¿Cómo es la calidad de los bytes aleatorios desde aquí cuando la agrupación de entropía se agota?

edit_1

Mientras que ahora estoy ejecutando 3 pruebas de detección en paralelo para /dev/urandom en mi computadora portátil, obtuve las siguientes líneas interesantes. La prueba aún no está completa.

 #=============================================================================# test_name |ntup| tsamples |psamples| p-value |Assessment #=============================================================================# diehard_parking_lot| 0| 12000| 100|0.99573896| WEAK diehard_sums| 0| 100| 100|0.00116464| WEAK sts_serial| 7| 100000| 100|0.99996076| WEAK 

En la implementación subyacente de /dev/urandom es un CSPRNG, cuyo conjunto de salida tiene un período máximo de menos de 2 ^ (26 ∗ 32) – 1 , que luego se alimenta a SHA-1 para producir una salida para /dev/urandom Como tal, urandom obviamente puede producir la cantidad de números aleatorios que desee, sin embargo, no puede ofrecerle resultados reproducibles; tendrá que almacenar en caché la secuencia que obtenga usted mismo.

No tiene que preocuparse por lo que sucede cuando se estima que el grupo de entropía está agotado, /dev/urandom producirá lo que usted solicite. Los “ataques teóricos” de los que habla la página de manual de urandom (4) son inexistentes . (El “problema” es un gran malentendido de lo que es la “estimación de la entropía”)

Existen muchos otros PRNG con grandes periodos que pueden reproducirse: el Mersenne Twister en C ++ , los PRNG xorshift, etc. Debe poder adaptar cualquier PRNG a la distribución que sea adecuada para sus propósitos.

No, / dev / random y / dev / urandom están diseñados para aplicaciones criptográficas donde se desea una entropía muy alta a cambio de la velocidad. Se ejecutan muy lentamente en comparación con un buen PRNG sin CS, por lo que no le darán suficientes muestras para la simulación o la integración de Monte Carlo.

Para estos, use un PRNG rápido pero de buena calidad como XOR-shift + o Mersenne Twister. Puede sembrar el PRNG con datos de / dev / urandom si no necesita repetibilidad.

No, no debe usar /dev/urandom intensiva, al menos de acuerdo con la documentación [aunque si lee el hilo de comentarios, encontrará un argumento de que la documentación es engañosa]:

El generador de números aleatorios del núcleo está diseñado para producir una pequeña cantidad de material de semilla de alta calidad para sembrar un generador de números pseudoaleatorios criptográficos (CPRNG). Está diseñado para la seguridad, no la velocidad, y está mal adaptado para generar grandes cantidades de datos aleatorios. Los usuarios deben ser muy económicos en la cantidad de material semilla que leen de / dev / urandom (y / dev / random); La lectura innecesaria de grandes cantidades de datos de este dispositivo tendrá un impacto negativo en otros usuarios del dispositivo. (Fuente: linux man 4 random )

Las implementaciones tempranas (pre 2.6) de Linux de /dev/urandom compartieron un grupo de entropía entre /dev/random y /dev/urandom , pero en estos días los grupos utilizados son algo independientes, y la lectura de /dev/urandom no afectará la disponibilidad de /dev/random . Otros sistemas operativos utilizan diferentes estrategias. En FreeBSD, por ejemplo, solo hay un dispositivo aleatorio, que solo bloquea al inicio del sistema.

En general, mi recomendación es que la entropía se considere como un recurso y no se consum en grandes cantidades en ausencia de una necesidad clara, aunque solo sea para evitar llamadas al sistema demasiado frecuentes e innecesarias, que son relativamente caras.

En cualquier caso, para la simulación de monte carlo donde no se requiere aleatoriedad criptográfica, debería estar bien con un buen PRNG; para pruebas independientes, debe agregar el PRNG de una sola lectura de /dev/urandom . (Sembrar a partir del time(NULL) nunca es una buena idea.)

En cuanto a la “calidad de los bytes aleatorios de [ /dev/urandom ] cuando el grupo de entropía se agota”, O’Neill (2014) señala que los diseñadores de generadores con fines criptográficos “no tienen las mismas preocupaciones sobre las propiedades estadísticas (como como uniformidad) en comparación con los generadores de números aleatorios de propósito general “.

Esto puede explicar por qué la salida de /dev/urandom falla las pruebas estadísticas, aunque el consenso parece ser que la salida de /dev/urandom es buena incluso después del agotamiento.

Si desea combinar las propiedades de /dev/urandom y un generador estándar para propósitos de simulación como Mersenne Twister, mi sugerencia sería exortar ambos flujos de datos. Los enfoques son lo suficientemente diferentes como para que no se cancelen entre sí.

Ref: http://www.pcg-random.org/paper.html