[147130] in cryptography@c2.net mail archive
Re: [Cryptography] real random numbers
daemon@ATHENA.MIT.EDU (Kent Borg)
Sat Sep 14 18:57:33 2013
X-Original-To: cryptography@metzdowd.com
Date: Sat, 14 Sep 2013 17:38:24 -0400
From: Kent Borg <kentborg@borg.org>
To: cryptography@metzdowd.com
In-Reply-To: <5234B91F.1000500@av8n.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
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