Re: pgcrypto seeding problem when ssl=on

On Fri, Dec 21, 2012 at 10:05:30PM -0500, Tom Lane wrote:
> This new patch looks pretty reasonable from here,
> modulo the question of whether it adds "enough" entropy.

More brains reviewing that question will be good.

> I'm not entirely sold on whether it does. ISTM that any attack based on
> this line of thinking already assumes that the attacker has complete
> knowledge of how many backends have been launched (else he doesn't know
> which sequence a targeted session will get).

pg_stat_activity.pid will do.

> If he knows that much,
> mightn't he also know *when* they were launched? Alternatively: if he
> can know the session's start time (which we helpfully make available...)
> how much harder is this really making it for him to deduce the session's
> seed?

If he has access to his own fork-time seed, he can indeed estimate the seeds
of other sessions. That seed is currently invisible to non-native code, and a
user able to deploy a C function already has the access needed to compromise
all sessions. The assumption that the fork-time seed stays buried is a source
of unease, though.

> On top of which: what exactly will he do with the seed once he's got it
> that would amount to a security problem?
>
> Or to put it in different terms, I'm not quite convinced that there's a
> plausible threat model that this patch blocks effectively.

The examples could be as numerous as the algorithms that specify use of a
cryptographically secure PRNG. Here's a simple one: an application generates
long-term private encryption keys by connecting, issuing "SELECT
gen_random_bytes(16)", and disconnecting. Long-term, across postmaster
restarts, there are still almost 2^128 possible keys. However, backends of
any given postmaster can only generate 2^15 possible keys. An attacker can
attempt to acquire, over time, a backend with every PID in the system. The
script I gave earlier is an example of doing so. He won't manage to visit
literally every PID, sure, but he'll easily get 95% of them. By issuing
"SELECT pg_backend_pid(), gen_random_bytes(16)" in each session, he assembles
a dictionary of most possible keys under this postmaster. If he repeats this
after each postmaster restart, he might acquire a dictionary covering months
or years of key generation. Given a ciphertext based on a key presumed to be
made during that time, he can try his relatively-small dictionary with a high
chance of success.

nm