[Cryptography] OpenSSL CSPRNG work

[Theodore Ts'o]

On Wed, Jul 05, 2017 at 11:18:26PM +0200, Florian Weimer wrote:
> 
> I already wrote that we're going to use AT_RANDOM (and reseed using
> getrandom once it returns data with GRND_NONBLOCK).  If that AT_RANDOM
> value is not random, it's up to you guys to fix that.

You do know that AT_RANDOM is only present in 2.6.29+ kernels, right?
Are you planning on supporting kernels older than that?  What happens
if a user tries calling arc4random() and they are running on a kernel
which predates AT_RANDOM?

Super-early in the boot process, there may not be a whole lot that we
can do on crappy hardware.  In those cases depending on AT_RANDOM is
not a whole lot different from using /dev/urandom, so from that
perspective I get why you are arguing that blocking is something you
can't do.

I would counter though that at least arc4random() in glibc is a new
interface, and if the new interface blocks, that is much different
than changing an existing interface (e.g., reading from /dev/urandom).

> That's a non-starter because it would halt the boot process.  In the
> futrue, we will need something like arc4random during process
> initialization.  And if we block there, the system will never proceed
> to the point where it generates more entropy.

So if ssh tries to generate long-term private RSA keys (for the host
ssh keys) using arc4random during early boot, it is really a hard
question whether you should block or not.  And I can understand why
glibc developers would prefer never to block.  At some level it
becomes a blame game.

If you have a cheap-sh*t router using crappy hardware with no hardware
RNG, no high resolution timer, and no environmental noise (because the
user might plug in the device before plugging in the network, so there
really isn't a lot even the kernel can work with), and then the
cheap-sh*t router generates a crappy RSA host key, and said cheap-sh*t
router is being used in Trump's private offices in Trump tower and the
Russians use it to break into his system.

Who's to blame?  Trump, for buying a cheap-sh*t router?  The router
manufacturer, for setting up a configuration which is impossible to
secure?  SSH, for insisting that host keys be generated within seconds
of first boot, instead of "on-demand" the first time someone tries
connecting to the host?  Glibc for providing an interface which can be
used to get insecure randomness, despite the claims on the man page?
The kernel, because glibc got the randomness from the kernel, and it's
always easier to blame the kernel devs?  etc.

It's really a systems failure, and at the end of the day, there is
very little that can be done by the kernel and by glibc.  All we can
do is make choices that hopefully lead to a more secure outcome, while
not screwing over existing users and hopefully not make life too hard
for new users....

							- Ted