Re: [patch 0/2] Add Fortuna PRNG to pgcrypto

On Fri, Jul 08, 2005 at 03:12:59PM -0500, Bruno Wolff III wrote:
> On Fri, Jul 08, 2005 at 23:03:49 +0300,
> Marko Kreen <marko(at)l-t(dot)ee> wrote:
> >
> > Well, those OS'es that already have urandom/random, don't need
> > it. And those that don't - I really don't feel responsibility
> > to write one...
>
> But fortuna is essentially a high quality /dev/urandom. It doesn't make seem to
> much sense to implement it on top on /dev/urandom.

Ah, the chain /dev/urandom -> Fortuna -> result irritates you?

The main reason for Fortuna is to cover OS'es that don't have
/dev/random. Currently only Win32 is adequately covered as it
provides it's own hardware random for seeding. On others
the output is theoretically weak, but the silly randomness plus
hashing user data (which is supposedly secret) and key (ditto)
should provide 'Good Enough for 99% cases' randomness.

Now - for /dev/random OS'es: ofcourse, if the /dev/urandom works,
I could skip all of the Fortuna and use that directly, but I don't
see the need for that. I even see disadvantage in doing that.

First, I prefer /dev/urandom to /dev/random (in Linux terms).
The /dev/random advantade is too theoretical for me - not worth
the practical disadvantage. But following applies to it too.

While there is hardware-backed entropy available the urandom
gives true randomness - no way to predict it. If the entropy
is drained, it degenerates into PRNG (although very good one).

The danger is, that if it runs as PRNG, some resourceful
'interested party' can read some of the output and then
predict what the next user will get or what some other user
got before. So it is pretty important not to drain all
entropy from it. /dev/random avoids this with blocking,
but IMHO urandom has state large enough to allow running
as a PRNG some time.

Now consider following scenario: you have 30 clients connected
to the server, each encryption something occasionally.
The current reseed delay is 3h - the result is that on
average, after every 6 seconds someone asks 256 bits from
/dev/urandom. This pretty much guarantees that entropy
will be drained - especially on an unattanded server.
The situation would be much worse if they all read directly
from /dev/urandom.

And here's the key difference - if they read directly from
/dev/urandom they all have PRNG with same state. If someone
observes enough of the output from there to predict what
others get, he can. But when using Fortuna inside pgcrypto:

- Each user (connection) will have different state.
- There is bigger chance that seeding from /dev/urandom
has true entropy in it.

So even if someone predicts one state, it has no effect
on other users. Ok, this is not exatly true when using
pooled connections - attacker could predict what the previous
user got or what next one will, but the fact that other
states are not compromised still stays.

OK, all this is rather theorethical. Practically speaking,
if we need to have Fortuna anyway, we may as well be better
OS citizens by using it on /dev/urandom too.

--
marko