Re: How can I build OSSP UUID support on Windows to avoid duplicate UUIDs?

From: Garick Hamlin <ghamlin(at)isc(dot)upenn(dot)edu>
To: MauMau <maumau307(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Hiroshi Saito <hiroshi(at)winpg(dot)jp>, Dave Page <dpage(at)pgadmin(dot)org>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: How can I build OSSP UUID support on Windows to avoid duplicate UUIDs?
Date: 2013-10-31 17:02:22
Message-ID: 20131031170222.GH28438@isc.upenn.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 31, 2013 at 09:54:14PM +0900, MauMau wrote:
> From: "Robert Haas" <robertmhaas(at)gmail(dot)com>
>> ISTM that the biggest problem is that we don't have a random number
>> generator which generates enough bits of randomness to implement
>> uuid_generate_v3. I think relatively few people would cry if we
>> didn't support uuid_generate_v1(), and the others all look simple
>> enough, provided there's somewhere to get lots of random bits.
>>
>> On Linux, it seems like we could get those bits from /dev/urandom,
>> though I'm not sure how efficient that would be for the case where
>> many UUIDs are being generated at once. But that wouldn't be very
>> portable. It's tempting to think that we'd need a PRNG that generates
>> wider values, for which we might find other application also. But I'm
>> not volunteering to be the one to create such a thing.
>
> OpenSSL provides rand_bytes() which generates random bytes of any length.
> It uses /dev/urandom or /dev/random on UNIX/Linux and Crypto API of
> Microsoft on Windows.

What about using a cipher here as the PRNG? It seems like using openssl
rand_bytes() to seed aes in ctr would work ok without starving the system of
entropy when making a lot of uuids.

Garick

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2013-10-31 17:07:17 Re: API bug in DetermineTimeZoneOffset()
Previous Message Tom Lane 2013-10-31 16:52:41 API bug in DetermineTimeZoneOffset()