> Date: Sun, 21 Jul 2019 11:55:23 -0400 > From: Greg Troxel <[email protected]> > > I don't think we should change /dev/random. For a very long time, the > notion is that the bits from /dev/random really are ok for keys, and > there has been a notion that such bits are precious and you should be > prepared to wait. If you aren't generating a key, you shouldn't read > from /dev/random.
This notion has been around for a long time, but it doesn't quite match modern cryptography: once you have a 256-bit secret you can have as many secret bits as you want. What reading from /dev/random does that _is_ useful in modern cryptography is that it serves as a barrier to wait for that initial secret. So there's no need to read more than a single byte from it to wait. (One can reject this premise of cryptography, and refuse to use it, and reject TLS/SSH/&c. and everything else, but I'm not interested in getting into those weeds.) > So I think rust is wrong and should be fixed. What Rust's vendor/rand library is doing is sensible _for some goal_: it is waiting for the entropy pool to be seeded before generating keys. Applications may depend on it to do this _at least once_; the trouble arises when applications block on a single byte over and over again. > It would also be reasonable to have a sysctl to allow /dev/random to > return bytes anyway, like urandom would, and to turn this on for our xen > builders, as a different workaround. That's easy, and it doesn't break > the way things are supposed to be for people that don't ask for it. What's the advantage of this over using replacing /dev/random by a symlink to /dev/urandom in the build system? A symlink can be restricted to a chroot, while a sysctl knob would affect the host outside the chroot. The two would presumably require essentially the same privileges to enact.
