[Cryptography] OpenSSL CSPRNG work

[John Denker]

Nemo wrote on 07/05/2017 08:42 PM:

>> The never-blocking /dev/urandom on Linux has been a serious design
>> flaw from the beginning.

Then on 07/06/2017 06:51 AM, Patrick asked:

> What is the problem with a non-blocking /dev/urandom, assuming it was
> seeded with at least 128 unpredictable bits when first initiated?

There is a proverb that says:
  Never confuse the presence of one thing with the absence of another.

A non-blocking RNG is not the problem.  What we need is a RNG
that never blocks *And* never returns insecure results.

A RNG that blocks is a problem.
A RNG that produces insecure results is a problem.
A RNG system that foists on you the choice between blocking and
 insecurity is a problem.

> assuming it was seeded [...]

That assumes away the root of the problem.  Any PRNG is at
the mercy of its seed.

On "most" systems proper seeding is entirely possible, although
the requirements differ from system to system.  Expertise and
attention to detail are required.

On some systems, proper seeding is simply not possible.  Such
systems are not secure and cannot be made secure.  However, this
should not be used as an excuse for doing a bad job on systems
where a good job is possible.

For example, consider a VM booted from the same snapshot
every time, so that it has no persistent writable storage.
That creates problems, but they can be overcome in various
ways that involve cooperation from the host, e.g. via a
virtual /dev/hwrng and/or a seed provided on the kernel
commandline and/or whatever.

  Conversely, you don't want to require every system to
  have a /dev/hwrng and you don't want to require every
  kernel commandline to have a seed, in cases where those
  are not needed.  So like I said, the requirements differ
  from system to system.

Stacking up a bunch of "possible" solutions without verifying
that one of them is an /actual/ solution in a given context
is the opposite of good engineering.