In message <20020529090027.GA13251@rek.tjls.com>, Thor Lancelot Simon writes:
>On Wed, May 29, 2002 at 04:58:57PM +0900, itojun@iijlab.net wrote:
>> >2) If the reseeding from /dev/random can't be turned off, the code's not
>> >   useful as random().  You yourself even suggested earlier that it would
>> >   be desirable to use the code as random().
>> 
>> 	let me back up.  we cannot replace random() by arc4random() or other
>> 	strong crypto logic.  there can be code that depends on its
>> 	predictability (and i learned that there are).  so let me drop
>> 	suggestions like "make random() to be a stronger random number" or
>> 	"make random() an alias to arc4random()".
>
>When you say "there can be code that depends on its predictability" do
>you mean that you've found some code that depends on random() being a
>linear congruential generator?  Ouch!
>
>As Perry pointed out, when some of us suggested that arc4random() could
>not replace random() because the output was not predictable, we were
>actually being stupid; if you know the key, the output is, of course,
>predictable.  So if that's the problem, it can be overcome by not
>rekeying the cipher as the current code does (but this should probably
>only be done in a debug mode).

Not necessarily -- reproducibility is important for other reasons.  
PRNGs, in general, should not be reseeded except by explicit program 
action, and the usual choice is a constant or "random" initial seed.

The question about rekeying is "why?"  Why do I want a PRNG to rekey 
itself at random times?  I think we agree that we're not producing 
key-grade random numbers, and that's the application that most needs 
rekeying.

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com ("Firewalls" book)