[Cryptography] real random numbers

[ianG]

On 15/09/13 00:38 AM, Kent Borg wrote:
> On 09/14/2013 03:29 PM, John Denker wrote:

> And once we have built such vaguely secure systems, why reject entropy
> sources within those systems, merely because they you think they look
> like "squish"?  If there is a random component, why toss it out?


He's not tossing it out, he's saying that it is no basis for measurement.

Think of the cryptography worldview -- suppliers of black boxes (MDs, 
encryptions, etc) to the software world are obsessed about the 
properties of the black box, and suppliers want them to be reliable and 
damn near perfect.  No come back, no liability.

Meanwhile, in the software world, we think very differently.  We want 
stuff that is "good enough" not perfect.  That's because we know that 
systems are so darn complex that the problems are going to occur 
elsewhere -- either other systems that don't have the cryptographic 
obsession, our own mistakes or user issues.

E.g., SHA1 is close to perfect for almost all software needs, but for 
the cryptographers, it isn't good enough any more!  "We must have SHA2, 
SHA3, etc."  The difference for most real software is pretty much like 
how many bit angels can dance on a pinhead.

As John is on the supplier side, he needs a measurement that is totally 
reliable and totally accurate.  Squish must therefore be dropped from 
that measurement.

...
> You dismiss "things like clock skew", but when I start to imagine ways
> to defeat interrupt timing as an entropy source, your Johnson noise
> source also fails: by the time the adversary has enough information
> about what is going on inside the GHz-plus box to infer precise clock
> phase, precise interrupt timing, and how fast the CPU responds...they
> have also tapped into the code that is counting your Johnson.


Once the adversary has done that, all bets are off.  The adversary can 
now probably count the keys bits in use, and is probably at the point 
where they can interfere at the bit level.

Typically, we don't build designs to that threat model, that way lies 
TPMs and other madness.  In risk terms, we accept that risk, the user 
loses, and we move on.


> There are a lot of installed machines that can get useful entropy from
> existing sources, and it seems you would have the man who is dying of
> thirst die, because the water isn't pure enough.


It is a problem.  Those on the supplier side of the divide cannot 
deliver the water unless it is pure enough.  Those on the builder side 
don't need pure water when everything else is so much sewage.  But oh 
well, life goes on.


> Certainly, if hardware manufacturers want to put dedicated entropy
> sources in machines, I approve, and I am even going to use rdrand as
> *part* of my random numbers, but in the mean time, give the poor servers
> a sip of entropy.  (And bravo to Linux distributions that overruled the
> purist Linux maintainer who thought no entropy was better than poorly
> audited entropy, we are a lot more secure because of them.)


Right.  The more the merrier.



iang