[Cryptography] OpenSSL CSPRNG work

[Theodore Ts'o]

On Sun, Jul 02, 2017 at 10:36:57AM +0200, Florian Weimer wrote:
> 
> For glibc, we are also considering adding an implementation of
> arc4random to an upcoming release.  The consensus view is that we
> cannot use /dev/urandom because it may not be available in chroots.
> We support kernels older than 3.17/3.18, so we cannot assume the
> presence of the getrandom system call.  And getrandom cannot obtain
> randomness if the kernel pool is not initialized (d'oh).

If the kernel pool is not initialized, what hope does glibc have of
getting good seed entropy for its CRNG?  What will you plan to do in
that case?  Please don't say, "oh, we'll just seed from the time and
process id."  :-)

The only thing you can do is what getrandom(2) does, which is block.
If you return an error, you'll run into the problem that most
application programs don't bother checking for error returns.  You can
try to use /dev/urandom, which will provide best efforts randomness,
and probably better than what you can do purely in userspace ---
except you seem to be worried about what to do in chroots.  And so if
you are in a chroot w/o /dev/urandom and someone calls arc4random(),
is it OK if you return crap randomness?

OTOH, I'm not sure it's valid to worry about improperly formed
chroots.  Do you worry about how to run an ELF binary in a chroot is
missing /dev/null?  Or if /dev/tty is missing?  And similarly, what
does "support" for kernels older than 3.17/3.18 mean from a security
perspective when those kernels are probably filled with security
holes?

So if /dev/urandom is missing the only question is does arc4random
fail securely (abort the process with an error message or block), or
fail insecurely (return numbers which appear to be random, but aren't
really)?

					- Ted