Re: pgcrypto seeding problem when ssl=on
От | Tom Lane |
---|---|
Тема | Re: pgcrypto seeding problem when ssl=on |
Дата | |
Msg-id | 15489.1356145530@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pgcrypto seeding problem when ssl=on (Noah Misch <noah@leadboat.com>) |
Ответы |
Re: pgcrypto seeding problem when ssl=on
|
Список | pgsql-hackers |
Noah Misch <noah@leadboat.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@leadboat.com> wrote: >>> This should have gone to security@postgresql.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
В списке pgsql-hackers по дате отправления: