RE: [PATCH] random: allow writes to /dev/urandom to influence fast init

[David Laight <David.Laight@ACULAB.COM>]

From: Jason A. Donenfeld
> Sent: 23 March 2022 02:51
> 
> On Tue, Mar 22, 2022 at 8:16 PM David Laight <David.Laight@aculab.com> wrote:
> > Never mind scripts that try to immediately save a new seedfile [1].
> >
> > What about code run by later startup scripts that wants random numbers.
> > They really do want the seedfile data to be used.
> > If it isn't used then they are likely to get very weak random numbers.
> >
> > You can't really expect startup scripts to be issuing ioctl requests.
> 
> To be clear, this "expect[ation]" of yours is very much a new
> expectation. Crediting bits has required an ioctl since forever. Those
> shell scripts have been broken forever. The proposal here is to add new
> behavior to support those old broken shell scripts.
...

I personally won't have expected the behaviour for long!
I was only trying to get a buildroot system to initialise the
random number generator last year.
But I'm sure I read some of the documentation as well as looking
at the scripts and the kernel sources.

The buildroot scripts actually need fixing so they actually
add entropy on older kernel.

I do remember looking at one of the kernel entropy stores
(probably the Linux one) a few years back and thinking
that it was over-complex and probably didn't actually work
that well in reality.
IIRC it saved 'entropy bytes' and the number of bits of entropy
they represented - and then read out enough bytes to get
the required entropy to reseed the PRNG.
Now if your PRNG has N bits of state. In principle at least
after you've output N bits someone can solve the simultaneous
equations and determine the PRNG state.
But as soon as you use a cryptographic hash function that
is not really possible in any reasonable timeframe.
(Is even MD5 that broken?)

But the 'entropy store' can just stir in new bytes and
count the number of entropy bits.
Then it doesn't really care how random the bytes are.
(Apart from an estimation of how 'full' it is.)
Copy bits to the PRNG and you reduce the number of
bits in the entropy store - but continue just stirring
in new data.

I've often wondered whether the RC5 algorithm would
make a good entropy store.
Just cycle the algorithm with each entropy byte as
is done when setting each key byte.
Clearly you don't want to use the RC5 output as random data.
But it ought to be plenty good enough to keep entropy.
The only real problem is that RC5 is pretty horrid on
the data cache, and probably a bit big for per-cpu data.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)