Re: /dev/random is hot garbage

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

> Date: Sun, 21 Jul 2019 20:52:52 +0200
> From: Manuel Bouyer <bouyer%antioche.eu.org@localhost>
> 
> /dev/randon actually works as documented and if rust wants /dev/urandom
> behavior it should use /dev/urandom. Also I'd like to get explained why
> a compiler needs that much random bits.

The difference is that /dev/random may block, and if it blocks, it
doesn't wake up until the entropy pool is seeded.  In contrast,
/dev/urandom never blocks, even if the entropy pool has not yet been
seeded.

There is no reason in modern cryptography to read more than one byte
from /dev/random ever in a single application; once you have done
that, or confirmed some other way that the the entropy pool is seeded,
you should generate keys from /dev/urandom.

What Rust's vendor/rand library seems to guarantee for its callers is
that it won't return any data until the entropy pool has been seeded,
and then it will return arbitrarily much data without ever blocking
again.  It does this by reading a single byte from /dev/random, and
then generating keys from /dev/urandom.

This is _locally_ sensible for a library that may have many users
beyond a compiler.  But what seems to be happening (although I haven't
dived into the build process myself to confirm) is that many
subprocesses in the build process are _indepenently_ initializing the
Rust vendor/rand library -- reading one byte from /dev/random, which
sometimes blocks.

In a build chroot, or in a Xen guest, where you aren't handling any
secrets (e.g., no sshd except on the local network, no package
signing, &c.), you can replace /dev/random by a symlink to
/dev/urandom and the build will never block.