cvs commit: src/sys/libkern arc4random.c

[Sam Leffler]

> On Fri, 15 Aug 2003, Sam Leffler wrote:
>
>> >   Lock down arc4random so it can be safely called w/o Giant.
>> >
>> >   Minor code reorganization was required, but the only functional
>> >   change was that the first 1024 bytes of output are thrown out
>> >   after each reseed, rather than just the initial seed.
>>
>> 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.

I suggest that being fairly confident about your changes is very different 
from testing them.

> However,I also have no way of knowing if arc4random was working correctly 
before
> the commit either...

If you didn't know how to verify things worked before or after why did you 
make these changes?  Was there a specific problem you were trying to 
address?

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

You could use the rndtest code directly in the kernel to gate the output of 
arc4random or you could extract the code and write a user-level test 
application.  I don't know if Mark Murray has something already along these 
lines (presumably he had something from his work on /dev/random).

Note that the data generated by arc4random needs to be exported to user 
apps for seeding crypto operations when operating in a chroot'd environment 
where /dev/random is not available.  This is something openbsd identified 
and that we've not brought over yet (I've known about it for a while but 
the work's been pending).  As such one should be very careful about futzing 
with the goodness of the data arc4random generates.

	Sam