[Cryptography] OpenSSL and random

John Denker jsd at av8n.com
Fri Dec 2 19:51:26 EST 2016


> On 11/30/16 at 11:43 AM, I wrote:

>> I say again:  /dev/random must learn to never block, and /dev/urandom
>> must learn to never emit untrustworthy bits, whereupon the specification
>> is the same for both.  The same goes for getrandom() and getentropy():
>> they must never block, and they must never emit untrustworthy bits.

I stand by that.

On 12/01/2016 10:24 PM, Bill Frantz wrote:

> I think we would all love to be in this state.

Yes.  That's what users need.  We need to keep focused on that.

> How do we get there?

That's the right question.

> What does OpenSSL do since it lives in the real world?

That's mostly the same question.  Openssl and a bazillion other users
all face similar problems.

The answer has several ingredients:

In the short run, openssl and everybody else need to publish some
disclaimers, perhaps:

	Some platforms are not secure, and cannot be made secure.  It
	is sometimes impossible for openssl by itself to detect the
	problems, let alone fix them.  For starters, if the platform
	does not have an audio card or other hardware-based source of
	randomness, somebody MUST provide a high-quality random seed
	file, and it is sometimes impossible for openssl to be sure
	this has been done properly.  In some cases the system is
	already compromised long before the openssl-based apps begin
	to run.  Security requires attention to detail.  It doesn't do
	much good to triple-lock the front door while the side door
	and the windows are standing open.

Like everybody else, openssl needs a RNG that never blocks and never
produces low-quality randomness.  That is an achievable goal, and
AFAICT the only reasonable goal.

In the short term, on linux platforms, that implies all of the
following:
  a) use /dev/urandom, because it never blocks, *and*
  b) take strong measures to provide it with a proper seed, *and*
  c) keep in mind that sometimes proper seeding is impossible, and
   improper seeding is undetectable, and either way the system is
   not secure.

In the slightly-longer term, the work of Ard Biesheuvel is important,
since grub provides a way -- one of the few decent ways -- of providing
a sufficiently-early sufficiently-random seed.  This approach should
work on the vast, vast majority of laptops, desktops, and server-rack-
class machines.  Certain other high-volume platforms e.g. Mac and
Android are deployed by control freaks, who will have to take full
responsibility for providing suitable randomness.

Returning to the short term, if you can't for the desired grub + kernel
features, you can attempt to stir /dev/urandom yourself.  The two
easiest ways are
 a) Sneakernet.
 b) Using a hardware source.  In most cases the audio system is
  far and away the best quality and least hassle.

Both of these options are discussed in some detail near the top of
  https://www.av8n.com/computer/htm/secure-random.htm

> The disto people have to figure out how to delay using random/urandom
> until it is initialized.               [1]

That is so non-quantitative that there is no way of knowing whether it
is completely right or completely wrong.  Until somebody provides a
hard upper bound on how long initialization will take, and a hard lower
bound on how long users are willing to wait, statements of the form [1]
are useless for real-world engineering.


On 12/02/2016 09:52 AM, Jason Cooper wrote:

>> I hate to be pedantic, but how about not creating the /dev/[u]random
>> nodes until sufficient entropy is achieved?

That is not a solution.  Users really need the randomness.  If they don't
get it from the platform, they will not wait around.  They just won't,
as Rich and Peter and others have pointed out.  Instead they will cobble
up some other source of randomness, with predictably terrible results.

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

People seem to be assuming, implicitly or sometimes explicitly, that
every problem in the world either has a software solution or has no
solution at all.  Well, that's just not true.  A random distribution
over numbers *can* be produced ... just not by software.  John von
Neumann was right.  The sooner everybody comes to terms with this,
the better off we will all be.



More information about the cryptography mailing list