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
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
