cvs commit: src/sys/libkern arc4random.c

[Sam Leffler]

> Mike Silbersack writes:
>> > How did you validate the this change?  I strongly suggest that mods
>> > like this need review before commit.  Subtle problems can go unnoticed
>> > for a long time.
>> >
>> > 	Sam
>>
>> I'm fairly confident that I did not add any bugs in this commit.
>> However, I also have no way of knowing if arc4random was working
>> correctly before the commit either... How hard would it be to hook up
>> the randomness testing code you committed a few months back?  If the
>> testing code is in userland, perhaps we could export a /dev/arandom like
>> openbsd does for simpler testing.
>
> I have not looked at the locking, but I have looked at this from a
> randomness perspective.
>
> With that in mind, I think Mike did the right thing in making sure
> that the first chunk of arcfour 'randomness' is ditched after a
> rekey. It may be fixing a non-problem, but if there is an undisclosed
> problem in determining the arcfour sequence, this helps thwart that.
>
> For the paranoids, this is cheap (almost free), and is solid from a
> arcfour-neurotic perspective.

I am not arguing for Mike to remove his change.  I am noting that making 
changes to critical system components w/o review and/or testing is 
dangerous.  Going forward we should have some tools for validating changes 
like this.  If the output of arc4random is available through a sysctl or 
similar then it could be a tool that sits in /usr/src/tools/tools. 
Otherwise it would be good to create a test module or similar to shunt 
arc4random data through rndtest.

	Sam