From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Honza Horak <hhorak(at)redhat(dot)com> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: random() generates collisions too early |
Date: | 2013-10-21 14:19:25 |
Message-ID: | 526537ED.2010607@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | alfonso.vicente | 2013-10-21 14:31:39 | BUG #8543: Standby recovery use incorrect timeline to determine WAL length |
Previous Message | Heikki Linnakangas | 2013-10-21 13:31:08 | Re: BUG #8532: postgres fails to start with timezone-data >=2013e |