[cryptography] urandom vs random

Nico Williams nico at cryptonector.com
Thu Aug 22 12:40:32 EDT 2013

On Wed, Aug 21, 2013 at 12:29 AM, Yazid Boukeroui <yboukerr at vt.edu> wrote:
> In terms of usability engineering, /dev/random is fairly cumbersome and in dire need of reform and expansion.
> A user, might want more control of /dev/random - which sources of entropy, when, and which applications. e.g. I want my Geiger counter to feed communications and radio noise to feed data. I want 3000 from 9am-5pm and 200 otherwise. I want all this'd in a GUI or config file.
> A developer, might want to tell /dev/random "don't give me keyboard and mouse crap, instead give me 80% rdrand and 20% audio source."

Applications have no business specifying such things.  Users/sysadmins
do have a need to be able to configure HW RNG sources, but not in a
weighed manner like that.

Say you have N>1 HW RNG sources of differing quality (and output
rate!).  Why bother taking different numbers of bits from each to form
an input to the SRNG pool?  Just take whatever each source has
available and feed it all in.  If your SRNG is any good this is good

What I'd like is for the HW RNG source configutation to be made very
clear to users: at boot time, at login time, when source availability
changes, and at critical secret or private key generation times.  That
last is difficult without changing implementations of all sorts of

My suggestion is /dev/urandomN where N is one of 128, 192, or 256, and
represents the minimum entropy estimate of HW RNG inputs to date to
/dev/urandomN's pool.  If the pool hasn't received that much entropy
at read(2) time, then block, else never block and just keep stretching
that entropy and accepting new entropy as necessary.


More information about the cryptography mailing list