| From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
|---|---|
| To: | Noah Misch <noah(at)leadboat(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: DSM segment handle generation in background workers |
| Date: | 2018-11-14 07:22:42 |
| Message-ID: | CAEepm=2xEKGUWJadcqXUWQQDfPy-urJ3hgJT50Svj7n8e6st-A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Nov 14, 2018 at 6:34 PM Noah Misch <noah(at)leadboat(dot)com> wrote:
> On Wed, Nov 14, 2018 at 05:50:26PM +1300, Thomas Munro wrote:
> > On Wed, Nov 14, 2018 at 3:24 PM Noah Misch <noah(at)leadboat(dot)com> wrote:
> > > What counts is the ease of predicting a complete seed. HEAD's algorithm has
> > > ~13 trivially-predictable bits, and the algorithm that stood in BackendRun()
> > > from 98c5065 until 197e4af had no such bits. You're right that the other 19
> > > bits are harder to predict than any given 19 bits under the old algorithm, but
> > > the complete seed remains more predictable than it was before 197e4af.
> >
> > However we mix them, given that the source code is well known, isn't
> > an attacker's job really to predict the time and pid, two not
> > especially well guarded secrets?
>
> True. Better to frame the issue as uniform distribution of seed, not
> unpredictability of seed selection.
What do you think about the attached?
--
Thomas Munro
http://www.enterprisedb.com
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Increase-the-number-of-possible-random-seeds-per-tim.patch | application/octet-stream | 1.7 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2018-11-14 07:51:51 | Re: Restore CurrentUserId only if 'prevUser' is valid when abort transaction |
| Previous Message | Dilip Kumar | 2018-11-14 06:38:01 | Re: Undo logs |