RFC: Random numbers


Luiz Augusto von Dentz
 

Hi Marcus,

Lets move the discussion of
https://gerrit.zephyrproject.org/r/#/c/12341 here since it should be
quite important to get it right if we intend Zephyr to be somewhat
secure OS.

Hi,
> >
> > This PRNG implementation has more general utility in zephyr than
> as
> > a pseudo device driver, but I think adding it in this way as a
> > driver is taking us in the wrong direction.
> >
> > Even on systems which have access to HW entropy generators it can
> > be very expensive to harvest that entropy, which means entropy is
> > valuable. There are many places around zephyr where we need some
> > random number, but that number does need to be a high quality
> > random number. For example numerous parts of the network stack
> > need random numbers for transaction ids and timer offsets etc.
> On
> > such systems it would be useful to to distinguish between users
> > that require pure entropy and those that don't, thus reducing
> > pressure to collect quality entropy.
> >
> > I think this PRNG should be recast as subsystem/library rather
> than
> > as a driver for none existant hardware. The reseed interface
> > should be retained, its primary interface should be a new
> interface
> > to sit along side the existing sys_rand32_get(), perhaps
> > sys_prng_get(). We would then move users that don;t require high
> > quality entropy to the sys_prng_get() interface (Im thinking
> > maninly of all the network stack calls). This leaves us with two
> > interfaces, one to get (possibly expensive) high quality entropy,
> > and a second to give PRNG for all uses where that is 'good
> enough'
> >
>
> Maybe sys_urand32_get in addition to sys_rand32_get so we mimic
> /dev/urandom and /dev/random. sys_urand32_get might be PRNG based
> and should be considerably faster considering sys_rand32_get can
> block if it doesn't have enough entropy.
>
> > On systems with copious, low cost HW entropy we could simply wire
> > sys_prng_get() to the hw entropy source and bypass the prng
> > completely.
>
> Btw, isn't depending on one source of entropy alone bad/broken? I
> understand it is currently like this because the did not exist any
> way to collect entropy from other sources, but now we are talking
> about introducing one so we might as well switch from the driver
> given the random number to the driver working as a source of
> entropy which is then collected by random subsystem.
> >
> > On systems with limited/expensive HW entropy we use high quality
> > entropy to seed the prng.
> >
> > On systems with no dedicated source of HW entropy, rather than
> > building a driver like this we should perhaps instead look at
> > adding an entropy pool (as a subsystem or library, not a driver),
> > that has a mechanism to add entropy and can dole out entropy on
> > demand and then adjust various general hw drivers to feed what
> > meagre entropy then have to the pool. As with the previous
> > scenario, the PRNG would be seeded from the entropy pool.
> >
> > What do others think?
>
> I guess I agree, although currently the driver, there can be only
> one Im afraid, work as entropy pool instead of a source of entropy.
>
> Btw, regarding the implementation sys_urand32_get, if you agree
> with that, that might use sys_rand32_get to seed.
--
Luiz Augusto von Dentz

Join devel@lists.zephyrproject.org to automatically receive all group messages.