On Mon, Nov 6, 2017 at 9:35 AM, Andrey Semashev via Boost < boost@lists.boost.org> 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@lists.boost.org
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