[Cryptography] Finding Entropy Isn't That Hard

2013-09-13 Thread Kent Borg

On 09/11/2013 07:18 PM, Perry E. Metzger wrote:
the world's routers, servers, etc. do not have good sources, 
especially at first boot time, and for customer NAT boxes and the like 
the price points are vicious. 


I agree that things like consumer NAT boxes have a tricky problem, and 
anything that needs high bandwidth random data, but otherwise routers 
and servers are not as bad off as people say.  At least in the case of 
modern servers that are running enough of an OS to include a good 
entropy-pool RGN (like Linux's urandom*).


These boxes have GHz-plus clocks, so fast that the box doesn't have 
that clock, it only exists on-chip.  It is multiplied up from a lower 
frequency external crystal oscillator by an analog PLL which is also 
on-chip.  This fastest clock is commonly used to drive an on-chip 
counter.  These chips also have interrupts from the outside world.  
There is real entropy in the interaction between the two.


What is that value of that counter when the interrupt is serviced? I 
assert there is entropy in the LSB of that value.  A GHz-plus clock is 
running just too fast for someone meters (or kilometers) away to know 
its exact value.  And every time the observer might get the LSB wrong, a 
bit of entropy got by: Use that data to stir an entropy pool.


How do we know it is hard to know the value of a GHz-plus counter? 
Because of the engineering problems suffered by people trying to build 
fast systems.  Clock distribution is difficult--there is a reason that 
high speed clock doesn't exist off-chip, the skew becomes great.  Even 
on-chip clock distribution is tricky and requires careful layout rules 
when designing the chip.  And even on this fast chip, the uses of the 
fastest clock are limited and any functions that will work on a slower 
clock will get a slower clock. Clock distribution is hard.  Hard within 
a large IC, hard on a circuit board, hard between circuit boards, hard 
between boxes, hard between equipment racks, hard between 
buildings...how far away is this nefarious observer, the one who you 
worry might be able to infer the LSB?  I think more than a few cm is too 
far away and if you don't have security at that radius, you don't have 
security.



[* Until Linux kernel 3.6 the person maintaining urandom was busily 
turning off interrupts as a source of entropy, I think because he didn't 
know how much entropy he was getting so better not to get it at all 
(huh?).  In 3.6 this was changed to use all interrupts as entropy 
sources, which is good.  This means earlier kernels aren't so 
good--though I notice that Ubuntu's kernel has the 3.6 improvement in 
their version of 3.2, so individual distributions will vary.]



-kb
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: [Cryptography] Finding Entropy Isn't That Hard

2013-09-13 Thread Kent Borg

On 09/12/2013 10:41 AM, Kent Borg wrote:
routers and servers are not as bad off as people say. 


Not that more sources is bad.  A new trustworthy HW entropy source would 
be good.  Even a suspect rdrand is worth XORing in (as Linux does on the 
machine I am using right now).


But if you thirst for more entropy keep looking in your current 
hardware, server boxes are particularly good hunting grounds for a few 
more dribs of entropy:


 - current RPM of all the fans (the proverbial entropy-starved server 
can have a lot of fans)

 - temperatures
 - voltages
 - disk (SMART) statistics (temperatures and error counts, multiplied 
by the number of disks)


These are all things that could wear out or go wrong, which means they 
need monitoring because...you can't otherwise know what they are.  Cool, 
that's a decent definition of entropy.  Sample them regularly and hash 
them into your entropy pool.  Not a lot of bandwidth there, but if your 
RNG does a good job of hiding its internal state, and you are mixing in 
a dozen more bits here and a dozen more bits there...pretty soon you 
have made the attacker's job a lot harder.


Maybe not as sexy as a lavalamp or radioactive gizmos, but more 
practical and available now.


-kb



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


Re: [Cryptography] Finding Entropy Isn't That Hard

2013-09-13 Thread Marcus Leech


[* Until Linux kernel 3.6 the person maintaining urandom was busily turning off interrupts as a source of entropy, I think because he didn't know how much entropy he was getting so better not to get it at all (huh?). In 3.6 this was changed to use all interrupts as entropy sources, which is good. This means earlier kernels aren't so good--though I notice that Ubuntu's kernel has the 3.6 improvement in their version of 3.2, so individual distributions will vary.]-kb

I'll also observe that on new mobile platforms, there are typically a flotilla of physical-world sensors. The low-level drivers for
 these should be contributing entropy to the pool in the kernel. At the apps layer, typically, the "raw" sensor values have been
 filtered by application-specific algorithms, so that they're less useful as entropy sources at that level.

For example, low-G accelerometers are quite noisy -- these are typically used as multi-axis rotation sensors (they use the gravity-field orientation to sense rotation).

Any physical-world sensor driver, where the sensor inherently has a bit of noise, I think has a "moral obligation" to contribute bits to the kernel entopy pool.





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

Re: [Cryptography] Finding Entropy Isn't That Hard

2013-09-13 Thread Kent Borg

On 09/13/2013 11:59 AM, Marcus Leech wrote:
Any physical-world sensor driver, where the sensor inherently has a 
bit of noise, I think has a moral obligation to contribute bits to 
the kernel entopy pool.


Within limits.  Mixing the entropy pool on Linux takes work and battery 
power.


Looking at some random Android kernel source code (git commit c73c9662) 
it looks like add_interrupt_randomness() is happening for every 
interrupt (your Android device's kernel may vary), so there is probably 
plenty of entropy.  And add_interrupt_randomness() throttles to only 
feed the randomness once a second, not wasting our time or battery.


Don't carry moral obligation beyond what is reasonable!

-kb

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