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.

The cryptography mailing list

Reply via email to