[Cryptography] real random numbers

Kent Borg kentborg at borg.org
Sat Sep 14 17:38:24 EDT 2013

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


More information about the cryptography mailing list