Re: [HACKERS] Query cancel and OOB data (fwd) - Mailing list pgsql-hackers

From ocie@paracel.com
Subject Re: [HACKERS] Query cancel and OOB data (fwd)
Date
Msg-id 9806012132.AA03214@dolomite.paracel.com
Whole thread Raw
In response to Re: [HACKERS] Query cancel and OOB data (fwd)  (Hal Snyder <hal@enteract.com>)
List pgsql-hackers
Hal Snyder wrote:
>
> > From: Bruce Momjian <maillist@candle.pha.pa.us>
> > Date: Mon, 1 Jun 1998 00:53:21 -0400 (EDT)
> ...
> > > Just do time and pid. But get the time from gettimeofday so it will be
> > > down to the millisecond or so. Anything more is overkill for this application.
> >
> > You have given me exactly what I needed.  If I run gettimeofday() on
> > postmaster startup, and run it when the first backend is started, I can
> > use the microseconds from both calls to generate a truely random seed.
> > Even if the clock is only accurate to 10 ms, I still get a 10,000 random
> > keyspace.  I can mix the values by taking/swapping the low and high
> > 16-bit parts so even with poor resolution, both get used.
> >
> > The micro-second times are not visible via ps, or probably even kept in
> > the kernel, so these values will work fine.
> >
> > Once random is seeded, for each backend we call random twice and return
> > a merge of the two random values.  I wonder if we just call random once,
> > and XOR it with our randeom seed, if that would be just as good or
> > better?  Cryptologists?
> >
> > Comments?  Sounds like a plan.  The thought of giving the users yet
> > another option to disable cancel just made me squirm.
>
> For FreeBSD and Linux, isn't /dev/urandom the method of choice for
> getting random bits? [I've been away from this thread awhile - please
> excuse if this option was already discussed].

I believe /dev/random is guaranteed to be "random", while /dev/urandom
is guaranteed to return a certain number of psuedorandom bytes in a
given time.  These are not universally available though.  Seeding with
bits taken from the pid and hi-res time should be OK.

Something I did on a similar task was to set up a max-keys-per-key and
max-elapsed-time-per-key.  Basically, seed the random number generator
when the postmaster starts, and reseed after every 10 keys, or if 10
minutes have elapsed since the random number generator was las seeded.
This way, the would be attacker can't know for sure when the random
number generator was last reseeded.


Ocie Mitchell

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] cvs snapshot comm changes
Next
From: ocie@paracel.com
Date:
Subject: Re: [HACKERS] regular expressions from hell