On Tue, Jul 05, 2016 at 09:33:04PM -0500, Rob Landley wrote: > On 07/05/2016 06:42 AM, Etienne Champetier wrote: > >> You've implied that this new API can block until it's initialized, which > >> reading from /dev/random can already do, and presumably > >> select/poll/inotify could do on /dev/random without consuming entropy. > > > > As shown in my mail from 29 june 2016 at 15:54 > > [ 14.321536] ### getrandom ### > > [ 42.603677] ### dd ### > > > > getrandom() wait until /dev/urandom is initialized, which can be way > > before /dev/random is initialized > > Ok, this is a new assertion. How does that work? How would /dev/urandom > get random data to seed it without /dev/random having enough entropy for > one byte of output?
The key point is that /dev/random is "tinfoil hat compliant". The things it does (and especially considering entropy to become "depleted") have no basis in reality but can't change because people will complain (bikeshedding). /dev/random is safe to use, but very slow and costly, _even after_ it has collected sufficient entropy (because it wrongly considers that entropy to become "depleted"). On the other hand, /dev/urandom has a problem that it will give results before sufficient entropy has been collected, resulting in duplicate sequences (and thus duplicate keys generated) on identical devices with a fairly high probability. The getrandom syscall was added both to address this deficiency in urandom, and to address the case where random bytes are needed but no file descriptors are available (to protect against fd exhaustion attacks undermining crypto, basically). Rich _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
