Re: pgcrypto seeding problem when ssl=on

On Sun, Jan 13, 2013 at 05:46:12PM -0500, Tom Lane wrote:
> Marko Kreen <markokr(at)gmail(dot)com> writes:
> > On Fri, Dec 21, 2012 at 10:27 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> >> How about instead calling RAND_cleanup() after each backend fork?
>
> > Attached is a patch that adds RAND_cleanup() to fork_process().
>
> I remain unconvinced that this is the best solution. Anybody else have
> an opinion?

I'd describe it as the clearly-secure solution. The biggest hazard I see is
the drain on system entropy. A system having only a blocking /dev/random
could suddenly find itself entropy-exhausted after installing the minor
upgrade. Backends could block waiting for system entropy to accumulate.
That's not directly a problem on Linux. However, if other programs on the
system read from /dev/random, the pressure from PostgreSQL's /dev/urandom
usage may make those programs wait longer for entropy.

I'm also comfortable with the security of Marko's original proposal, modulo it
happening in each backend shortly after fork, not merely in pgcrypto.
OpenSSL's ssl module uses a similar method, and one of the papers I cited
describes it. (If anything, OpenSSL is less cautious. It uses time(), not
gettimeofday().) The performance characteristics of this approach are easier
to guess: one system call if we use MyProcPid + gettimeofday(), zero if we use
MyProcPid + MyStartTime.

You proposed mixing gettimeofday() into the postmaster's entropy pool after
each fork. I wouldn't be too concerned if we did it that way, but my quick
literature review did not turn up any similar ideas. Given that this is
strictly more expensive than the previous method, I don't recommend it.

Overall, I'd recommend mixing in MyProcPid and MyStartTime after each fork.

nm