Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at