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 f
 ailures 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

The cryptography mailing list

Reply via email to