Re: /dev/random is hot garbage

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

> Date: Sun, 21 Jul 2019 11:55:23 -0400
> From: Greg Troxel <gdt%lexort.com@localhost>
> 
> 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.