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. 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 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:
redfishos:~ # cat /etc/firmware/touch_module_id_0x82.img | pigz -7c | sha1sum
1f0e7e00a47159708a5877b052d2e2c6e3489788 -
redfishos:~ # { cat /etc/firmware/touch_module_id_0x82.img; echo; } |
pigz -7c | sha1sum
d8db1ae97fc5ac8fa441db5c146d95fc43ac6d2e
In the best scenario $RANDOM provides a number that makes the
procedure change boot. The data read from /dev/urandom can be 32 bytes
or 64 bytes and the compression level can vary between 1 and 9.
Therefore every single bit of the input should be correctly guessed
otherwise the output will be completely different.
Instead of using $RANDOM, it is possible to use a value generated from
/dev/random by a single byte read:
randval=$(dd if=/dev/random bs=1 count=1 status=none | hexdump -ve '1/1 "%d\n"')
Or keep the first variant in which the initial data is read from
/dev/random in a range between 32 and 64 bytes, adding this trick just
in case $RANDOM is not defined.
Best regards, R-
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
