Re: [HACKERS] Query cancel and OOB data (fwd)

From: ocie(at)paracel(dot)com
To: hal(at)enteract(dot)com (Hal Snyder)
Cc: hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Query cancel and OOB data (fwd)
Date: 1998-06-01 21:32:17
Message-ID: 9806012132.AA03214@dolomite.paracel.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hal Snyder wrote:
>
> > From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message ocie 1998-06-01 21:41:23 Re: [HACKERS] regular expressions from hell
Previous Message Bruce Momjian 1998-06-01 19:36:56 Re: [HACKERS] cvs snapshot comm changes