On Sun, Nov 5, 2017 at 10:20 AM, Peter Dimov via Boost < boost@lists.boost.org> wrote:
James E. King, III wrote:
You're still using "optimal" only with respect to performance. It's > never optimal for random numbers to not be cryptographically secure.
Issues are always welcome.
Your use of "optimal" shows that you do not agree with the principle that generated random numbers should always be of cryptographic quality by default unless explicitly chosen by the user to not be. This fundamental mindset difference is not something issues can fix.
Actually the patient is open for surgery so I am quite open to making changes. You are suggesting that: 1. The default random_generator use a random_device for entropy. This is a breaking change, as the explicit constructors for random_generator would no longer take a boost::mt19937, so if anyone has this code they would need to change their random_generator to something else. Perhaps provide a random_generator_compat for them? 2. My use of optimal was relative to performance, yes. That does not mean what I said is what's best. That's why we're discussing it here, to reach alignment.
I'm adding boost::uuids::random_device_solo which is a > > basic_random_generator of random_device (header-only) type, ...
That's not a very good name. :-)
I changed it to random_generator_os, temporarily, but pending more discussion it may become random_generator.
It's not committed yet. :>
The logical choice would be random_device_generator but I don't like it because you'll give it a "token" parameter and insist on passing it to Wincrypt because unspecified multinationals using XP and a hardware entropy source will need it to meet hypothetical government standards.
I have already removed the token mechanism from the uuid detail implementation because it is unnecessary. Anyone is free to pass in their own UniformRandomNumberGenerator for which they can provide their own implementation, which will cover hardware-based entropy generation use cases. Boost.Uuid will provide a standard header-only random_device that uses bcrypt/cloudabi/file/wincrypt as necessary to meet platform requirements, but it will be in "detail". It is still a bit more complex than it needs to be so I am continuing to simplify it from what it was in the pull request for Boost.Random. For example I want to eliminate the variate/uniform_int generator layer and just use the UniformRandomNumberGenerators operator() directly. Again these are a work in progress and not committed yet. Happy to have picked up new tricks along the way, like using boost::enable_if and boost::tti to properly handle UniformRandomNumberGenerators that are PseudoRandomNumberGenerators depending on whether a seed method exists. - Jim