For some applications (e.g., using libraries that rely on cryptonite's getRandomBytes run in IO on architectures without the RDRAND instruction), it would be useful to have a source of entropy on HaLVM with a transparent interface via reading /dev/urandom. This branch accomplishes that.
If --enable-urandom is passed to configure, the functions in System.IO, Data.ByteString, etc., that could be used to read /dev/urandom succeed. The bytes returned are the output of a port of the ChaCha20 CRNG used in Linux 4.14 for /dev/urandom. The CRNG is seeded with the low-order bits of multiple invocations of rdtsc, which is what Linux does on x86_64 when RDRAND isn't available.
If nothing or --disable-urandom is passed to configure, all associated code is removed by the prerocessor.
protoben
commented
6 years ago
For some applications (e.g., using libraries that rely on
cryptonite'sgetRandomBytesrun inIOon architectures without the RDRAND instruction), it would be useful to have a source of entropy on HaLVM with a transparent interface via reading/dev/urandom. This branch accomplishes that.If
--enable-urandomis passed toconfigure, the functions inSystem.IO,Data.ByteString, etc., that could be used to read/dev/urandomsucceed. The bytes returned are the output of a port of the ChaCha20 CRNG used in Linux 4.14 for/dev/urandom. The CRNG is seeded with the low-order bits of multiple invocations ofrdtsc, which is what Linux does onx86_64whenRDRANDisn't available.If nothing or
--disable-urandomis passed toconfigure, all associated code is removed by the prerocessor.