Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 49423 invoked by uid 500); 12 Mar 2003 20:52:22 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 49411 invoked from network); 12 Mar 2003 20:52:21 -0000 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Wed, 12 Mar 2003 12:54:40 -0800 From: Greg Stein To: dev@apr.apache.org Subject: Re: apr_generate_random_bytes() blocks forever Message-ID: <20030312125440.B24764@lyra.org> Mail-Followup-To: dev@apr.apache.org References: <86llzltu0r.fsf@kepler.ch.collab.net> <20030311213316.GA1427@manyfish.co.uk> <86hea9tr0d.fsf@kepler.ch.collab.net> <3E6E5995.4080606@xbc.nu> <85hea9xznc.fsf@newton.ch.collab.net> <3E6F9739.9060409@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3E6F9739.9060409@algroup.co.uk>; from ben@algroup.co.uk on Wed, Mar 12, 2003 at 08:23:21PM +0000 X-URL: http://www.lyra.org/greg/ X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Wed, Mar 12, 2003 at 08:23:21PM +0000, Ben Laurie wrote: > Karl Fogel wrote: > > Branko Cibej writes: > > > >>>Or gstein has suggested that apr_generate_random_bytes() can grow a > >>>new flag, indicating urandom is preferred. Actually, when we were talking, I was thinking flags to define its behavior, more like what Ben is talking about below. For example, a flag to say "pseudo random data is acceptable". Certainly nothing as low-level as "don't block". The flag would indicate the *type* of data to return. >... > Woah! That's so wrong! The problem is that if you really want n bits of > _real_ randomness, you may _have_ to block. Right. >... > The most general fix I can think of is an interface where you pass > _three_ numbers. k, n and i, where k is the number of bits of randomness > you want, n is the number of bits of entropy you want for _this_ chunk > of randomness, and i is the number of initial bits of entropy you want > invested in randomness. Would n==i==0 be a typical pseudo-random generator? Assuming so, then I like this interface. I'll also note that the UUID generation would simply ask for k=48, n=i=0. (6 bytes of "good" random data, but cryptographic randomness is not important) Cheers, -g -- Greg Stein, http://www.lyra.org/