[PATCH v1 1/2] random-bits: Factor out entropy generating function

Noah Goldstein goldstein.w.n@gmail.com
Thu Mar 31 23:05:20 GMT 2022


On Thu, Mar 31, 2022 at 5:51 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> Hi Cristian,
>
> On Thu, Mar 31, 2022 at 5:57 PM Cristian Rodríguez
> <crrodriguez@opensuse.org> wrote:
> >
> > On Thu, Mar 31, 2022 at 12:32 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> > >
> > > Just so we're on the same page here, is this a discussion about
> > > optimizing https://code.woboq.org/userspace/glibc/include/random-bits.h.html
> > > ?
> > >
> > > You just need a super fast random uint32_t for some future pthread changes?
> > >
> > > If so, I can send a patch to return moderately secure integers here really fast.
> > >
> > > Jason
> >
> > That would be great if is better than the current solution.
>
> Alright, well, here's something: https://xn--4db.cc/YQOxDP6Z/c
>
> This is somewhat "secure", and maybe overkill.

AFAIK our goal is entropy more so than security. For example
if this is used to generate jiffies to stagger threads its not a security
issue in any sense, it's just not ideal for performance.

>
> I can adjust this to have additional security properties (for example,
> preventing that counter from running backwards). Or I can adjust it to
> be even faster and have fewer security properties. Or maybe bench this
> and you'll find that it's fine.
>
> I suspect the only thing we really care about here is not leaking the
> AT_RANDOM value somehow, and siphash usually does a good job at that.
>
> Thoughts?
>
> Jason


More information about the Libc-alpha mailing list