[Cryptography] real random numbers

[Jerry Leichter]

On Sep 14, 2013, at 5:38 PM, Kent Borg 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.

> 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.
You've completely missed what Denker was getting at with "squish".  "Squish" never applies to a fully characterized, deterministic component like a hash.  "Squish" is an "unknown unknown":  Data that you don't understand, so you think it might be random, but you really can't be sure.  Consider the example he responded to, that comparing the clocks on the CPU and on the sound card "should be usable" as a source of randomness.  If you dig in to what "should be usable" means here, it comes down to:  Both clocks show some degree of random variation, and the random variation is uncorrelated.  That might be true - or it might not:  Perhaps there's some path you haven't thought of through the power supply that tends to synchronize the two.  Lack of imagination on the analyst's part does not equate to lack of correlation (or other failure modes) on the system's part!  (In fact, the world is full of unexpected couplings between nominally independent events.  I've debugged and fought failures in systems built on the unsupported assumption that "things will smooth out on average".  They are always unexpected, and can be difficult to find after the fact.  And ... people don't seem to learn the lesson:  The next system makes the same bad assumptions.)

As Denker said:  Adding "squish" as a source of confusion in a well implemented mixer is at worst harmless - if you want to do it, go ahead.  But adding it as a source of an entropy estimate is wrong.  Either you have some way of estimating the entropy based on real physical modeling, or you're just making things up - and "just making things up" is not the way to build a secure system.
                                                       -- Jerry