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

Subject: Re: [boost] Boost.Uuid and header-only support
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2017-11-06 14:35:43

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.