[uuid] Platform-specific UUID generator (was Re: Issue 9407: please merge fix)
On Fri, Jan 16, 2015 at 10:49 AM, Antony Polukhin <antoshkka@gmail.com> wrote:
Looks like Boost.UUID library is not maintained.
This is unfortunate and reminded me this exchange: https://twitter.com/niv_anteru/status/487496938150195200 A platform-specific random generator would apparently be far more efficient (I say apparently because I didn't know there were platform-specific uuid generation until I read this tweet). I reminded this with the fix discussion and made the ticket marked as feature request: https://svn.boost.org/trac/boost/ticket/10939 I'm taking note to try a patch but don't hold your breath. Also, would there be any benefit in having another typedef in C++11 mode which would use the std mersene twister instead of the boost one?
On Sunday 18 January 2015 13:57:05 Klaim - Joël Lamotte wrote:
On Fri, Jan 16, 2015 at 10:49 AM, Antony Polukhin <antoshkka@gmail.com>
wrote:
Looks like Boost.UUID library is not maintained.
This is unfortunate and reminded me this exchange: https://twitter.com/niv_anteru/status/487496938150195200
A platform-specific random generator would apparently be far more efficient (I say apparently because I didn't know there were platform-specific uuid generation until I read this tweet).
I reminded this with the fix discussion and made the ticket marked as feature request: https://svn.boost.org/trac/boost/ticket/10939
I'm taking note to try a patch but don't hold your breath. Also, would there be any benefit in having another typedef in C++11 mode which would use the std mersene twister instead of the boost one?
If we're speaking about Windows then I believe the system-provided functions for UUID generation require linking to auxiliary libraries (i.e. not kernel32.dll) - COM implementation, if I'm not mistaken. http://msdn.microsoft.com/en-us/library/windows/desktop/ms688568%28v=vs.85%2... Interestingly, it also mentions UuidCreate of which I didn't know before. It also requires another library to link with and also does not guarantee universal uniqueness. On POSIX systems there is no standard API for UUIDs, AFAIK. I'm only aware of libuuid, if it can be considered widespread enough. The bottom line is that using specialized APIs will require linking to additional libraries, possibly non-standard, which may be undesirable. OTOH, it's not clear if UUID generation can be considered a performance critical operation.
Andrey Semashev wrote:
Interestingly, it also mentions UuidCreate of which I didn't know before.
Based on its description in the documentation, I strongly suspect that UuidCreate just calls CryptGenRandom to create a 128 bit random number, then sets the UUID type appropriately. Which is, as I argued, what we need to do as well.
On Sunday 18 January 2015 17:19:03 Peter Dimov wrote:
Andrey Semashev wrote:
Interestingly, it also mentions UuidCreate of which I didn't know before.
Based on its description in the documentation, I strongly suspect that UuidCreate just calls CryptGenRandom to create a 128 bit random number, then sets the UUID type appropriately. Which is, as I argued, what we need to do as well.
I don't mind us doing that, with a fallback if CryptGenRandom path fails. Although CryptGenRandom description doesn't say whether its entropy is renewed.
Andrey Semashev wrote:
Although CryptGenRandom description doesn't say whether its entropy is renewed.
It doesn't actually matter, when the generator is AES counter mode, which is specified to be the case from Vista SP1 onwards. Before that, it was in principle possible to attack it as it was RC4 based, but that still required access to the local machine. I see, by the way, that boost::random_device is already implemented to use CryptGenRandom. It requires building though, and Boost.System for the error reporting.
participants (3)
-
Andrey Semashev -
Klaim - Joël Lamotte -
Peter Dimov