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-06 15:31:05

On Mon, Nov 6, 2017 at 9:35 AM, Andrey Semashev via Boost <
boost_at_[hidden]> wrote:

> On 11/06/17 16:26, James E. King, III via Boost wrote:
>
>> On Mon, Nov 6, 2017 at 7:49 AM, Peter Dimov via Boost <
>> boost_at_[hidden]
>>
>>> wrote:
>>>
>>
>> Paul A. Bristow wrote:
>>>
>>>> I have been following this erudite discussion with interest, but >
>>>>>
>>>> ignorance.
>>>>
>>>>>
>>>>> Without wishing to add even more entropy, may I suggest that adding
>>>>>
>>>> more > options is rarely a bad thing, but it creates an even more
>>>> bewildering > set of options for the user (for UUID, I fear as ignorant
>>>> as
>>>> I).
>>>>
>>>> That is why I'd like the default generator to do the right thing and
>>>> doing the wrong thing to be harder and not be presented as an
>>>> equivalent...
>>>>
>>>>
>>> ... or more "optimal"...
>>>
>>>
>>> alternative.
>>>
>>>>
>>>>
>>> I'm planning to change random_generator to use the header-only
>> random_device
>> based on points made in this discussion:
>>
>> 1. It is more secure.
>> 2. I believe it is the most widely used use case: generating a uuid
>> relatively infrequently
>> (i.e. not in bulk).
>>
>
> I still think that having random_generator as an object is an advantage
> that people probably use for performance. I would prefer the entropy-based
> generator to be provided under a different new name.
>
> I understand the arguments for more secure implementation by default,
> although it appears to me that after the change the more secure
> implementation is going to be the only one provided by Boost.UUID, not just
> the default. What I disagree with is that the cost of more security is
> going to be imposed on all users, whether they need it or not. And frankly,
> I don't think that security should depend on UUID properties in the first
> place - UUIDs are *not* a security measure, it is a piece of data that
> should be adequately protected by a separate security layer. If you don't
> protect it and rely on its properties like unpredictability then you're
> wrong.
>
> The primary use of UUIDs is an id - a slightly better version of a counter
> that doesn't need to be synchronized between threads or processes.
> Name-based generators also allow it to be a sort of a hash function as
> well. Thus it should be cheap to create and operate on. Having a more
> secure random generator may be useful as an option, but really the primary
> concern about UUIDs is their uniqueness, not predictability. An attacker
> should not have an access to your sensitive data, including UUIDs, in the
> first place.
>
>
Based on testing, it is faster to use the non-deterministic
UniformRandomNumberGenerator
provided by the operating system if you are creating less than 100 uuids
(on my system, obviously).

I believe the majority of users are probably calling
boost::uuids::random_generator()() to make a uuid
as the documentation had nothing in it about performance.  It does now, at
least in my sandbox.

Once the PR is ready for review I will post it here for review.

Peter's last email led me to change how random_device is defined so now it
is quite easy to make
an operating system provided random_device typedef with a configurable
entropy size using a single macro.
Therefore where a PRNG is used and it wants to seed with an iterator taking
unsigned int, and in
the case where we want 16 bytes in a single call from the OS, both cases
are now optimal.

- Jim