RFC: initialize /dev/urandom, is it necessary? Can we do it in a better way?

[Guillermo Rodriguez Garcia]

El lun, 18 sept 2023 a las 9:42, Roberto A. Foglietta (<
roberto.foglietta at gmail.com>) escribió:

> Hi all,
>
>  I am investigating the Android init procedure (one version, one
> device, not in general) and I found an interesting line about the
> initialization of the /dev/urandom (seeding, I suppose).
>
>  cat /proc/cmdline > /dev/urandom
>
>  Therefore, I developed a more sophisticated way to do that initialisation:
>
> # 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 &
>

Not sure whether seeding dev/urandom with output from dev/random makes much
sense, since both use the same source of entropy.

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.

Guillermo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20230918/58f9e89c/attachment.html>