On Fri, Apr 25, 2014 at 8:58 PM, Josh Berkus <j...@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 <st...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers