Date: Wed, 9 Dec 2020 19:16:58 +0000 From: RW <rwmaillists@googlemail.com> To: freebsd-hackers@freebsd.org Subject: Re: arc4random initialization Message-ID: <20201209191658.42063a95@gumby.homeunix.com> In-Reply-To: <CAG6CVpVUPzaGK-CdqdvGEmytmkAH%2BQTrX0BRho-HPUts60HZpQ@mail.gmail.com> References: <20201206153625.13e349a8@bigus.dream-tech.com> <EB47F35A-EAD8-4B97-B676-FD8C5AD57398@FreeBSD.org> <CAG6CVpVUPzaGK-CdqdvGEmytmkAH%2BQTrX0BRho-HPUts60HZpQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20201209191658.42063a95>