On 09/14/2013 03:29 PM, John Denker wrote:
Things like clock skew are usually nothing but squish ... not reliably predictable, but also not reliably unpredictable. I'm not interested in squish, and I'm not interested in speculation about things that "might" be random.

I see "theoretical" the enemy of the "good" here.

The term "squish" is entertaining, but be careful that once you paint away with your broad brush that you don't dismiss engineering realities that matter.

I can see there is an appeal to entropy sources that you can work back to some quantum origin, but even they will fail horribly if you don't build a larger system that is secure, and secure at some non-trivial radius. (How much Tempest-hardening are you going to do?)

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? You seem to respect using hashing to condition and stretch entropy--though why any existing hash shouldn't also fall to your "squish" generalization, I don't know. It seems that you would reject using a coin toss as a source of entropy because coins are not perfectly fair and there are biases in their results. So? You respect hashing, why not clean the output with a good hash?

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.

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.

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.)


-kb

_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Reply via email to