svn commit: r253786 - in head/sys: dev/random modules/padlock_rng modules/rdrand_rng modules/yarrow_rng

[Andrey Chernov]

On 31.07.2013 4:07, David O'Brien wrote:
> I believe you're talking about this code in
> sys/libkern/arc4random.c:arc4rand()
> 
> 	if (atomic_cmpset_int(&arc4rand_iniseed_state, ARC4_ENTR_HAVE,
> 	    ARC4_ENTR_SEED) || reseed ||
> 	   (arc4_numruns > ARC4_RESEED_BYTES) ||
> 	   (tv.tv_sec > arc4_t_reseed))
> 		arc4_randomstir();
> 
> Without setting 'arc4rand_iniseed_state' from ARC4_ENTR_NONE ->
> ARC4_ENTR_HAVE, we would still call arc4_randomstir() periodically due
> to (tv.tv_sec > arc4_t_reseed) and (arc4_numruns > ARC4_RESEED_BYTES).

The whole problem is that arc4 is poorly initialized right after boot,
but immediately used in many places like tcp. It reseeds again only
after 5 minutes after boot making vulnerability window at this interval.

> But, this situation isn't the big issue.  We have an existing bug where
> if one is using a hardware RNG, read_random() never gets changed from
> simply being read_random_phony() due to random_modevent() not calling
> random_yarrow_init_harvester() thru '(*random_systat->init)()'.  Thus
> arc4random() has been weak for thus using the Intel RDRAND or Via
> Padlock.

I don't fix hardware RNG parts due to missing hardware for tests. They
should have the same line as randomdev_soft.c somewhere.

-- 
http://ache.vniz.net/
bitcoin:1G6ugdNY6e5jx1GVnAU2ntj2NEfmjKG85r