[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: /dev/random is hot garbage
> 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
> 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.
Main Index |
Thread Index |