Re: svn commit: r239569 - head/etc/rc.d

On Sat, Sep 15, 2012 at 12:07 PM, Mark Murray <markm@freebsd.org> wrote:
> Ben Laurie writes:
>> > Are you aware of Yarrow's approach to poor entropy while harvesting?
>>
>> Yes. I am _only_ talking about fixes for the current practice of
>> discarding input - once Yarrow gets to eat input, then its all fine,
>> but as you say, you don't want to run Yarrow over all input because it
>> is too expensive.
>
> Correct.
>
>> So, you plan to xor input with itself, instead of discarding if it
>> fills the buffer. My point is that unfortunate choice of input can
>> result in the input cancelling itself out.
>
> That means that diverse input should be used, and that is the intent
> anyway.
>
> Hashing _certain_ input in /etc/rc.d/initrandom is also attractive.
>
>> This is not part of Yarrow - Yarrow specifies that you hash all
>> inputs, not xor or discard them :-)
>
> Beyond nitpicking. How the data is harvested is not discussed in much
> detail.

It says that the pools contain the running hash of all inputs fed to
them since they were last used to reseed. It is _not_ "beyond
nitpicking" to observe that neither xor nor discard are hashing.
_Particularly_ when you suggest that my criticism arises from
ignorance of Yarrow!

The whole point of Yarrow is to extract all available entropy by the
use of hash functions. If you do something else, then you are not
doing Yarrow.

That said, as I understand your proposed code, what you are doing is
xoring each complete input into a HARVESTSIZE buffer, then submitting
that as an event - so the problem only arises if a single input
repeats internally. It might be a good idea, assuming we go down this
path, to add a note to the man page pointing out that:

cat a > /dev/random
cat b > /dev/random

is wiser than:

cat a b > /dev/random

I remain surprised that the cost of hashing the input into a
HARVESTSIZE buffer is noticable after all the other costs of the
system call, though.

>  Here, I'm chunking the file input up, instead of taking it
> piecemeal. In each case, the harvested data is handed over to Yarrow as
> a series of data "events". Keystrokes, mouse events, interrupts or uio()
> calls are all such events, and many more are possible as input.

I notice that events are also discarded when the queue reaches a
certain length. This seems like a problem, too.
_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"