On Thu, Oct 31, 2013 at 01:59:04PM -0400, Robert Haas wrote:
> On Thu, Oct 31, 2013 at 1:02 PM, Garick Hamlin <gham...@isc.upenn.edu> wrote:
> > On Thu, Oct 31, 2013 at 09:54:14PM +0900, MauMau wrote:
> >> From: "Robert Haas" <robertmh...@gmail.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.
> There are two good reasons for us NOT to rely on OpenSSL:

Right, that makes sense.  openssl is a non-starter here.  In which case that
approach is no easier than any other prng.

I think using /dev/urandom directly would be surprising.  At least it would
have probably have taken me a while to figure out what was depleting the
entropy pool here.


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to