Thank you, “Mom.” *(I guess.)* All of you are quite correct in guessing that the previous post was mine – that I did not bother to log in before responding. (But that I was making __no__ particular attempt to hide myself ... why bother?)

Having both observed that a particular PRNG solution does not appear to provide 64 bits of __entropy__ in an apparently 64-bit value, and having also expressed a *concern* with regards to this matter, it is quite reasonable to assume that the OP __does__ require a more rigorous PRNG solution – perhaps, indeed, for some kind of cryptographic application. As I noted, “several such PRNGs *are* available in the Perl environment.”

I would also like to __specifically__ call-out the proffered suggestion of “simply” combining two 32-bit values. From any cryptographic standpoint (or, from the standpoint of any other use-case requiring comparable rigor), this is __n-o-t__(!!) the same. The two halves of the resulting 64-bit value will in fact be *joined* to one another: one is the product of the PRNG at iteration *(n),* and the other is the product of that same PRNG at iteration *(n+1),* where the value of *n* is unpredictable but the relationship between the two parts is not. This is a potentially-deadly flaw. If you need *n* bits of entropy, you __must__ use an algorithm that is designed to provide it. Such algorithms are available in Perl.

Comment onRe^5: how to get a 64bit random number with rand() ?