On Mon, 4 Oct 2004, Bruno Wolff III wrote:
On Mon, Oct 04, 2004 at 18:58:41 +0200, Marco Colombo <[EMAIL PROTECTED]> wrote:
Actually, that should be done each time the random() function is evaluated. (I have no familiarity with the code, so please
That may be overkill, since I don't think that random has been advertised as a secure or even particularly strong random number generator.
bear with me if the suggestion is unsound). I'd even add a parameter for "really" random data to be provided, by reading /dev/random instead of /dev/urandom (but read(2) may block).
You don't want to use /dev/random. You aren't going to get better random numbers that way and blocking reads is a big problem.
Sure you are. As far as the entropy pool isn't empty, /dev/random
won't block, and thus there's no difference in behaviour.
When you're short of random bits, /dev/random blocks, /dev/urandom falls back to a PRNG + hash (I think SHA1). Under these conditions,
/dev/urandom output has 0 "entropy" at all: an attacker can predict
the output after short observation provided that he can break SHA1.
That is, anything that uses /dev/urandom (when the kernel pool is
empty) is just as safe as SHA1 is.
I agree that for a general purpose 'good' random() function, /dev/urandom is enough (as opposed to a plain-old PRNG). In some applications, you may need the extra security provided by /dev/random: its output (_when_ is available) it's always truly random (as long as you trust the kernel, of course - there have been bugs in the past in Linux about overestimating the randomness of certain sources, but they've been corrected AFAIK).
How about the following: random() = random(0) = traditional random() random(1) = best effort random() via /dev/urandom random(2) = wait for really random bits via /dev/random
It might be nice to have a secure random function available in postgres. Just using /dev/urandom is probably good enough to provide this service.
Why not all of them. The problem is how to handle a potentially blocking read in /dev/random (actually _any_ disk read may block as well). Just warn people not to use random(2) unless they really know what they're doing...
I don't think the read syscall overhead is noticeable (in Linux at least). But for sure we can't afford to _open_ /dev/urandom each time... backends will have to keep an extra fd open just for /dev/urandom... hmm... I can't think of any better way of doing that.
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ [EMAIL PROTECTED]---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
