RE: RE (tilly) 1: a random sort of list

[Adam]

As I understand it, you don't have to call srand because Perl seeds it to time for you, but if you are writing a script where you want to use rand for some attempt^* at security then you should re-seed it yourself with something more obscure. I usually use some combination of time and place, er, pid. Although obviously you don't want to just xor the two.

^*I say attempt because in the end nothing is trully secure and I don't want to start a debate on it.

[tilly]

Yes. But getting a good random seed can be hard.

On systems that have it, sample /dev/random. Frequent CGI scripts might run out of entropy though. CPAN has some cryptography modules that do a similar thing with similar limits.

If you need a *lot* of random data, make a large file from something volatile (/dev/kmem is a good source), compress it, throw away the start and encrypt *that*. Compress again and throw away the start if you are paranoid. Then sample.

The reason why this works is that perfectly random data is mathematically identical to data with an information rate of 1 (one bit of info per bit of data). So you start with data people cannot easily determine. Compression tries to increase your information rate so it becomes closer to random. (Modulo necessary signatures.) However given the type of information there will be recognizable artifacts. Encryption tries to scramble your information unrecognizably. The result is unpredicatable data that should be very close to looking like white noise.

ObTrivia: Virtually any form of encryption, even very weak ones (eg the pathetic standard Unix crypt) will be much harder to break if you first compress the data stream.

[tye]

Actually, modern Perl (since 5.004) does much better than srand(time()). The probable seed looks something like:

srand 1000003*time() + 3*$usec + 269*$$ + 73819*${undef} + 26107*\$x

where ${undef} is whatever integer is left on the stack and \$x is a pointer into the stack. Note that the above Perl code doesn't actually work; it is just an approximation of what the C code inside Perl is doing.

On systems with /dev/urandom, that is just used instead, which is pretty good. Use /dev/random if you have it, though you may have to wait for enough entropy to gather. But back to the case of systems without /dev/*random...

Although the code is described as a "quick hack" (because it doesn't do some fancy summing but just multiplies and adds), it would be hard to do much better portably from within a Perl script.

But this still isn't enough for cryptographic uses. Repeated runs of the same script might well yield the same values for the "what is left on the stack" and the "address into the stack" while the other values can be predicted to a certain extent.

So if you come up with something that seems really hard to predict, just add it into Perl's seed rather than replacing it. In other words:

    srand( fancyseed() );

is probably not nearly as good of an idea as, for example:

    srand( rand(~0) ^ fancyseed() );

Suggestions for better ways to add randomness in are welcome.

The documentation on srand() in perlfunc.pod is also worth reading.

        - tye (but my friends call me "Tye")