When there is 'ssl=on' then postmaster calls SSL_CTX_new(),
which asks for random number, thus requiring initialization
of randomness pool (RAND_poll). After that all forked backends
think pool is already initialized. Thus they proceed with same
fixed state they got from postmaster.
Output is not completely constant due to:
1) When outputting random bytes, OpenSSL includes getpid()
output when hashing pool state.
2) SSL_accept() adds time() output into pool before asking
for random bytes. This and 1) should make sure SSL handshake
is done with unique random numbers. [It's uncertain tho'
how unpredictable the PRNG is in such mode.]
Now, problem in pgcrypto side is that when compiled with OpenSSL,
it expects the randomness pool to be already initialized. This
expectation is filled when ssl=off, or when actual SSL connection
is used. But it's broken when non-SSL connection is used while
having ssl=on in config. Then all backends are in same state
when they reach pgcrypto functions first time and output is only
affected by pid.
Affected:
* pgp_encrypt*() - it feeds hashes of user data back to pool,
but this is "randomized", thus there is small chance first
few messages have weaker keys.
* gen_random_bytes() - this does not feed back anything, thus
when used alone in session, it's output will repeat quite easily
as randomness sequence is affected only by pid.
Attached patch makes both gen_random_bytes() and pgp_encrypt()
seed pool with output from gettimeofday(), thus getting pool
off from fixed state. Basically, this mirrors what SSL_accept()
already does.
I'd like to do bigger reorg of seeding code in pgcrypto, but
that might not be back-patchable. So I propose this simple fix,
which should be applied also to older releases.
--
marko