James E. King, III wrote:
In other words, the existing implementation may be optimal using a PRNG.
This depends on your definition of optimality. If speed is more important than not having UUID collisions, sure, it's optimal.
I have not tried RtlGenRandom yet, but I am worried about removing Wincrypt in favor of that because it will break any implementation that uses its own entropy provider, for example a wincrypt driver that hooks up to a hardware entropy generator based on project requirements (government, etc).
What definition of "break" do you use here? I can't imagine that seeding a Mersenne twister with whatever hardware source of entropy can meet any government requirements, or that such a project will not generate its UUIDs directly from the entropy source, instead of going through a third-party library that needs to be audited and re-audited if upgraded. Plus, the entropy provider is hardcoded at present. What specific scenario will "break"?