Re: pgcrypto seeding problem when ssl=on

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Marko Kreen <markokr(at)gmail(dot)com>, Postgres Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgcrypto seeding problem when ssl=on
Date: 2012-12-22 03:05:30
Message-ID: 15489.1356145530@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Noah Misch <noah(at)leadboat(dot)com> writes:
> On Sat, Dec 22, 2012 at 12:59:55AM +0200, Marko Kreen wrote:
>> On Fri, Dec 21, 2012 at 10:27 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
>>> This should have gone to security(at)postgresql(dot)org, instead.
>>
>> It went and this could have been patched in 9.2.2 but they did not care.

> Ah.

A slightly less revisionist view of the history is that the patch that
Marko originally proposed to -security was considerably more complicated
and less portable than this one, so we put it on hold until we thought of
something better. This new patch looks pretty reasonable from here,
modulo the question of whether it adds "enough" entropy.

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). 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?

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2012-12-22 04:01:19 Re: pgcrypto seeding problem when ssl=on
Previous Message Tom Lane 2012-12-22 02:46:17 Re: Making view dump/restore safe at the column-alias level