On Wed, Nov 14, 2018 at 8:52 PM Noah Misch <noah@leadboat.com> wrote:
> On Wed, Nov 14, 2018 at 08:22:42PM +1300, Thomas Munro wrote:
> > On Wed, Nov 14, 2018 at 6:34 PM Noah Misch <noah@leadboat.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@leadboat.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?
>
> You mentioned that you rewrote the algorithm because the new function had a
> TimestampTz. But the BackendRun() code, which it replaced, also had a
> TimestampTz. You can reuse the exact algorithm. Is there a reason to change?
The old code used a "slightly hacky way to convert timestamptz into
integers" because TimestampTz might have been floating point back in
the day. Now that TimestampTz is always an integer, we might as well
use it directly and shuffle its bits for the same general effect, no?
The difference between x >> 20 and x / USECS_PER_SEC doesn't seem to
be material.
--
Thomas Munro
http://www.enterprisedb.com
