Re: UUIDs in core WAS: 9.4 Proposal: Initdb creates a single table - Mailing list pgsql-hackers

From Marti Raudsepp
Subject Re: UUIDs in core WAS: 9.4 Proposal: Initdb creates a single table
Date
Msg-id CABRT9RBL-4aVpTLbTnAJARh2Vxqropk4ZOAAV0x2j2kWMH2nTQ@mail.gmail.com
Whole thread Raw
In response to Re: UUIDs in core WAS: 9.4 Proposal: Initdb creates a single table  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
On Fri, Apr 25, 2014 at 8:58 PM, Josh Berkus <josh@agliodbs.com> wrote:
> Well, I've already had collisions with UUID-OSSP, in production, with
> only around 20 billion values.  So clearly there aren't 122bits of true
> randomness in OSSP.  I can't speak for other implementations because I
> haven't tried them.

Interesting. The statistical chances of this happening should be
approximately 4e-17. Are you certain that this was due to uuid-ossp
and not an application bug?

Can you say what kind of operating system and environment that was? I
skimmed the sources of uuid-ossp 1.6.2 and it seems to be doing the
right thing, using /dev/urandom or /dev/random on Unixes and
CryptGenRandom on Windows. Barring any bugs, of course. However, if
these fail for whatever reason (e.g. out of file descriptors), it
falls back to libc random(), which is clearly broken.

On Fri, Apr 25, 2014 at 6:18 PM, Greg Stark <stark@mit.edu> wrote:
> The difficulty lies not really in the PRNG implementation (which is
> hard but well enough understood that it's not much of an issue these
> days). The difficulty lies in obtaining enough entropy. There are ways
> of obtaining enough entropy and they are available.

> Obtaining enough entropy requires access to hardware devices which
> means a kernel system call.

This is a solved problem in most environments, too. The kernel
collects entropy from unpredictable events and then seeds a global
CSPRNG with that. This collection happens always regardless of whether
you request random numbers or not, so essentially comes for "free".
Applications can then request output from this CSPRNG.

Reason being, this infrastructure is necessary for more critical tasks
than generating UUIDs: pretty much all of cryptography requires random
numbers.

> They also deplete
> the available entropy pool for other sources which may means they have
> security consequences.

This only affects the Linux /dev/random, which is discouraged these
days for that reason. Applications should use urandom instead. To my
knowledge, there are no other operating systems that have this
"depletion" behavior.

Regards,
Marti



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Decrease MAX_BACKENDS to 2^16
Next
From: Christoph Berg
Date:
Subject: Re: includedir_internal headers are not self-contained