On Thu, Oct 07, 2004 at 12:08:51 +0200,
Marco Colombo <pgsql@esiway.net> wrote:
> On Wed, 6 Oct 2004, Bruno Wolff III wrote:
>
> >You don't necessarily need to break SHA1 to be able to track the internal
> >state.
>
> Well, I'm not an expert. I base my knowledge on what other people say.
> Quoting the opening comment in random.c from a recent Linux kernel tree:
I was thinking something like have root access for a short time or getting
access to the state that is saved between reboots off a backup tape or
something.
> Whether "random numbers that are merely cryptographically strong"
> are acceptable for your application is up to you. Your application
> blocking might be even a less acceptable event, but I don't buy this
> kind of argument. Random bits are just another resource.
I think we agree here. I just don't see many cases where the risk of SHA1
being broken in a way useful to compromise /dev/urandom is significant
compared to other risks for a typical postgres system.
> >Assuming that all 128 bits were grabbed in one call to /dev/random, you
> >should be safe. However if the bits were returned a byte at a time
> >with intervening bytes returned to /dev/urandom to the attacker, the
> >key could be vunerable.
>
> I'm not sure I get the "intervening bytes" part. Guessing a 128-bits long
> string or a 160-bits long one of which 32 bits are known shouldn't make
> any difference.
I am not sure of the semantics of a read from /dev/random requesting, say
16 bytes. If you are guarenteed to get all 16 bytes without anyone else
being able to get any /dev/urandom reads inbetween any of the bytes, you
have convinced me that /dev/random does protect the data better than
/dev/urandom. However if you get /dev/urandom output between the bytes
(by say knowing the approximate rate at which entropy is being collected
and doing the requests in bursts shortly after estimating enough entropy
for one byte has been obtained) then you have to only break 16 8 bit
keys instead of one 128 bit key.
> I know 0 of PostgreSQL internals and development issues.
> I'll play with the idea of making a contrib module.
It should be pretty easy to write a C function that reads from /dev/[u]random.
Extensability is one of the nice features of Postgres.
