Bug#537952: Use more random random seed than localtime

[Jonathan Yu]

Silly me, I forgot to address your last point.

On Wed, Jul 22, 2009 at 2:51 PM, Jonathan Yu<frequency at cpan.org> wrote:
> Hi Don:
>
> On Wed, Jul 22, 2009 at 2:09 PM, Don Armstrong<don at debian.org> wrote:
>> On Wed, 22 Jul 2009, Jonathan Yu wrote:
>>> Incidentally, here is the quilt patch which should fix the issue. It
>>> should also work on older Perls without Perl_seed, so I'll forward
>>> this upstream (while making a simultaneous release in Debian) so
>>> that hopefully it's fixed in the near future.
>>
>> 1) salph ignores huge swaths of entropy which is present in the seed,
>> so I didn't want to use it (and I don't think it's the right thing to
>> do.)[1] You'd certainly need more than one call to the seed to set it
>> reasonably, and if you use salph, you don't need to restrict it to
>> 1..2^30
> Oh, I didn't know that. From my basic understanding of the code, it
> converts the entropy data (as an integer) into a string, and uses that
> somehow to get entropy. Like I said, I tried with the setseed method,
> but I had an issue with tests failing.
>
> The original implementation was calling setalph or whatever function
> with scalar(localtime) as its parameter, so I assumed that passing the
> Perl_seed (in place of localtime) would be the Right Thing(tm) to do.
>>
>> 2) Perl_seed generates a new seed every time you call it. It does not
>> expose the internal state of the random number generator. (Reading its
>> implementation will be instructive.)
>>
>> 3) Using localtime to seed the generator instead of failing (or at
>> least warning) is bad. At the very least, it should use something
>> like:
>>
>> time ^ $$ ^ unpack "%L*", `ps axww | gzip -f`

That is true, but I thought it'd be reasonable given that it's the
same thing it was doing before. I could do something with time ^ $$,
but I don't want to involve forking system calls (especially since ps
isn't exactly portable, though it will work well on Debian). Other
things to consider are different implementations of ps, for example
with busybox, if for some reason that's installed on the system rather
than the normal procutils.

Anyway, I think if users need to be sure of what seeds they are using,
they should be passing them in themselves in order to get some real
randomness. That's why my algorithms don't automatically seed -- an
empty seed will result in easily predictable output.

All of this though has made me realize that I should make it more
prominent in my documentation (for Math::Random::ISAAC in particular)
that there is no automatically chosen seed, and you need to seed the
algorithm yourself.

Anyway, given that this is good for Perl 5.8.1 and newer, and we have
5.8 since etch, I think we should be OK at least for Debian. You are
welcome to add on to my forwarded upstream bug report though:
https://rt.cpan.org/Ticket/Display.html?id=48080

>>
>> or some other reasonable implementation as well as warning that you're
>> not actually using random data.
>
> About your following e-mail about Math::TrulyRandom -- I was saying to
> use the data you get from there as a seed, so it doesn't matter that
> what *it* returns is non-uniform, you'll still get a uniform
> distribution after passing the seed through Math::Random. You're
> right, I have no idea if the assumptions about underlying hardware
> will still give it reasonable entropy, so maybe something like
> /dev/random would be a better source.
>
> Do you have specific issues with the current [patched] implementation?
> It's producing different output even with several subsequent
> executions, though I have no idea if it's generating biased output.
> Certainly though it should at least be suitable for your purposes
> (that is, simulations).
>
> If you need more security, you should make sure you're using a
> cryptographically secure PRNG algorithm and use some good seeds. Today
> I was browsing CPAN and found some neat modules which do this sort of
> thing, like Data::Entropy, which provides entropy useful for
> cryptography (and so would be fantastic for seeding an RNG)
>
> For a better, more modern RNG, I'd suggest using Math::Random::MT
> (already packaged as libmath-random-mt-perl)
>
>>
>>
>> Don Armstrong
>>
>> 1: The implementation of salph is also rather opaque and may not have
>> uniform distribution for the input that you're passing it, leading to
>> non-unform distribution of random values for repeated calls to the
>> program. [I haven't read the paper it's based on, either...]
>> --
>> This can't be happening to me. I've got tenure.
>>  -- James Hynes _Publish and Perish_
>>
>> http://www.donarmstrong.com              http://rzlab.ucr.edu
>>
>>
>>
>