Switch to use getrandom(2) as source of randomness

[mksh]

Problem: Rust's rng by default uses ThreadRng which is pseudo-random number generator, seeded from the system random.

Solution: instead of using Rust algorithms, defer random number generation to system random generator implementation, interfaced via https://github.com/rust-random/getrandom

getrandom(2) should be secure enough for use for end-user key generation, it is merely the same as dd if=/dev/random See https://man7.org/linux/man-pages/man2/getrandom.2.html man for details

[jenpaff]

Problem: Rust's rng by default uses ThreadRng which is pseudo-random number generator, seeded from the system random.

Solution: instead of using Rust algorithms, defer random number generation to system random generator implementation

https://docs.rs/rand/0.5.0/rand/rngs/struct.OsRng.html

Linux, Android: reads from the getrandom(2) system call if available, otherwise from /dev/urandom. macOS, iOS: calls SecRandomCopyBytes. Windows: calls RtlGenRandom.

getrandom(2) should be secure enough for use for end-user key generation, it is merely the same as dd if=/dev/random See https://man7.org/linux/man-pages/man2/getrandom.2.html man for details

If we're deciding to move away from a PRNG, then this sounds like a fair solution. ThreadRng actually uses OsRng for its entropy pool, so this change would mean that we defer completely to the random number generator.

I'm still wondering about the trade-off security vs efficiency when it comes to using PRNG vs RNG. From the docs I read

OsRng usually does not block. On some systems, and notably virtual machines, it may block very early in the init process, when the OS CSPRNG has not yet been seeded.

• will entropy gathering be a problem for us? Should we just go for it and implement the more secure way and monitor during testing?