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

[Bill Cox]

On Wed, Jan 20, 2016 at 10:47 AM, Kent Borg <kentborg at borg.org> wrote:

> 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.
>
>
I was unclear.  I meant to say that rngd, or some daemon like it, should
require health monitors and good entropy estimators.  I agree this is
out-of-scope for the kernel, but a good hardware RNGD utility daemon like
rngd should provide this, IMO.  Developers of TRNGs should be encouraged to
provide raw bits, and a decent model, and leave the rest to the rngd devs.

Getting this stuff right is hard.  Hiding the raw bits makes it even harder.

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.
>

Agreed.  Every source of entropy, even one with a back-door, is welcome in
the entropy pool.  The trick is maintaining a good guestimate of secure
entropy.  Physical models and health monitors can help with entropy
estimates, though back-doors are still possible.  Multiple sources can help
with security.  The problem I saw in my version of rngd (which may be old -
I did not check upstream) is that it did not have a way to require multiple
entropy sources to contribute significant entropy.


> 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.
>

I agree.  All (potential) sources of entropy are welcome.


> 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.


Hmm... How about when I use a single very well characterized TRNG, for
which I can prove that the entropy contributed on each update to
/dev/random is at least 400 bits with extremely high probability?

I guess it depends on what you mean by cracking.  If you mean hacking in
user space to defeat all sources of entropy feeding /dev/random, I agree.
It is simpler to hack one source than several.  However, if you mean an
attack that attempts to guess the output from /dev/urandom, I would prefer
to defend against this with one known-good source over multiple
questionable ones.


> 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.


Yep.  It is simple enough to just throw more somewhat imperfect bits of
entropy at the problem than polishing each one to be sure we understand it
100%, so long as we can be confident that the bits contain _some_ entropy.

Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160120/a6bfb397/attachment.html>