[openssl-dev] what's possible and what's not ... including RNGs

John Denker ssx at av8n.com
Thu Jun 29 18:28:24 UTC 2017


On 06/29/2017 08:01 AM, I wrote:

> Some platforms are not secure and cannot be made secure.

This is relevant to the RNG discussion, and lots of other
stuff besides.

*) For example, you can use openssl rsa to generate a so-called
 private key, but it will not actually be private (in any
 practical sense) if the operating system's RNG has been
 compromised.  There is little that openssl can do to detect
 this problem.  RNGs are infamously hard to test.

*) As another example, a VM guest is at the mercy of the host.

*) Don't enable remote administration using "admin" as the
 root password.

*) Etc. etc. etc.

All this "should" be obvious.  However, there are lots of people
who use openssl but don't know much about security in general
or crypto in particular.  Therefore the limitations need to be
prominently mentioned in the openssl documentation.  That's not
sufficient by itself, but it counts as a step in the right
direction.

Series metaphor:  A chain is only as strong as its weakest link.
Parallel metaphor:  A fence is only as strong as its weakest picket.

One of the defining properties of modern civilization is division
of labor.  You simply cannot have everybody be responsible for
everything.  We make jokes when the division is done improperly:
   https://www.av8n.com/physics/not-my-job.htm

but even so, a great many divisions are necessary.

 -- If you hire a locksmith to install a deadbolt on your front
  door, that does not make him responsible for the fact that the
  back door is made of balsa wood, and the side door is standing
  wide open.

 ++ If you hire a security consultant to look at the big picture,
  that's different.

 +- The locksmith MAY remark on security problems that he notices,
  but he is not obliged to fix them, or even to search for them.

In this parable, openssl is the locksmith.  The project does not
have the resources to do much beyond basic locksmithing.

========

There are deep issues here that I don't know how to solve.  For
example, what should be done when the situation is discovered
to be insecure?
 a) Ignore the discovery and soldier on?
 b) Print a warning?
 c) Block?

Blocking generally infuriates the users.  They replace the
offending software with something that doesn't block, even if
it's less secure.

Warnings aren't much better.  It does little good to print a
warning about a problem that the user does not understand and
could not solve.

Ignorance is not bliss.
Into the valley of death rode the six hundred.

Asking the user a question that has no good answers, e.g. to
choose between /dev/random and /dev/urandom, does not solve
the problem at all.

=================================

On 06/29/2017 10:07 AM, Theo de Raadt wrote:

>> As has been said many times before, what we need (but do not have)
>> is /one/ source of randomness that never blocks and never returns
>> bits that are guessable by the adversary.

> I've been preaching this for more than a decade, and that is exactly
> what I built in OpenBSD.

> It isn't very hard to do this properly in the kernel.

Sometimes it's not very hard ... but sometimes it's provably impossible,
depending on what sort of support is available from the hardware.  I
stand by the assertion that some platforms are not secure and cannot
be made secure.  RNGs are one manifestation of this, among others.


More information about the openssl-dev mailing list