On Wed, Nov 14, 2018 at 05:50:26PM +1300, Thomas Munro wrote: > On Wed, Nov 14, 2018 at 3:24 PM Noah Misch <n...@leadboat.com> wrote: > > On Mon, Nov 12, 2018 at 09:39:01AM -0500, Tom Lane wrote: > > > I doubt that's a good idea; to a first approximation, it would mean that > > > half the seed depends only on the PID and the other half only on the > > > timestamp. Maybe we could improve matters a little by left-shifting the > > > PID four bits or so, but I think we still want it to mix with some > > > rapidly-changing time bits. > > > > > > I'm not really sure that we need to do anything though. Basically, > > > what we've got here is a tradeoff between how many bits change over > > > a given timespan and how unpredictable those bits are. I don't see > > > that one of those is necessarily more important than the other. > > > > 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. Incidentally, possible future work may be to use pg_strong_random() when available, like pgbench set_random_seed() does. That would achieve both unpredictability and uniform distribution. It would be mere defense in depth; if unpredictability matters, one still needs a CSPRNG (e.g. pgcrypto).
