Tom Lane wrote:
>
> Bruce Momjian <maillist@candle.pha.pa.us> writes:
> > I was trying to avoid the
> > 'magic cookie' solution for a few reasons:
>
> > 1) generating a random secret codes can be slow (I may be wrong)
>
> Not really. A typical system rand() subroutine is a multiply and an
> add. For the moment I'd recommend generating an 8-byte random key with
> something like
>
> for (i=0; i<8; i++)
> key[i] = rand() & 0xFF;
>
> which isn't going to take enough time to notice.
>
> The above isn't cryptographically secure (which means that a person who
> receives a "random" key generated this way might be able to predict the
> next one you generate). But it will do to get the protocol debugged,
> and we can improve it later. I have Schneier's "Applied Cryptography"
> and will study its chapter on secure random number generators.
A neat feature of linux is that it has a kernel random number
generator which is fed random data from interrupt times. The only
drawback is that this is sort of a "pool", so whn the pool is full,
drawing 8 bytes from it is not a problem, but when the pool is
drained, it can take some time to generate more data. At any rate, it
might be a good starting point for a postgres random number generator
-- sample usage of shared memory and perform a hash on this. From
"applied cryptography":
"In effect, the system degrades gracefully from perfect to practical
randomness when the demand exceeds the supply. In this case it
becomes theoretically possible .. to determine a previous or
subsequent result. But this requires inverting MD5, which is
computationally infeasible"
applied cryptography, 2nd eddition, p427.
This is sort of what we want. As random as the key can be, but able
to generate a pseudo-random key if we're short on time.
Ocie