Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 11 Sep 2012 00:12:06 -0700
From:      Doug Barton <dougb@FreeBSD.org>
To:        obrien@freebsd.org
Cc:        Arthur Mesh <arthurmesh@gmail.com>, Ian Lepore <freebsd@damnhippie.dyndns.org>, freebsd-rc@freebsd.org, Xin Li <delphij@delphij.net>, freebsd-security@freebsd.org, RW <rwmaillists@googlemail.com>
Subject:   Re: svn commit: r239569 - head/etc/rc.d
Message-ID:  <504EE446.6060500@FreeBSD.org>
In-Reply-To: <20120911064636.GB72584@dragon.NUXI.org>
References:  <50451D6E.30401@FreeBSD.org> <20120903214638.GO1464@x96.org> <50453686.9090100@FreeBSD.org> <20120904220754.GA3643@server.rulingia.com> <20120906174247.GB13179@dragon.NUXI.org> <20120906230157.5307a21f@gumby.homeunix.com> <20120906224703.GD89120@x96.org> <20120907015157.GA29497@server.rulingia.com> <20120910135218.GA68128@dragon.NUXI.org> <504E343A.4020802@FreeBSD.org> <20120911064636.GB72584@dragon.NUXI.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 09/10/2012 23:46, David O'Brien wrote:
> On Mon, Sep 10, 2012 at 11:40:58AM -0700, Doug Barton wrote:
>> I am opposed to this patch, more details below.
>>
>> On 9/10/2012 6:52 AM, David O'Brien wrote:
>>> * Updates the comment about blocking -- it hasn't been true for 8 years.
>>
>> Just because .seeded=1 doesn't mean the device is ready to spit out high
>> quality random bits. I don't mind a change in terminology here, but we
>> should be clear that the device needs seeding early.
> 
> In what way did I suggest we don't need to seed the PRNG?
> I simply removed an outdated and incorrect statement.

Yes, the comment as it stood was out of date. I'm not sure that removing
it (rather than rephrasing it) was the right call.

> In fact writing into /dev/random CANNOT "seeded" yarrow.  All /dev/random
> input is untrusted and is assumed to have _0_ entropy:
> 
>    void
>    random_yarrow_write(void *buf, int count)
>    {
> 	...
> 	random_harvest_internal(get_cyclecount(), (char *)buf + i,
> 	    chunk, 0, 0, RANDOM_WRITE);

You're taking that out of context. The 0 there is just an estimate, but
it's added to the tailq anyway.

> I would need to setup a 2004-04-09 -CURRENT system to test, but I don't
> see how these commands could have unblocked the generator except that
> they contributed to the interrupts that occurred.

Yes, some actual testing on your part would really be awesome at this
point.

> So we have two issues -- (1) is how yarrow is operating per the design
> with its checks on "seeded",

I am specifically avoiding that issue as it is out of scope for the
rc.d-related discussion. There is room for a larger discussion on
whether or not we should make .seeded dynamic again.

But regardless of that decision, it's unquestionable that we need to
seed the device at boot time, which is what I am interested in.

> and (2) what is the difficulty of an
> attacker being able to figure out the internal state of the PRNG
> generator such that they can predict the output -- something which you
> mentioned in a recent reply.

... and something that I pointed out that with the current defaults is
close enough to impossible not to be a threat model we need to spend
much time on.

> We also have the issue that we are the only system in which /dev/random
> does not block if the PRNG has consumed all the seeded entropy:

I'm not sure that "the PRNG has consumed all the seeded entropy" is a
statement that can apply to our Yarrow implementation, but once again
that's a whole different discussion than what we're dealing with
regarding the rc.d bits.

>>> * Doaument the natural limitations of the harvesting subsystem due to
>>>   it having finite resources (space & time).
>>
>> It has yet to be proven that we're dropping entropy at all.
> 
> We are dropping input. 

Well I was assuming that the input has at least some entropic value, but
you are right, "input" is the more correct term here.

> Whether that input contains any entropy is a
> different issue.  That said, _I_have_seen_the_dumps_of_the_internal_buffers_
> from Arthur's experiments.  It happens -- easily.  I'll leave it up to
> him if he wants to rerun the experiments and post the results.

I have always said that I'm willing to listen to actual evidence that
there is a problem, and make changes accordingly. I already responded to
Arthur about his statements in this regard today. If it's true that
we're dropping input there are any number of changes that could be made
to fix that problem.

> Also, both jbh <201209050944.38042.jhb@freebsd.org> and RW
> <20120905021248.5a17ace9@gumby.homeunix.com> feel this likely does
> happen just from reading the code.  Please explain from either
> (1) a code reading, or (2) your own instrumented kernel that dropping
> of input to /dev/random does not occur.

Once again, you're the one asserting that there is a problem with a
system that has worked well for 12 years, so the burden of proof is on
you. That said, I'm interested in Arthur's evidence.

>> The use of dd to feed the entropy in with 2k chunks is specifically to
>> address this issue.
> 
> Maybe I'm missing something...  The code in 'initrandom' is
> "| dd of=/dev/random bs=8k".  Where are you getting 2k chunks from that?

You're right, I didn't have a chance to look over the code when I wrote
that response, and was going by my (obviously faulty) memory on that
trivial point. My understanding is that Arthur's tests were with the
current defaults. It would be interesting to see what happens if we
reduce that to 4k (to match the input buffer size), or perhaps even lower.

>>> * Apply Bruce Schneier's advice WRT not reusing seed material to
>>>   the 'better_than_nothing' seed material and only use it on first
>>>   post-installation boot.
>>
>> This is also entirely the wrong approach. We should choose commands that
>> have the highest degree of entropy possible between reboots, AND use the
>> /entropy file.
> 
> Why do you want to continue to use guessable input? 

We have been over this, and I'm tired of repeating myself.

> I guess I don't
> care that much if we write in into /dev/random as long as it is after
> we've written ${entropy_file}.  But I don't see much of the point.

I'm also tired of repeating why writing out a new /entropy file at boot
time makes the system weaker, not stronger.

> I'm really done arguing this with you.  I've argued my point with
> literature, code, and measurements.  Until you do the same I don't think
> you have anything new to add and I've addressed everything from your
> input I intend to.

Fair enough, I'm happy to leave the decision with core@. I at least
agree with you that nothing new has been said for a while now. :)

Doug

-- 

    I am only one, but I am one.  I cannot do everything, but I can do
    something.  And I will not let what I cannot do interfere with what
    I can do.
			-- Edward Everett Hale, (1822 - 1909)



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?504EE446.6060500>