Date: Mon, 7 Dec 2020 22:59:09 +0000 From: RW <rwmaillists@googlemail.com> To: freebsd-hackers@freebsd.org Subject: Re: arc4random initialization Message-ID: <20201207225909.650818c2@gumby.homeunix.com> In-Reply-To: <EB47F35A-EAD8-4B97-B676-FD8C5AD57398@FreeBSD.org> References: <20201206153625.13e349a8@bigus.dream-tech.com> <EB47F35A-EAD8-4B97-B676-FD8C5AD57398@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 7 Dec 2020 08:37:42 +0000 Mark Murray wrote: > Hi > > > On 6 Dec 2020, at 23:36, Dave Hayes <dave@jetcafe.org> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20201207225909.650818c2>