Closed mksh closed 1 year ago
Problem: Rust's
rng
by default usesThreadRng
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 asdd 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.
Problem: Rust's
rng
by default usesThreadRng
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 asdd if=/dev/random
See https://man7.org/linux/man-pages/man2/getrandom.2.html man for details