Subject: Re: arc4random(9)
To: None <firstname.lastname@example.org>
From: Steven M. Bellovin <email@example.com>
Date: 05/29/2002 11:17:14
In message <20020529090027.GA13251@rek.tjls.com>, Thor Lancelot Simon writes:
>On Wed, May 29, 2002 at 04:58:57PM +0900, firstname.lastname@example.org 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
--Steve Bellovin, http://www.research.att.com/~smb (me)
http://www.wilyhacker.com ("Firewalls" book)