On Wed, Aug 21, 2013 at 12:29 AM, Yazid Boukeroui <ybouk...@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 enough. 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 things. 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. Nico -- _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
