Re: [boost] Boost.Uuid and header-only support

Subject: Re: [boost] Boost.Uuid and header-only support
From: James E. King, III (jking_at_[hidden])
Date: 2017-11-05 14:11:58

On Sun, Nov 5, 2017 at 8:37 AM, Peter Dimov via Boost <boost_at_[hidden]
> wrote:

> Andrey Semashev wrote:
>
>> On 11/05/17 16:00, Peter Dimov via Boost wrote:
>> > 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.
>>
>> Mersenne twister has a very long period - probably longer than any given
>> application can reasonably run to generate UUIDs, let alone a single
>> random_generator instance.
>>
>
> In general when random numbers are concerned, the best default option is
> to use crypto-secure numbers if you can afford it, because doing otherwise
> may have security implications. You could have an active attacker guessing
> the output of the PRNG given sufficient amount of output - which he'll have
> if you generate 50M UUIDs per second.
>
> To eliminate even the slightest possibility of UUID collisions, you can
>> re-seed the Mersenne twister PRNG periodically.
>>
>
> This will reduce or eliminate its performance advantage.
>
> And performance of generating UUIDs can be significant in some
>> circumstances. UUIDs are typically used as various resource identifiers
>> (think sessions, users, etc.), so poor performance can limit the rate of
>> allocation of such resources.
>>
>
> Sure. As I said, if speed is more important than quality, it's optimal to
> use a seeded-once Mersenne twister, and the option to do so will not be
> going away. When it isn't, it isn't.
>
> (I've trouble imagining a scenario in which you won't run out of resources
> if you allocate 50M resource identifiers per second, but let's suppose one
> exists, for the sake of argument.)
>
>
I'm adding boost::uuids::random_device_solo which is a
basic_random_generator of random_device (header-only) type,
and documented it as optimal for one-off UUID generation, whereas the
standard random_generator is best suited
to be reused (in a thread-safe manner) for multiple uuid generation.

boost::uuids::uuid u = boost::uuids::random_generator_solo()();  // avoids
PRNG setup overhead

I'm also adding unit tests to properly test all the Wincrypt and Bcrypt
failure paths in the header-only random_device.
It won't show up in the codecov reports from the linux build however.
It would be nice to have a more automated integration for leveraging
generation of gmocks inside Boost.WinAPI somehow...
(I'm not using gmock for this effort, just a suggestion) it would make
mocking the Win32 APIs easier.

- Jim