Date: Fri, 18 Jul 2014 23:10:53 +0100 From: RW <rwmaillists@googlemail.com> To: freebsd-security@freebsd.org Subject: Re: Speed and security of /dev/urandom Message-ID: <20140718231053.3251d0b7@gumby.homeunix.com> In-Reply-To: <53C97E47.4030100@pyro.eu.org> References: <53C85F42.1000704@pyro.eu.org> <4E23BEEA-693A-4FA3-BE94-9BB82B49503A@vpnc.org> <CAK-wPOhuh_XUpQ9OZXB1UZjz6wQF=8gO2thWiBu9i3tt%2BKt7mQ@mail.gmail.com> <C9E21765-D47F-4D98-8C7A-FCD9922FD072@vpnc.org> <CAK-wPOhUDhzB6mXJ4XSCN4O6VcyPG9dXqtQJkR3Eoj6Q_gZ=Xg@mail.gmail.com> <53C97E47.4030100@pyro.eu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 18 Jul 2014 21:06:31 +0100 Steven Chamberlain wrote: > *If* getpid involves a syscall on every arc4random_buf call, that is > going to already going to limit its performance? Would it really be > any slower to just return random bytes from the kernel, with the > KERN_ARND sysctl? I think KERN_ARND uses the kernel version of arc4random rather than Yarrow - unless something changed. > The overhead of currently having to initially and > periodically seed RC4, discard the early keystream, and apply that > cipher thereafter, would be gone. The risk of the problem described > above, or of weaknesses in RC4, or implementation issues with > arc4random's PRNG seeding are also gone. The RANDOM kernel module may not be present, particularly in a stripped-down embedded kernel. In that case yarrow isn't present in the kernel, and kernel arc4random isn't securely seeded. An application may then securely seed userland arc4random via arc4random_addrandom(). Supporting that requires at least the possibility to fall back to a userland PRNG.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140718231053.3251d0b7>