This is also a problem with many virtual appliances. There is no easy answer to this kernel bootup entropy problem and it is lamentable that solutions are delegated to user space, and even to scripts, and to non-experts who will do a bad job of it but not know it.
You may as well feed what random data you have into rngd which will supply it to the kernel. You may as well feed /dev/urandom back, as has been pointed out, it is well-hashed (though then stretched) original entropy. It's a very poor solution but if there was a good solution it would be built into the kernel. (I remember the days when random state was saved on shutdown to be re-used on bootup). If you have control over the hardware spec, get a good random device on-board, RPMB or a TPM or something that can produce real random data on demand and provides /dev/hwrng against which you can run rngd to keep entropy full. My particular advice is to not simply dump some limited amount of poor "entropy" into the pool, because in corner cases (especially if retry is needed) it may not always be enough for whatever early processes need it. Instead, use rngd to keep the pool full enough until you get past this stage and then kill rngd. Having poor entropy is bad enough, but stalling boot because you don't have enough poor entropy because you guessed wrong... Some processes unexpectedly consume entropy, e.g. openssl has been seen to consume entropy even when decrypting. If you decrypt enough things you can stall on entropy starvation. Sam On Tue, 19 Sept 2023 at 07:12, Michael Conrad <[email protected]> wrote: > On 9/19/23 01:36, Roberto A. Foglietta wrote: > > On Tue, 19 Sept 2023 at 03:25, Michael Conrad <[email protected]> > wrote: > >> On 9/18/23 06:14, Guillermo Rodriguez Garcia wrote: >> >> everything is compressed with gzip -7. This is the worst scenario. >>> However, even in the worst scenario due to gzip one single bit of >>> difference in the input generates a completely different compressed >>> output: >>> >> >> Compression (or any other deterministic manipulation of data) does not >> add any entropy (or "unpredictability") since the processing is 100% >> reproducible. >> In terms of entropy the output of the function is as good (or as bad) as >> the amount of entropy in the initial seed. >> >> Hi Michel, > >> Even aside from that, using gzip as some sort of hash function is not >> going to be anywhere near as good as using an actual hash function, like >> sha256, sha1 or even md5. >> > > PREMISE > > Hashing functions and compression algorithms are two completely different > kinds of mathematical tools. The most obvious difference is that > > That's a very large response so I'm not sure which part to quote, but I > think you're still missing the point. Assuming your initialization of > randomness is meant to stop people from guessing the RSA/SSL keys you > generate on a small low-power device during startup scripts, the attacker > will probably have a copy of your device and be able to replay any of the > steps you take during your startup script. It will not matter whether you > took a few random bits and a large static text and ran it through pigz > before feeding it to /dev/urandom, because the attacker will start with > guesses of the same few bits and also run them and that same static text > through pigz to potentially get the same output. If they mirror your > initialization of /dev/urandom, then they can try to guess your RSA keys. > The only defense is having more actual bits of entropy, or preserving them > from a previous boot in a manner that the attacker can't read. > > My comment about hashing functions was implying that they would be used > repeatedly, not that the entire input would be condensed into one single > hash. Yes there is a reduction of entropy if you feed a hash function more > than 20 bytes of data and only get 20 out of it. My point was that no > hashing or compression is needed, because the kernel RNG is itself a sort > of hash function and should handle that. Just feed it the raw input bytes. > > -Mike > _______________________________________________ > busybox mailing list > [email protected] > http://lists.busybox.net/mailman/listinfo/busybox >
_______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
