From: Jason A. Donenfeld > Sent: 23 March 2022 02:51 > > On Tue, Mar 22, 2022 at 8:16 PM David Laight <David.Laight@xxxxxxxxxx> 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)
