On Mon, 18 Jul 2011 14:08:14 +0200 (CEST) "Philipp Marek" <phil...@marek.priv.at> wrote:
> I just saw that ECL read /dev/urandom on startup, obviously to initialize its > random number generator. > > * Is that required by the specification? eg. SBCL gives always the same > numbers, unless (seed-random-state T) is called (or (make-random-state T)). I don't seem to find anything special about this in the Hyperspec, other than RANDOM being described as an approximately uniform pseudo-random generator... > * If the randomization at startup is wanted, how about reading much less > (eg. 3 words) and using a pseudo-random-number generator to fill the > random state? I agree that 4 or 8 bytes read from urandom(4) is probably sufficient, followed by the use of a pseudo-random generator. I know that the implementations of rand(3) are generally pretty crappy though, compared to BSD random(3). I'm not sure if other unix systems that also have /dev/urandom also have a decent random(3), but if so, perhaps that could be used. I have no idea if the ECL-provided Mersenne-Twister is good enough, but it's probably better than most rand(3) implementations. Perhaps that it could be initialized with minimal expanded state taken from urandom(4) to itself generate a somewhat better state in a few rounds... > My reasoning is that most people don't need cryptographically secure [1] > random numbers; if they need some, they can (and for portability _should_) > always initialize the state themselves. I agree, and we can use OpenSSL's libcrypto(3), arc4random(3) (BSD), Ironclad (CL!) or urandom(4)/random(4) ourselves if we really want them. All we need is to have a decent distribution with a decent performance. -- Matt ------------------------------------------------------------------------------ AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev _______________________________________________ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
