How to deal with insufficient entropy?

[Knogle]

Ahoy folks. Today i had an issue with a bugged kernel in fedora, which caused /dev/urandom to provide bad entropy below 5.
Now after kernel update, it has been fixed.
But in my opinion we have to consider this case for nwipe as well.
I'd implement using OpenSSL a second entropy source using OpenSSL secure seed function.
Also another 3rd source might be RDSEED.
Afterwards i would compare the entropies with a function, and use the best source, or only other source than /dev/urandom if it's entropy is trash.

 chairman  /  tmp  ./random_test 
Generated number from /dev/urandom: 16093874829290398580
Generated secure number with OpenSSL: 15071724709619326984
Calculated entropy for /dev/urandom number: 0.982317
Calculated entropy for OpenSSL number: 0.965202
Entropy of /dev/urandom number is higher.
 chairman  /  tmp  ./random_test 
Generated number from /dev/urandom: 11040882187890465188
Generated secure number with OpenSSL: 12642248249775629216
Calculated entropy for /dev/urandom number: 0.988699
Calculated entropy for OpenSSL number: 0.999295
Entropy of OpenSSL number is higher.
 chairman  /  tmp  ./random_test 
Generated number from /dev/urandom: 17993105468484316347
Generated secure number with OpenSSL: 3046486997064974945
Calculated entropy for /dev/urandom number: 0.988699
Calculated entropy for OpenSSL number: 0.988699
Both numbers have the same entropy.

What are your thoughts on this?
BR,

[PartialVolume]

Also another 3rd source might be RDSEED.
Afterwards i would compare the entropies with a function, and use the best source, or only other source than /dev/urandom if it's entropy is trash.

Sounds good, you're talking about a function within nwipe to test entropy?

If so can that function also be called to test the first block of data generated by the aes prngs, at runtime so that we know the Openssl functions are working? Basically a data-in integrity test on the random data to test for a broken Openssl implementation. I know we are checking return status but a entropy test on the first block generated would be the ultimate test that the random data is being generated correctly.

[Knogle]

Sure, thats doable. I am currently developing a self-test routine for assessing entropy during startup to determine whether to use urandom or OpenSSL's rand. We need to decide if we want to include support for RDSEED, potentially limiting it to x86 architectures due to the requirement of x86 assembly code, which could affect compatibility with other platforms like ARM. Or just check for architecture, and depending on this, offer this option.

For the AES PRNG, I can implement a dry run as part of the init process. This would involve generating around 1 up to 16KB of random data and analyzing it to ensure adequate entropy and quality.

[Knogle]

Currently doing some attempts on implementing/rewriting the entropy stuff. This is a tough one, because i think it wasn't intended to be changed ever.
It seems like nwipe works with entropy_fd file handlers (in method.c, but it get's set in nwipe.c in the actual current implementation) when reading from the entropy.
So we have to change it somehow to use a function instead. Or we could use a legacy approach, piping from the nwipe_entropy_dev_urandom_read() function, casting the uint64_t into int.
Also there is no consistent datatype for all the entropy and seed handling through nwipe. Maybe we should use uint64_t for all, or something else.
This would basically involve changes in nwipe.c method.c gui.c and prng.c as well as prng.h . If we want to include them into the nwipe_options_t struct, we have to consider options.c and options.h as well.
What do you think? Maybe you can take a look onto my first attempts in my external-seeding branch. https://github.com/Knogle/nwipe/tree/external-seeding