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:

1. Not all builds are done --with-openssl.

2. OpenSSL is rickety and poorly-documented, and depending on it for
more things will surely increase the pain we suffer on some great
future day when we begin supporting some other SSL library alongside

Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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

Reply via email to