Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 10 Sep 2012 23:46:36 -0700
From:      David O'Brien <obrien@FreeBSD.org>
To:        Doug Barton <dougb@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:  <20120911064636.GB72584@dragon.NUXI.org>
In-Reply-To: <504E343A.4020802@FreeBSD.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>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

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);

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.

So we have two issues -- (1) is how yarrow is operating per the design
with its checks on "seeded", 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.

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:

   crw-rw-rw-  1 root  wheel  0x1f Aug 22 16:39 /dev/random
   lrwxr-xr-x  1 root  wheel     6 Aug  1 15:33 /dev/urandom@ -> random

Thus I am concerned about the internal state of the generator.

compare
	:
	while true; do
        dd if=${INPUT} of=/dev/null bs=8k count=1 2> /dev/null
	echo -n "."
	done

with both INPUT=/dev/random and INPUT=/dev/urandom on both FreeBSD
and any other non-FreeBSD system.
I am not sure how we're POSIX compliant with this.


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

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.


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

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

-- 
-- David  (obrien@FreeBSD.org)



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