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

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

...

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.