¿Qué tan seguro es sembrar PRNG con las secuencias de CSPRNG?

En primer lugar, no hay nada de malo en sembrar un CSPRNG con la salida de otro CSPRNG, en la medida en que la fuente se haya sembrado correctamente en primer lugar.

Como han dicho otros, Mersenne Twister no es un algoritmo criptográfico, por lo que no debe usarlo para un casino.

/dev/random y /dev/urandom se crean utilizando un CSPRNG sólido en casi todos los UNIX modernos, a excepción de los posibles incidentes con una semilla inadecuada que puede usar para cualquier cosa, y en muchos sistemas tampoco se bloqueará una vez que hayan sido correctamente sembrado.

La excepción es Linux, donde se utiliza una antigua función de purín de cosecha propia en lugar de la criptografía moderna. /dev/random bloquea porque teóricamente bajo ciertas suposiciones hace que la salida sea criptográficamente segura, incluso si la función de suspensión no tiene una fuerza criptográfica. Y /dev/urandom tira eso porque entonces uno realmente puede hacer algo de trabajo.

Linux random no se ha roto realmente, solo está en la zona de algunas explotaciones parciales posibles bajo condiciones controladas: enlace

Combinado con las dificultades de obtener solo salidas incompletas y permutadas, no creo que sea probable que un atacante pueda explotar Linux /dev/urandom a través de su sitio. Pero ¿por qué arriesgarlo? Puede usar con seguridad /dev/random para generar una semilla para un CSPRNG adecuado. Siempre que no exponga la salida de /dev/random , no importa si la función de suspensión es criptográficamente sólida o no, una parte aislada de la salida todavía es lo suficientemente impredecible.

Esto ciertamente parece una optimización prematura.

Un CSPRNG rápido en una CPU Intel moderna producirá entre 500 MB y 2 GB por segundo. Incluso si tiene un juego bastante aleatorio que requiere 100 bytes aleatorios por segundo por jugador (no puedo pensar en un juego de casino típico), un solo núcleo podrá generar números aleatorios para diez millones de usuarios simultáneos.

Otras operaciones, como el acceso a la base de datos, el servidor web, etc. serán mucho más caras que generar buenos números aleatorios. Recomiendo sembrar un buen cifrado de flujo como ChaCha o AES-CTR desde el generador aleatorio del sistema en lugar de degradarlo a un PRNG inseguro. Es posible que el generador aleatorio del sistema ya sea suficientemente rápido.

Consulte eBACS para ver los puntos de referencia de los cifrados de flujo.

Usar PRNG no criptográficos como Mersenne-Twister para un casino en línea es una muy mala idea. Estos generadores no apuntan a una impredecibilidad. Solo intentan parecer lo suficientemente aleatorios para que sus fallas no causen ninguna desviación de los datos aleatorios reales que rompen el código de uso por accidente.

Por ejemplo, si ejecutó una simulación científica con MT y con números aleatorios perfectos y dio resultados diferentes, eso se consideraría un defecto en MT. Pero no intenta resistir a alguien que intente deliberadamente predecir el resultado.

Como @CL. Ya dicho, MT es fácilmente predecible una vez que hayas visto unos cientos de salidas. Compare eso con un CSPRNG que será indistinguible para los verdaderos números aleatorios incluso después de observar petabytes de datos.

Wikipedia dice :

  

El algoritmo en su forma nativa no es adecuado para la criptografía (es decir, no es un CSPRNG).   Observar un número suficiente de iteraciones (624 en el caso de MT19937, dado que este es el tamaño del vector de estado a partir del cual se producen las futuras iteraciones) permite predecir todas las iteraciones futuras.

En otras palabras, incluso con una semilla fuerte, solo obtiene unos pocos valores de salida impredecibles. La diferencia entre Mersenne Twister y un CSPRNG es que el último permanece impredecible por mucho más tiempo.

Debe reiniciar el PRNG regularmente. Alternativamente, use un CSPRNG en primer lugar, y concéntrese en optimizar ese para la velocidad.