/dev/urandom
es una buena opción, pero getrandom
system call sería ideal, utilizando las banderas predeterminadas.
En cuanto a las referencias, este artículo no es estrictamente académico, pero es una lectura razonablemente fácil, y cita Un número de expertos en apoyo de sus explicaciones. Creo que este pasaje, que cita el artículo de Daniel Bernstein, merece la pena reproducirse:
Los criptógrafos ciertamente no son responsables de este disparate supersticioso. Piense en esto por un momento: quien haya escrito la página de manual / dev / random parece creer simultáneamente que
- no podemos descubrir cómo expandir de manera determinista una salida de 256 bits / dev / random en un flujo interminable de claves impredecibles (esto es lo que necesitamos de urandom), pero
- podemos descubrir cómo usar una sola clave para cifrar de manera segura muchos mensajes (esto es lo que necesitamos de SSL, PGP, etc.).
Para un criptógrafo, esto ni siquiera pasa la prueba de risa.
El artículo que has vinculado es más una preocupación teórica que práctica. Lo que significa no es que el diseño de Linux RNG sea malo estrictamente hablando, sino que no es óptimo en varios aspectos, que sin embargo solo se aplican en un escenario muy estrecho: cuando un atacante ha logrado ver el estado del RNG en algún momento en su ejecución, pero (a) ya no puede ver los estados más nuevos y (b) puede influir en su entrada de entropía. Eso es muy específico : se encuentra a una distancia muy precisa de la operación normal (cuando el adversario no ha visto el estado de RNG) y en el peor de los casos (donde el atacante ha comprometido completamente el RNG y puede ver el estado repetidamente).