[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