4 ms·
Sorta: if your CSPRNG is weird/broken then you have way worse problems, so just use your CSPRNG. If your CSPRNG is fine, adding global counters, timestamps, upt
by lvh 9y ago
Sorta: if your CSPRNG is weird/broken then you have way worse problems, so just use your CSPRNG. If your CSPRNG is fine, adding global counters, timestamps, uptime... makes no sense.
(Also, you should use /dev/urandom, not /dev/random. Or getentropy/getrandom/CryptGenRandom, depending on your OS.)
- CJefferson 9y agoCSPRNG can be badly behaved at startup time on virtual machines, and there have been problems with bad random numbers at start up time. Adding wall clock time to the mix wouldn't hurt.
- lvh 9y agoWhich operating system do you run where time isn't already in the CSPRNG pool?
- CJefferson 9y agoI believe Linux only uses physical devices (which are very limited in some VMs), but this might just be folk-legend (I haven't read the source).
- lvh 9y agoNo, Linux' random.c has add_device_randomness (sp? it's definitely something_device_randomness), which includes a bunch of machine-specific things to the RNG, including MAC addresses, serial numbers, and, crucially, the RTC.
- CJefferson 9y agoI'm obviously misinformed. Thanks for that.