Re: random() generates collisions too early

On 10/21/2013 04:19 PM, Heikki Linnakangas wrote:
> On 18.10.2013 14:55, Honza Horak wrote:
>> On 10/18/2013 02:10 AM, Noah Misch wrote:
>>  > sudo sysctl -w kernel.pid_max=2048
>>  > psql -c 'create unlogged table samp(c float8)'
>>  > for n in `seq 1 200000`; do psql -qc 'insert into samp values
>> (random())'; done
>>  >
>>  > The results covered only 181383 distinct values, and 68 values
>> repeated four
>>  > or five times each. We should at least consider using a
>> higher-entropy seed.
>>
>> As I was told this is not taken as a security issue, since random() is
>> not considered as a CSPRNG in any case, but as Noah said, we should
>> probably try to make it a bit better.
>
> Interesting. PostgreSQL's random() function just calls the underlying
> libc random() function. I assume you tested this on with Linux and glibc.
>
>> Also, I'd suggest to state explicitly in the doc, that random()
>> shouldn't be taken as CSPRNG, since I can imagine people blindly
>> believing that random() can be good enough for such use cases, just
>> because they see how many possible values they get from double-precision
>> type:
>> http://www.postgresql.org/docs/9.3/static/functions-math.html
>
> Yeah, that seems like a good idea. A patch would be welcome.

I don't think we need to tell some long stories here, so what about this
one:
"pseudo-random value in the range 0.0 < x < 1.0 (characteristic of
randomness depends on the system implementation and is usually limited,
thus not considered as a CSPRNG in any case)"

Corresponding patch of doc is attached.

Regards,
Honza