[Cryptography] TRNG related review: rngd and /dev/random

Kent Borg kentborg at borg.org
Wed Jan 20 13:47:40 EST 2016


On 01/20/2016 11:30 AM, Thierry Moreau wrote:
> On 20/01/16 01:37 AM, Bill Cox wrote:
>>
>> These problems are fixable.  Health monitors with good entropy
>> estimators should be required for each entropy source.
>
> Those who maintain the Linux kernel are not in a position to *require* 
> either health monitors or good entropy estimators. The inclusion of an 
> entropy source in a system is a decision that may be made even after 
> the Linux distribution packaging.

The kernel cannot make a perfect RNG, there are system issues that are 
bigger than just the kernel's responsibility. The kernel needs to do the 
best job it can but...


A few years ago the Linux urandom maintainer seemed to be turning off 
every entropy source he could because none of them were well enough 
characterized for him. Crazy! (Then Ted took over again, thank God.)

It is important to have some entropy making its way in, but there is a 
logical extreme here to avoid: don't discard all your entropy just 
because none of it is perfect.

Heck: give me a backdoored RNG (the new NSA one!), and give me another 
backdoored RNG (what is Intel's old RNG opcode?), and I'll mix them 
together--maybe use the CPU temperature to control how the two 
backdoored RNGs slide across each other in time. And let me mix in the 
timestamp counter at every interrupt and let me mix in the most recent 
value of the Dow Jones Industrial Average and a few books off Project 
Gutenberg. And keep the attackers out of my box and a few meters 
away---and I will have a great RNG.

It is important to know the RNG isn't spitting disguised zeros, and that 
is hard. But mixing in complete crap--with something good--should not be 
a problem. Don't excise everything that you can't prove is perfect.

Someone on this list liked to dismiss stuff as "squish". I say go ahead 
and put in lots of squish. I know I would rather crack a simple RNG with 
only a few inputs that can be well characterized than a chaotic RNG with 
tons of inputs I would have to track. Mix in an interrupt from the fan's 
RPM sensor and let a door slam a couple times on a windy day--and as an 
attacker I am up a creek because I don't know what dozen-ish bits got 
tossed in when and I can't get enough clear RNG output before the 
internal state further drifts from my tracking.

"Oh, hell, turn this one over to the exploit boys who can just e-mail a 
damn infected spreadsheet and quit trying to do it the hard way."


Just making sure your RNG isn't flat out broken is really, really 
important and not so easy. Making sure it is perfect is a distraction.


-kb



More information about the cryptography mailing list