Am Wed, May 11, 2022 at 04:32:57PM +0200 schrieb Jason A. Donenfeld: > random32.c has two RNGs in it: one that is meant to be used > deterministically, with some predefined seed, and one that does the same > exact thing as random.c, except does it poorly. The first one has some > use cases. The second one no longer does and can be replaced with calls > to random.c's proper random number generator. > > The relatively recent siphash-based bad random32.c code was added in > response to concerns that the prior random32.c was too deterministic. > Out of fears that random.c was (at the time) too slow, this code was > anonymously contributed by somebody who was likely reusing the alias of > long time anonymous contributor George Spelvin. Then out of that emerged > a kind of shadow entropy gathering system, with its own tentacles > throughout various net code, added willy nilly. > > Stop👏making👏crappy👏bespoke👏random👏number👏generators👏. > > Fortunately, recently advances in random.c mean that we can stop playing > with this sketchiness, and just use get_random_u32(), which is now fast > enough. In micro benchmarks using RDPMC, I'm seeing the same median > cycle count between the two functions, with the mean being _slightly_ > higher due to batches refilling (which we can optimize further need be). > However, when doing *real* benchmarks of the net functions that actually > use these random numbers, the mean cycles actually *decreased* slightly > (with the median still staying the same), likely because the additional > prandom code means icache misses and complexity, whereas random.c is > generally already being used by something else nearby. > > The biggest benefit of this is that there are many users of prandom who > probably should be using cryptographically secure random numbers. This > makes all of those accidental cases become secure by just flipping a > switch. Later on, we can do a tree-wide cleanup to remove the static > inline wrapper functions that this commit adds. > > Cc: Jakub Kicinski <kuba@xxxxxxxxxx> > Cc: Theodore Ts'o <tytso@xxxxxxx> > Signed-off-by: Jason A. Donenfeld <Jason@xxxxxxxxx> > --- > Jakub - If there are no objections to this plan, I intend on taking this > through the random.git tree, which is what this commit is based on, with > its recent siphash changes and such. -Jason Nice! However, wouldn't it be much better to clean up the indirection introduced here as well? prandom_u32() as wrapper for get_random_u32() and prandom_bytes() as wrapper for get_random_bytes() seems unnecessary... Thanks, Dominik
