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. Garick -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
