[Cryptography] /dev/random is not robust

[John Denker]

On 11/04/2013 10:39 AM, John Kelsey wrote:

>>  Given that we're assuming the device can't reliably generate a secure key pair,
>>  and assuming that it doesn't already have a secret specific to the device, what
>>  protocols would be suitable for doing that?             [1]

> Yep, this is an unfixable problem.

I wouldn't have said that.

Statement [1] is true enough as it stands ... but it's looking
through the wrong end of the telescope.  We should instead turn
it around.  Consider the contrapositive:

  Given that we don't want to be completely screwed, we MUST
  ensure that the device has enough randomness onboard, so 
  that it can generate secure session keys.

  This is an entirely /solvable/ chicken-and-egg problem.
  Proper provisioning is a big part of the solution.  As
  soon as you can establish a secure connection, you can
  download tons of exogenous randomness.

On 11/04/2013 09:46 PM, Watson Ladd wrote:

> I'm sorry: Did the Mind your P's and Q's paper escape everyone on this list?
> There are thousands of devices out there generating keys on first-power on
> with insufficient entropy, with observable deleterious effects.
> 
> This problem needs to be solved, 

Yes!

> and the only way to do it is to find
> or add sources of randomness to the hardware and have the kernel
> use them, 

That is not the "only" way to solve the main problem(s).  
There must be a hardware RNG somewhere in the mix, and I 
have devoted a lot of time and effort to this part of the 
problem.  However, the fact remains that a properly seeded 
cryptographically strong PRNG is good enough for many 
purposes, and indeed superior for many purposes, especially 
given that the demand for randomly-distributed bits tends 
to be very bursty.

> as well as a critical failure if they do not exist/are not sufficient.

Increasing the number of critical failures is not a good
way to win friends and influence people. 
 -- Converting an insidious critical failure to a manifest
  critical failure is a small step in the right direction;
  however ...
 -- The real goal should be to eliminate the failure mode
  entirely.  This appears to be entirely doable.

On 11/05/2013 05:45 AM, Albert Lunde wrote:

> There may be no one-size-fits-all answer. 

Those are wise words.
 -- There are a couple of different common cases that
  require slightly different answers.
 -- There are a couple of unusual cases that require
  some extra effort, but are still entirely doable.
 -- I'm sure there are cases that cannot be handled.  It
  will always be possible to design a device that cannot
  be secured, because fools are so ingenious.  However,
  this is not the typical case.  Not even close.

There are huge categories of devices out there that could
be made much more secure at essentially zero incremental
cost, and that should be the first place we focus our
efforts.

> Providing means to manage a random seed across reboots or provision
> it for a VM from a hypervisor seem like they could help important
> corner cases.

Exactly so.  Those are important cases.  Along the same lines, 
it should go without saying that proper provisioning of 
NON-virtual machines is also required.

Meanwhile, as another part of the overall solution, a good
hardware RNG is also required.  This does not, however need
to exist on every machine, and it does not need to meet every
demand for randomly-distributed bits.

Note the contrast:  As a rule of thumb:
  A) Seed-files and PRNGs tend to be good for meeting 
   short-term peak demand.
  B) There is still a long-term need for a HRNG.  A PRNG
   cannot exist without a HRNG backing it up.  On the
   other hand, the coupling between the two does not
   need to be particularly tight.