Date: Sat, 19 Jul 2014 22:41:12 +0100 From: Steven Chamberlain <steven@pyro.eu.org> To: Benjamin Kaduk <kaduk@MIT.EDU>, Mateusz Guzik <mjguzik@gmail.com> Cc: freebsd-security@freebsd.org Subject: Re: Speed and security of /dev/urandom Message-ID: <53CAE5F8.9010508@pyro.eu.org> In-Reply-To: <alpine.GSO.1.10.1407191707010.21571@multics.mit.edu> References: <53C85F42.1000704@pyro.eu.org> <20140719190348.GM45513@funkthat.com> <20140719192605.GV93733@kib.kiev.ua> <53CAD950.1010609@pyro.eu.org> <20140719205350.GX93733@kib.kiev.ua> <20140719210534.GA4630@dft-labs.eu> <alpine.GSO.1.10.1407191707010.21571@multics.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Sat, 19 Jul 2014, Mateusz Guzik wrote: >> I believe the idea here is to have reliable source for reseeding after >> fork. That is one issue, for which getrandom(2) may be an improvement, but I mentioned other problems. On 19/07/14 22:07, Benjamin Kaduk wrote: > I don't think that's quite right; there are issues in reliably detecting > that fork has occurred and a reseed performed. > Always getting random bits from the kernel avoids the need to detect fork. Precisely. A syscall may be fast enough (uniquely on FreeBSD) to provide arc4random_buf output, and perhaps be already as fast as doing getpid on each call and running a stream cipher in userland. RW mentioned kernels without RANDOM, being an awkward situation for which it seems necessary to fall back to the PRNG in userland. Regards, -- Steven Chamberlain steven@pyro.eu.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53CAE5F8.9010508>