arc4random initialization

[RW]

On Mon, 7 Dec 2020 18:52:03 -0800
Conrad Meyer wrote:


> > The risk would be that kernel arc4random is initialized early and
> > insecurely and there's no appropriate read_random() call to reseed
> > it before something critical uses it.  
> 
> arc4random(9) is integrated with random(4), so that arc4random is
> immediately reseeded when the random device is seeded.  

But that that can only happen when something reads from random(4).
Fortuna doesn't spontaneously seed itself. 

However, I'd forgotten that modern userland arc4random seeds through
getrandom(2) which substantially mitigates the problem by creating more
reads from random(4) and reducing the importance of kernel arc4random.

It is theoretically possible for kernel arc4random to be used unseeded
for up to 5 minutes. It would probably need to be an atypical setup
though, maybe embedded.  But it sounds like better use of hardware
generators in current would mostly solve this. 

> However, the concern still applies to userspace arc4random(3), which
> is not integrated with core random(4) reseeds.

It looks to be integrated to the extent that it initializes though a
blocking call to getrandom, which is by far the most important thing.
Reseeding afterwards is mostly shutting the stable door after the
horse has bolted.