Quote from: Carlton Banks on August 12, 2023, 02:37:01 PM

opinion is that the original code was also pretty dubious for securely seeding an RNG (src/utility/random.cpp:39-41). depending on the output of std::random_device is clearly implementation/platform specific

I think there are good odds that for any platform where the code can actually be built that function just read randomness from the OS, but you're right that it isn't guaranteed.

Basically it seems they changed from code that had security problems in theory but usually not (and maybe never) in practice to code that was certainly broken all the time for everyone in both theory and practice.

[/quote]
in fact, ISTM it's not even necessary to search the entire 32-bit number space?! surely it's possible to feed unix-timestamps since the 2016 date/time when the PR was merged into some common c++ mersenne_twister implementations to find every seed generated with the insecure code. either way, it's very surprising that it's taken 7 years for anyone to notice
[/quote]The timer is a high resolution (nanosecond) one and it uses the least significant bits of it, so it loops every 4.2 seconds or so. But depending on the platform not all the bits will be used, e.g. mac i think only has microsecond resolution.

In any case it shouldn't matter because optimized code will make fast work of all 32-bits.

Quote from: NotATether on Today at 04:17:46 AM

I don't think there's any. If they wanted to just use it as a unit test for their seed generation algorithm, they should've left it at that and not make it a public API or command.

But there isn't any test it's used for I can find, and its used in all the documentation any place a seed is needed. I also can't find any instructions in their docs on how you *should* generate the seed. Like if you want to use dice you still need a procedure to de-bias the dice (and to get hex out). I don't buy it, it's just not a credible excuse to me. To be clear, I'm not suggesting that it was intentionally vulnerable, but that it was just mistaken and that a rather non-pragmatic view on what users will or should do caused it to not get as much care as it ought to have.

Quote from: Carlton Banks on August 12, 2023, 02:37:01 PM

and that's without considering the actual (uncommented) change to cast the current system time (!) to an unsigned 32-bit integer as the return type for the function providing the entropy seeding data. I'm 100% confident that you don't need to be an expert to see that this is staggeringly unprofessional, rock-bottom basic tutorials for generating entropy describe exactly this sort of practice as badbadbad

It's also likely bad for the non-cryptographic usage in libbitcoin. An attacker can observe some of the choices made by the software you can recover the RNG state then use it to predict the random choices that were used and will be used, which likely results in DOS vulnerabilities.

On modern computers there is seldom a reason to use very poor randomness. The only time these days when I use non-cryptographic randomness is for the inner loops of optimization search code where the RNG is very performance critical. In those cases I'll use xoshiro256++ periodically seeded with rdrand (the hw RNG on modern cpus). But in any ordinary software it's uncommon for the rng performance to matter so much that you can't use a cryptographic one.

Maybe in some usage or another using a crappy PRNG with weak seeding wouldn't be harmful, but it's usually not worth the cost of figuring out if its safe or not (and making sure it stays safe as people change code), better to use a safe thing unless and until the performance is an issue and then figure out if something faster can be used safely.