On Friday 16 January 2015 13:00:55 Andrey Semashev wrote:

On Friday 16 January 2015 13:49:27 Antony Polukhin wrote:

...

Hi,

Looks like Boost.UUID library is not maintained.

Could someone take care of that library. Especially I'm interested in applying a pull request to fix 9407 https://svn.boost.org/trac/boost/ticket/9407 issue ( https://github.com/boostorg/uuid/pull/2). Pull request has been already reviewed by Andrey Semashev and significantly improved.

There is actually another important pull request that is lingering:

https://github.com/boostorg/uuid/pull/4

as well as a few others. I tried to contact the author privately but got no response. So perhaps this library should be managed by CMT now? Forwarding it to boost-maint list.

I received a response from Andy Tompkins today where he approves that CMT takes over Boost.UUID. He is interested in contributing to it in the future though.

Andrey Semashev wrote:

On Friday 16 January 2015 18:33:28 Peter Dimov wrote:

...

Antony Polukhin wrote:

...

Especially I'm interested in applying a pull request to fix 9407 https://svn.boost.org/trac/boost/ticket/9407 issue ( https://github.com/boostorg/uuid/pull/2).

On Windows, the usual procedure is to use RtlGenRandom, but I'm not sure which approach is better.

I think it's not public API. MSDN recommends using CryptGenRandom instead.

There are no longer any non-public Windows APIs as a result of the antitrust lawsuit, but yes, it's probably better to use the supported version. On a more general note, all this homegrown entropy gathering in that function (for most of which I might be responsible, in fact) should just be skipped if we have CryptGenRandom or /dev/urandom; it should merely be a fallback. We're never going to improve upon CryptGenRandom's output, most we could do is not damage it, and /dev/urandom is, I think, also reasonably-crypto-quality on today's POSIX OSes. There's one subtlety though, the fact that we currently proceed unconditionally to mixing homegrown entropy allows us to not check for errors from CryptGenRandom or fread, and if we're going to skip it, we should check. On an even more general note, this is actually a reimplementation of random_device, so it might be worth fixing that to always work (and perhaps take advantage of std::random_device if present?).

Antony Polukhin wrote:

We have no guarantee that CryptGenRandom algorithm is not reversible or predictable.

There is enough information at http://msdn.microsoft.com/en-us/library/windows/desktop/aa379942(v=vs.85).as... http://en.wikipedia.org/wiki/CryptGenRandom http://blogs.msdn.com/b/michael_howard/archive/2005/01/14/353379.aspx

So mixing in some additional entropy seems reasonable.

There is no guarantee that mixing in highly predictable, or constant, values using SHA1 improves the quality of the random numbers, or decreases their predictability. It is not at all impossible for such amateur improvements to actually decrease the quality of the original source. The only genuine entropy here is QueryPerformanceCounter, which is already incorporated into the output of CryptGenRandom. And in fact, the goal of the original code has never been to achieve crypto quality randomness, or even to approach the quality of CryptGenRandom. It's just for UUID generation, after all.