/dev/urandom
è una buona scelta, ma la chiamata di sistema getrandom
sarebbe l'ideale, usando i flag di default.
Per quanto riguarda i riferimenti, questo articolo non è strettamente accademico, ma è una lettura ragionevolmente facile, e cita un certo numero di esperti a sostegno delle sue spiegazioni. Penso che questo passaggio, che l'articolo cita Daniel Bernstein, valga la pena di riprodurlo:
Cryptographers are certainly not responsible for this superstitious nonsense. Think about this for a moment: whoever wrote the /dev/random manual page seems to simultaneously believe that
- we can't figure out how to deterministically expand one 256-bit /dev/random output into an endless stream of unpredictable keys (this is what we need from urandom), but
- we can figure out how to use a single key to safely encrypt many messages (this is what we need from SSL, PGP, etc.).
For a cryptographer this doesn't even pass the laugh test.
L'articolo che hai collegato è più di una preoccupazione teorica che pratica. Ciò che significa non è che il design RNG di Linux sia in senso stretto, ma che non sia ottimale in una serie di aspetti, che tuttavia si applicano solo in uno scenario molto ristretto: quando un utente malintenzionato è riuscito a vedere lo stato del RNG ad un certo punto nella sua esecuzione ma (a) non è più in grado di vedere gli stati più recenti e (b) è in grado di influenzare il suo input entropico. Questo è molto specifico - si trova ad una distanza molto precisa dal normale funzionamento (quando l'avversario non ha visto lo stato RNG) e nel caso peggiore (dove l'attaccante ha completamente compromesso il RNG ed è in grado per vedere più volte lo stato).