arc4random initialization

RW rwmaillists at
Mon Dec 7 22:59:16 UTC 2020

On Mon, 7 Dec 2020 08:37:42 +0000
Mark Murray wrote:

> Hi
> > On 6 Dec 2020, at 23:36, Dave Hayes <dave at> wrote:
> > 
> > So security-wise, just how bad is it to be improperly seeded? If I
> > cannot get a valid entropy stash at boot time, can I delay the need
> > for it until I can get a writable filesystem up and running?

The warning doesn't mean it was unseeded, just that it didn't 
seed from the boot entropy file.

I think it's unlikely that this is a significant problem if your cpu
has  RDRAND or similar, but it depends on the timing of calls.

 sysctl -o -B 65536 kern.arandom > /dev/null

should force a reseed if you want one. 

> This means that the random(4) device and relevant infrastructure like
> arc4random starts up in an insecure state and is not to be trusted
> for e.g. generating SSH keys.
> After you have used the machine for a while (exactly how long
> "depends"), it will reseed itself and become secure.
> Essentially, expect every boot off a DVD on the same hardware to reuse
> cryptographic keys 

That's easy to test.

> and therefore be insecure.

Kernel arc4random() also reads entropy from Fortuna via read_random().

If there's a hardware generator Fortuna will get enough entropy to reach
the  default minpoolsize within 0.7s of initialization. If arc4random is
called before that it will get reseeded on the first call to
read_random() that occurs after Fortuna is able to seed. 

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.

IMO it would be better to eliminate that 0.7s period by getting enough 
entropy from the hardware generator instantaneously when Fortuna
initializes. Whatever the paranoia over these generators they're better
than no seeding at all.

More information about the freebsd-hackers mailing list