Hi Roberto, El lun, 18 sept 2023 a las 11:54, Roberto A. Foglietta (< [email protected]>) escribió:
> On Mon, 18 Sept 2023 at 11:20, Guillermo Rodriguez Garcia > <[email protected]> wrote: > > > >> # RAF: seeding the urandom device with some data and a few bits of > randomness. > >> # The randomness is put at the beginning of some text data, which > is going > >> # to be compressed. It is expected that the whole compressed data > will be > >> # way different each time, even if a great part of the input is > constant. > >> # Moreover, the size of the randomness changes each time into a > range of > >> # [32, 64] bytes, and this adds more unpredictability. Like a > hash, the > >> # compression algorithm will produce a way different binary output > by just > >> # changing a few bytes and initial conditions. > >> { > >> n=$((33 + ${RANDOM:-15}%32)) > >> dd if=/dev/random bs=$n count=1 2>&1 > >> cat /proc/cmdline /proc/*stat /init* > >> } | pigz -$((1 + n%9))c > /dev/urandom & > > > > Hi Gulliermo, > > first of all, thank for the feedback. > > > Not sure whether seeding dev/urandom with output from dev/random makes > much sense, since both use the same source of entropy. > > AFAIK, the /dev/random uses a source of entropy related to hardware > events while /dev/urandom is a pseudo-random generator. No, this is a common myth but it is not correct. Both random and urandom use the same PRNG. See: https://www.2uo.de/myths-about-urandom/ > This should > grant us that there is a difference between the two. immediately after > a boot, it is supposed that many hardware events took place Or not. This could be, for example, a cloned VM running on the cloud (which is a typical use case for busybox). > and > therefore reading some bytes from /dev/random would not be such a big > issue., IMHO. > > > Also note that dev/random will block if there is not enough entropy > left, so doing this in an init script might not be a very good idea -- > specially on systems that don't have a good source of entropy available. > > As as you might noticed in the function that I sent later answering > to Jeff, I do not use anymore the /dev/random but /dev/urandom > > udvseed(){ local n=$((33+${RANDOM:-15}%32)) u=/dev/urandom;f(){ dd > if=$u bs=$n count=1; };(cd /proc;f;cat cmdline *stat;f;) 2>&1|pigz > -$((1+n%9))c >$u; } > > This makes your first statement something to consider. Also $RANDOM if > available should be considered generated by the /dev/urandom and > therefore belonging to its entropy pool. If $RANDOM is not available > then my function is quite weak in term of unpredictability because > read 48 bytes from /dev/urandom which is not seeded yet and use it > with some proc data that might change but can be guessed and then > 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. Best regards, Guillermo Rodriguez Garcia [email protected]
_______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
