[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201903261624.x2QGOxOV006525@sdf.org>
Date: Tue, 26 Mar 2019 16:24:59 GMT
From: George Spelvin <lkml@....org>
To: lkml@....org, stephen@...workplumber.org
Cc: daniel@...earbox.net, hannes@...essinduktion.org,
netdev@...r.kernel.org
Subject: Re: Revising prandom_32 generator
> A little backstory. I started the prandom_32 stuff long ago when I wanted
> a better (longer period) PRNG for use in netem. Took the existing code from
> older version of GNU scientific library (pre GPLv3). If there is something
> faster with better properties go for it. But the whole point of prandom_32
> is that it doesn't have to be crypto quality.
Than you for the encouragement! The lfsr113 generator is really
a perfectly respectable generator. There's nothing about it that
"needs fixing"; it's just possible to do slighty better.
When I can get better statistics, longer period (for the same state
size), faster *and* smaller code size, it seems worth looking into.
And yes, I understand "pseudorandom" very well. From a documentation
patch for drivers/char/random.c I also posted recenty:
+ *
+ * prandom_u32()
+ * -------------
+ *
+ * For even weaker applications, see the pseudorandom generator
+ * prandom_u32(), prandom_max(), and prandom_bytes(). If the random
+ * numbers aren't security-critical at all, these are *far* cheaper.
+ * Useful for self-tests, random error simulation, randomized backoffs,
+ * and any other application where you trust that nobody is trying to
+ * maliciously mess with you by guessing the "random" numbers.
Powered by blists - more mailing lists