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

On Tue, 27 Jan 2026 at 23:57, Roberto A. Foglietta
<[email protected]> wrote:
>
> On Mon, 26 Jan 2026 at 15:04, Roberto A. Foglietta
> <[email protected]> wrote:
> >
> [...]
> > ~> https://github.com/robang74/working-in-progress/blob/main/random.txt
>
> Sure it was broken, the generation of the random numbers via shell...
> ...and when something is SO broken, it is impossible to fix, right?
>
> Fixed.

Also with a single process in userspace and fixed text as input

https://github.com/robang74/working-in-progress/blob/eba0a10e1509df224398564bf8a50b013c19a0a7/prpr/uchaos.c

/*
 * (c) 2026, Roberto A. Foglietta <[email protected]>, GPLv2 license
 *
 * test: cat uchaos.c | ./chaos -T 1000 | ent
 *
 * Compile with lib math: gcc uchaos.c -O3 -Wall -o uchaos
 *
 * ***************************************************************************
 * PRESENTATION
 *
 * despite a relatively simple coding, this uchaos binary is able to provide
 * nearly 4MB/s of (pseudo) random numbers generated from a static input (known
 * known and constant in time) by stochastics jitter-drive hashing.
 *
 * Not even a special hash, just a modified version of one of the most ancient
 * text-oriented hashing functions that was written before every theory check
 * (practice shows that it was good for real, not for chance).
 *
 * Contrary to the past experiments, the streams mixing here doesn't even happen
 * because it is a single thread process. And by the way, past experiments were
 * mixing almost known text strings but they could have easily mixed the various
 * /dev/random streams in such a way that even if /dev/random would have been
 * "tampered" by a global attacker of by NSA design, then such mixage would
 * have provided good speed and security.
 *
 * Note: current implementation is a text strings-only PoC, it cannot deal with
 * binary input that has EOB char (\0) in the input data. Quick to change but it
 * is not the point here but djb2tum, possibly.
 *
 * Spoiler: in mixing /dev/random with a reasonably good function, not
necessarily
 * a PRF-function (Mihir Bellare, 2014), the output is automatically
NIS-certified
 * as much as every other SW that rely on /dev/random. Why? N coloured dices
 * provide an ordered sequence (white, red, green, etc.) but every other
 * sequence (red, green, white, etc.) is also fine.
 *
 * The first run of commit (#9c8f4f00) passed all the dieharder tests with 49MB.
 *
 */

Best regards,
--
Roberto A. Foglietta
+49.176.274.75.661
+39.349.33.30.697