Speed and security of /dev/urandom

[Benjamin Kaduk]

On Sat, 19 Jul 2014, Konstantin Belousov wrote:

> On Sat, Jul 19, 2014 at 09:47:12PM +0100, Steven Chamberlain wrote:
>> On 19/07/14 20:26, Konstantin Belousov wrote:
>>> I think that using sysctl for non-management functionality is wrong.
>>> If this feature is for the libraries and applications, and not for
>>> system management and introspection utilities, it should be normal
>>> syscall.
>>
>> If this is only to seed the arc4random in userland (with ~256 bytes or
>> so), it would be just like OpenBSD getentropy(2)?
>>
>> Just yesterday, something very similar is proposed for Linux, called
>> getrandom(2):
>> http://lists.openwall.net/linux-kernel/2014/07/18/329
>
> We, in fact, do not use sysctl for seeding SSP canary.  Kernel puts
> random bytes on stack, and libc fetches them.  But it is 64 bytes for
> 64-bit platforms, 32 bytes for 32-bit.
>
> Yes, the interface of the getrandom(2) from the link above looks
> reasonable.  The big question is, indeed, about its supposed use

I thought so, too, when I read it.

> models.  For one-time seeding of RNG with fixed amount of bytes,
> the ELF aux vector mechanism is much less intrusive and faster.

I think there is a lot of value in providing a syscall interface which can 
be the default way for applications to retrieve random bits.  This would 
avoid any issues with needing to track fork() and such, eliminating many 
sources of worry.  Performance-sensitive applications which do not want to 
suffer such syscall overhead may implement other PRNGs, and may be assumed 
to be somewhat aware of what they are doing.

-Ben